Checkliste: Android-Phone absichern, BEVOR es das 1. Mal ins Internet geht (AFWall+)

  • 820 Antworten
  • Letztes Antwortdatum
Hallo 000,
Hallo an0n,

Trust System User, wo und was ist das?

Ja, anderes AOSP/CM ROM wäre evtl. besser, nur fehlt mir noch das Wissen zur Installation und somit auch noch der Mut.

@000, danke für die Tips.
@an0n dito
 
@eldoblo - Es ist doch eigentlich ganz einfach:

  • Schreib' dir diese ominöse ...amazonaws.com Domain vollständig ab (wichtig: ohne Fehler, also nochmal prüfen)
Dann

  • AdAway öffnen
  • Superuser Zugriff erlauben
    _
  • Menü von AdAway öffnen (oben rechts, 3 Quadrate)
  • "Meine Listen" wählen
  • Reiter/Tab "SCHWARZ" wird angezeigt (müsste noch leer sein, das ist deine persönliche Blacklist für Domains/Hostnamen, die du gerne zusätzlich blockieren möchtest)
  • Oben das [ + ]-Symbol antippen
  • Im Feld "Hostname" gibst du jetzt die zu blockierende Domain exakt ein
  • Button [ Hinzufügen ] antippen
    _
  • Zurück-Taste
  • Button [ Dateien herunterladen und den Werbeblocker aktivieren ]
    _
  • Phone neu starten
  • Neuer Test mit Networklog
  • Ergebnis wieder mitteilen

PS: Merci für die Screenshots :cool2:

Edit: "Trust System User" - Das ist eine Option in der SuperSU-App von Developer Chainfire, wenn dir das nichts sagt, vergiss es wieder.
 
Zuletzt bearbeitet:
Man kann auch die IP feststellen und diese dann im afwall-start-script blockieren (wie bei den Facebook-Adressen):

Folgende Zeile hinzufügen:
Code:
# eldoblo's nightmare blocker
$IPTABLES -A "afwall" -d 54.171.31.66/32 -j REJECT
___

Eine (System-)App kann man auch mit root und dem Terminal einfrieren, wenn der Button [ Deaktivieren ] ausgegraut ist:

  • Anwendungsliste öffnen
  • App suchen, die bearbeitet werden soll (im Beispiel "Bluetooth-Freigabe")
  • Antippen, um die App-Info zu öffnen
  • "Echten" App-Namen ablesen (unter "Bluetooth-Freigabe")
  • => Im Beispiel ist das "com.android.bluetooth"
  • Android Terminal Emulator öffnen
Folgende Befehle eingeben, um die App "einzufrieren":
Code:
su
pm [COLOR=Red]disable[/COLOR] com.android.bluetooth
Folgende Befehle eingeben, um die App wieder "aufzutauen":
Code:
su
pm [COLOR=SeaGreen]enable[/COLOR] com.android.bluetooth
Um zu sehen, welche Apps "eingefroren" (-d = disabled) sind:
Code:
su
pm list packages -d
Tipp: Gut überlegen, was man da macht, evtl. vorher ein (TWRP) Backup machen ...
_
 

Anhänge

  • dig-amazonaws.com.png
    dig-amazonaws.com.png
    50,4 KB · Aufrufe: 390
  • app-list.png
    app-list.png
    30 KB · Aufrufe: 302
  • app-info.png
    app-info.png
    20,2 KB · Aufrufe: 305
  • app-freeze-unfreeze.png
    app-freeze-unfreeze.png
    12 KB · Aufrufe: 286
Zuletzt bearbeitet:
  • Danke
Reaktionen: mratix
ooo schrieb:
Inhalt Start-Script (Datei afwall-start-script)
#
# /data/local/afwall/afwall-start-script
#
IPTABLES=/system/bin/iptables
IP6TABLES=/system/bin/ip6tables

# Flush/Purge INPUT rules (All 'afwall' chains/rules gets flushed automatically, before the custom script is executed)
$IPTABLES -F INPUT

# Flush/Purge all chain
$IPTABLES -X
$IPTABLES -t nat -X
$IPTABLES -t mangle -

Achtung, im Startscript, Zeile 13 fehlt das letzte Zeichen

Errata
Code:
$IPTABLES -t mangle -X
@ooo Danke für das Tutorial zum Einfrieren/Auftauen
Code:
pm disable com.android.bluetooth
pm enable com.android.bluetooth
pm list packages -d
danach habe ich lange gesucht

Du hast echt was drauf :wubwub:
 
Zuletzt bearbeitet:
  • Danke
Reaktionen: ooo
mratix schrieb:
Achtung, im Startscript, Zeile 13 fehlt das letzte Zeichen

Vielen Dank, "Eagle Eye" mratix!

Ich hab' es gerade im Code korrigiert und die Datei afwall-start-script.txt im Beitrag gegen eine korrigierte ausgetauscht
___

mratix schrieb:
Du hast echt was drauf :wubwub:
Ja, das sieht man ja an meinen Fehlern ... (joke). - Nee, danke, ich freu' mich natürlich über dein Lob.

Mit dem pm (Package Manager) kann man im Terminal oder via adb übrigens noch sehr viel mehr herausfinden/machen. - Man kann diese Kommandos auch in Shell-Scripts verwenden, um Dinge zu automatisieren (z. B. nach einem ROM Install, eine Gruppe von System-Apps einfrieren mit nur einem Befehl etc.).

Schau' es dir mal an, wenn du möchtest.
 
Zuletzt bearbeitet:
Hallo,

-14 (NTP) Internet-Zeitserver in AFWall aktiviert.

Bluetooth-Freigabe mittels Terminal Emulator eingefroren. Laut der Anzeige "pm list packages -d" ist bluetooth eingeforen (eine Fehlermeldung text relocation....wird jedoch angezeigt).

Im start-script Zeilen für "eldoblo's nightmare blocker" eingegeben.

Netzwerklog zeigt im log wieder Bluetooth-Aktivitäten an.

Schaut euch bitte die Screenshots an.


Gruß

eldoblo

"der nightmare blocker"
 

Anhänge

  • Screenshot_2015-03-10-17-48-41.png
    Screenshot_2015-03-10-17-48-41.png
    85,1 KB · Aufrufe: 265
  • Screenshot_2015-03-10-17-47-53.png
    Screenshot_2015-03-10-17-47-53.png
    85,6 KB · Aufrufe: 283
  • Screenshot_2015-03-10-17-38-18.png
    Screenshot_2015-03-10-17-38-18.png
    101,7 KB · Aufrufe: 283
  • Screenshot_2015-03-10-17-37-25.png
    Screenshot_2015-03-10-17-37-25.png
    91,2 KB · Aufrufe: 250
@eldoblo

Edit: Scheint ja etwas Samsung-spezifisches zu sein (Samsung Diagnose == Spy Crap der Samsung-ROM):
https://www.google.de/search?q=54.171.31.66
https://www.virustotal.com/en-gb/ip-address/54.171.31.66/information/
https://www.virustotal.com/en-gb/domain/api-diagmon.samsungdmroute.com/information/


Edit 2: Andere Idee

Hat deine ROM eine Statistik-Funktion, wie bei z. B. CyanogenMod (siehe Screenshots)? - Die könnte man nämlich evtl. irgendwo in den Einstellungen
deaktivieren. - Zusätzliche Firewall-Blockierung ist aber immer (noch) besser ...

___


Der neue Traffic kommt daher, weil jetzt eine andere IP (54.171.31.62) benutzt wird, die wir nicht gesperrt haben. - Versuch das mal abzustellen, indem du die Regel bei "eldoblo's nightmare blocker" änderst (also nur die Zeile ändern), dann wieder Neustart:

ALT:
Code:
# eldoblo's nightmare blocker 
$IPTABLES -A "afwall" -d 54.171.31.[COLOR=Red]66/32[/COLOR] -j REJECT
(...66/32 bedeutet, das nur die einzelne IP 54.171.31.66 geblockt wird.)

ENTWEDER - NEU 1 (Die "Keule"):
Code:
# eldoblo's nightmare blocker 
$IPTABLES -A "afwall" -d 54.171.31.[COLOR=SeaGreen]0/24[/COLOR] -j REJECT
(...0/24 bedeutet, das alle 256 IPs des Bereichs (IP-Range) von 54.171.31.0 bis 54.171.31.255 geblockt werden.)

ODER - NEU 2 (nur die beiden IPs blocken):
Code:
# eldoblo's nightmare blocker - block Samsung diagnostic app monitoring spy crap 
$IPTABLES -A "afwall" -d 54.171.31.[COLOR=Green]66/32[/COLOR] -j REJECT
$IPTABLES -A "afwall" -d 54.171.31.[COLOR=Green]62/32[/COLOR] -j REJECT
Mal sehen, ob dann Ruhe ist oder wieder eine andere IP-Adresse benutzt wird ...

(Wenn das nicht hilft, schauen wir uns mal dein logcat an, um herauszufinden, welcher Prozess das eigentlich initiiert.)

___

Den Hostnamen in AdAway hast du nicht eingetragen?
Wenn doch, nimm ihn bitte wieder raus.
"Aufräumen" ist immer gut ...

Dein Bluetooth kannst du ja wieder auftauen, weil es ja immer noch Traffic gibt (das war's dann ja nicht):
Terminal öffnen:
Code:
su 
pm enable com.android.bluetooth
(Die beschriebene Fehlermeldung kenne ich nicht. - Das kann aber auch woanders herkommen ...)
_
 

Anhänge

  • statistik-1.png
    statistik-1.png
    15,9 KB · Aufrufe: 249
  • statistik-2.png
    statistik-2.png
    19,2 KB · Aufrufe: 255
  • statistik-3.png
    statistik-3.png
    8,1 KB · Aufrufe: 251
Zuletzt bearbeitet:
  • Danke
Reaktionen: mratix
wie @ooo vorhin schrieb, wird es ein Trackingtool sein.

Definitiv von Samsung. Und die beiden IP-Adressen der Zielserver sind in einer Amazon EC2-Cloud untergebracht. Daher vorsicht beim Sperren. Insbesondere blind mit einer Subnetmask /24. Da könnten schnell
a) Dienste anderer Apps mitgesperrt werden, die man braucht
b) Bereiche, die nicht in den Adressbereich des betroffenen Anbieters gehören.

Ich muss zugeben, in diesem Fall ist es schwer zu bestimmen, welche Adressen zum o.g. Szenario gehören. Einfach beobachten. Viel wichtiger wäre, herauszufinden welche App/Funktion es auslöst. Es sind ja keine großen Daten die das fließen, eher kleine Metadaten.
---

Mir fällt in den Screenshots auf, Du [bzw. dein Phone :) ] sich im Flugmodus befindet.
Ich konnte bei mir öfters merkwürdiges Verhalten bei afwall beobachten, wenn sich das Phone in diesem Modus befindet. Muss aber nichts heißen.

Auch sehe ich, dass die Einträge vom Interface rmnet0 statt wlan0 kommen.

Habe es gerade getestet, Flugmodus aktiviert. Ein paar Apps aufgerufen und zur Kommunikation gezwungen.
-> Netzwerk Log bleibt *wie Flasche leer*, da tropft nichts durch und kommt auch nichts an.

Daher wiederholt die Frage:
Netzwerk Log: Protokolliere hinter Firewall ist angeklickt?
Afwall: nach Änderung an den Häckchen, klickst du auch auf "Anwenden"? und bekommst ein "Regeln erfolgreich angewendet" zurück?

Bitte ggf. mal das Profil wechseln. Auch dann mus ein "Regeln erfolgreich..." zurückkommen.

Schon mal das Phone in den WLAN-Modus umgeschaltet? Neu gestartet?
Was steht im "Firewall-Protokoll" von afwall?
---

Die Sache mit der linker app_process has text relocations in adb kannst du ignorieren.
Es betrifft eher die Entwickler, darauf hast du wenig bis keinen Einfluss.

Eine kurze Suche spuckte aus: Xposed Module bla bla development, fehlerhafte Deklarationen in manifest von Apps usw.
 
die Einstellungen in AFWall sind korrekt gesetzt (hinter Firewall, Haken gesetzt, Anfrage, Bestätigung Regel übernommen usw.> ok) und werden übernommen.

# eldoblo's nightmare blocker
$IPTABLES -A "afwall" -d 54.171.31.0/24 -j REJECT
aktiviert, jedoch wird im weiteren logtest exakt 54.171.31.66 aufgeführt und somit werden Daten an der Firewall vorbeigeleitet.

Wlan ist deaktiviert, wozu aktivieren, habe kein anderes Gerät, Fritzbox, Hotspot, ok?
Aber auch mit Wlan>ON gleiches Testergebnis , nur aus und einlog etwas schneller.

Flugzeugmodus deaktiviert >mobile Daten aktiviert, dann für einige Sekunden mit Netzverbindung, danach automatischer auslog>einlog>
"böser" (bluetooth) Popup und loginfo zeigt die Daten.

Bei klick auf WHOIS IP-Adresse erscheint Amazonaws, wie hängt das zusamnen?

"Andere Baustelle", warum bekomme ich keine "Sofortmail" über den Beitrag von
matrix heute 03:15, war ja ausgelogt und seit dem nicht mehr im Forum, hätte also heute morgen die Foren "Sofortmail" bekommen müssen?

(bitte im Hinterkopf behalten, ich bin kein Fachmann nur Anwender)
 

Anhänge

  • Screenshot_2015-03-11-08-32-36.png
    Screenshot_2015-03-11-08-32-36.png
    89,9 KB · Aufrufe: 259
  • Screenshot_2015-03-11-08-31-39.png
    Screenshot_2015-03-11-08-31-39.png
    80,2 KB · Aufrufe: 256
Moin, eldoblo, gute Nachrichten für dich.

Kurzfassung: Die böse Hexe ist tot.

Lange Fassung:

Deine beiden Screenshots sagen mir Folgendes:

  1. Die Firewall-Regel für die DNS-Anfragen nach OpenDNS funktioniert auch für die Mobilfunkschnittstelle (Einträge von "0 root" für "UDP/rmnet0")
  2. Es wird keine Verbindung mehr zu xyz...amazonaws.com gemacht
  3. Die Firewall-Regel zum Blocken von amazonaws.com scheint also zu funktionieren
  4. Das Phone (der System User mit UID 1000) holt sich beim Start (oder kurz danach) Datum und Uhrzeit beim beabsichtigten NTP-Server der Universität
  5. Die Firewall-Regel für NTP funktioniert also auch, wie gewünscht
Da viele Apps unter dem System User (UID 1000) laufen, wird dieses Zeit-Holen (Protokoll NTP, Verbindung zur Uni) bei allen Apps *gleichzeitig* protokolliert, obwohl keine der Apps etwas damit zu tun hat (das verwirrt, ist aber halt so in Netzwerk Log). - Netzwerk Log protokolliert den Traffic pro User-ID, nicht pro App. - In der "Not" verbucht es dann halt bei jeder 1000er-App den Traffic des Users mit UID 1000.
Es ist nur ein Darstellungsproblem. - Die Firewall funktioniert.

Was du jetzt machen könntest, ist, die Regel nochmal auf die mit den beiden IPs (...66/32 und ...62/32) abzuändern, anstatt die "Keulen"-Regel zu benutzen (die ja 256 IPs gleichzeitig blockiert).

Übrigens müssten ja auch Einträge im Protokoll der AFWall+ Firewall als geblockt stehen, wenn alles korrekt ist (und das Protokoll eingeschaltet ist). - Wie sieht es denn dort aus?

Nur zur Info (und, um sicher zu gehen):
Network Log-Protokoll = alles, was rausgeht
AFWall+ Firewall-Protokoll = alles, was wirklich geblockt wurde
Das Network Log-Protokoll ist nicht das AFWall+ Firewall-Protokoll

Frage:
Kannst du uns mal einen Screenshot mit diesem (mir unverständlichen) Bluetooth-Popup machen? - Oder ein Bildschirm-Photo mit einer Kamera? - Oder wenigstens den exakten Text geben?

Wenn Bluetooth in den Einstellungen AUS ist, dann darf auch absolut nichts mit/über Bluetooth passieren ...
(Es sei denn, es gibt eine App, die die Einstellungen der Bluetooth-Schnittstelle verändern darf.)

Auch dieses Einloggen/Ausloggen beschreibst du so, dass ich es nicht verstehe. - Vermutlich ist es etwas ganz Triviales ... und ich bin einfach "blind", sorry.

___

Das mit deiner Sofort-Mail kann verschiedene Ursachen haben:

  • Deine Einstellungen bei androidh-hilfe.de sind vllt. noch nicht komplett
  • Der android-hilfe.de Server hat "gepennt"
  • Dein Mail-Provider hat "gepennt"
  • Deine Mail-App hat "gepennt"
  • Dein Phone hatte keine Verbindung zum Internet (entweder wirklich nicht, oder im Ruhezustand wird Strom gespart und die Schnittstelle abgeschaltet, keine Ahnung...)
  • Etwas völlig Anderes
 
Zuletzt bearbeitet:
bhoa krass! langsam @ooo jetzt komm ich nicht mehr mit :)

Wenn ich es richtig sehe, kommt der ganze Schadder von UID1000 und fließt sowas von vorbei, an der afwall.

Da würde ich als erstes und ohne zu zögern ein

Code:
$IPTABLES -A "afwall" -p all -m owner --uid-owner 1000 -j "afwall-reject"
bzw.

Code:
$IPTABLES -A "afwall-3g" -p all -m owner --uid-owner 1000 -j "afwall-reject"
reinschießen.

Und wenn immer noch was rauskommt die ROM deinstallieren, Antenne abknipsen und Akku entfernen :)

next: Ich warte noch etwas, bis @eldoblo das ganze in den Griff bekommt, bevor ich mit der nächsten Frage/Thema anfange.
 
@mratix - Verwirrung ... Wo sieht man Traffic, der (unerlaubt) abfließt?
 
Stimmt auch wieder.
Es sind lauter ntp Anfragen und der dns Resolver.

Aber so viele? Und wofür will Bluetooth Zeit synchronisieren?
Ziemlich kommunikationsfreudig und Traffic-hungrig das Phone :)
 
Lies noch mal meine Erklärung für @eldoblo in #130 zu der Mehrfach-Protokollierung in *allen* Apps einer UID (1000 - System User).

Es geht *nur* 1 Paket mit 76 Bytes raus, um Datum und Uhrzeit beim NTP-Server zu holen. - Das sendet der System User UID 1000 auf *OS-Ebene*, NICHT eine der Apps.

Netzwerk Log zeigt dieses 1 Paket aber bei allen Apps an, die unter dem System User UID 1000 laufen (*könnten*). - Weil Netzwerk Log es nicht anders hinbekommt. - Die Apps haben mit diesem *einen* NTP-Paket nichts zu tun.

Es wird (der Traffic) der Bluetooth-App "in die Schuhe geschoben", weil sie zufällig (alphabetisch) die erste App mit UID 1000 ist ...

Im übrigen ist der System User UID 1000 in der Firewall ja gesperrt und "-14: NTP" ist erlaubt ...
(Nur dieser einmalige NTP-Traffic beim Starten des Phones kann raus, die 1000er-Apps selbst dürfen NICHT raus.)
 
Zuletzt bearbeitet:
das Protokoll der AFWall zeigt gesperrte bluetooth IP's, das ist ok.

Anzeige auf dem Phone mittels Popups>Netzwerklog>Einstellungen>Verbindungsnatifacations>Popups

oder

AFWall>3 Quadrate>Einstellungen>Protokolldienst einschalten

erzeugt temporäre (s) Informationen mit Dienstbezeichnung, IP und Port auf dem Phone-Display.

amazonaws ist noch da.

so, jetzt habe ich genug Bilder gemacht.
 

Anhänge

  • Screenshot_2015-03-11-14-44-17.png
    Screenshot_2015-03-11-14-44-17.png
    99,7 KB · Aufrufe: 255
  • Screenshot_2015-03-11-14-42-02.png
    Screenshot_2015-03-11-14-42-02.png
    82,9 KB · Aufrufe: 259
  • Screenshot_2015-03-11-14-41-36.png
    Screenshot_2015-03-11-14-41-36.png
    85,9 KB · Aufrufe: 258
  • Screenshot_2015-03-11-14-40-56.png
    Screenshot_2015-03-11-14-40-56.png
    30,1 KB · Aufrufe: 245
  • Screenshot_2015-03-11-14-40-13.png
    Screenshot_2015-03-11-14-40-13.png
    313,4 KB · Aufrufe: 265
darf ich wiederholen: Du hast echt was drauf :wubwub:

- Ich kämpfe gerade mit folgendem und komme nicht drauf :confused2:
Code:
# Block all traffic from userapps that's not outgoing default http(s) port
SAFE_PORTS_TCP=80,443
$IPTABLES -A "afwall" -p tcp -m owner --uid-owner 10000:19999 -m multiport ! --dports $SAFE_PORTS_TCP --sport 1024:65535 -j "afwall-reject"
mag er vielleicht den Range nicht, weil es über die letzte (d.h. vorhandene) hinausragt?


- und dann suche ich nach einer Abfrage für <package_name>
Code:
$APP_NAME=com.android.flipper
$APP_UID=UID_von_$APP_NAME
... -m owner --uid-owner $APP_UID
es muss numerisch sein, damit es verarbeitet werden kann.

Hab da so eine schwache Erinnerung, dass es mal für DroidWall diskutiert wurde.


oupss, möchte nicht hineindrängeln ... ignoriert vorerst diesen Post
 
Zuletzt bearbeitet:
@eldoblo - Es ist alles korrekt. - Bis auf dieses Bluetooth-Test-Dingens.

Vorschlag:

  • Alles so lassen
  • Nur deinen Browser "einfrieren" und dafür vorher einen anderen Browser installieren (evtl. ist das mit Bluetooth irgendwie im Browser der ROM fest eingebaut?)
  • Zusätzlich würde ich die Hostnamen xyz...amazonaws.com alle bei AdAway auf die persönliche Blacklist setzen (wie ein paar Postings weiter oben beschrieben)
  • Dann surfen und nachsehen, ob dieses Bluetooth-Test-Dingens wieder hoch-popt.
Danke übrigens für die Erklärung zu Bluetooth-Pop-up von AFWall+ (ich > Schlauch > jetzt neben Schlauch) und die aussagekräftigen Screenshots :thumbup:

___

Du kannst auch mal probehalber versuchen, den Captive Protal Check zu deaktivieren:

(Das geht normalerweise zu Google, aber vllt. hat Samsung das "umgebogen" im Code der ROM.)

Terminal öffnen, dann
Code:
su
settings put global captive_portal_detection_enabled 0
settings put global captive_portal_server localhost
Protokolle löschen
Phone neu starten und warten, ob diese amazonaws.com-Sache wieder im Protokoll steht.

Wenn die wieder kommt, würde ich mir ernsthaft überlegen, das Phone oder die ROM auszutauschen gegen was Nicht-Samsung-iges ...

Edit: Vllt. machen wir doch noch ein logcat ...

Der ursprüngliche Beitrag von 15:30 Uhr wurde um 16:17 Uhr ergänzt:

@mratix - Ich habe mir das nicht genau angesehen, aber wenn ich dich richtig verstehe, dann willst du allen ausgehenden Traffic blocken, der nicht von Port 80 oder Port 443 abgeht?

Ich habe das nicht ausprobiert und weiß nicht, ob das funktioniert:
Code:
# only allow outgoing traffic from source port 80 (HHTP) and 443 (HTTPS) tcp
# and DNS requests
#
$IPTABLES -P OUTPUT DROP
#
$IPTABLES -t nat -A OUTPUT -p udp --dport 53 -j DNAT --to-destination 208.67.222.222:53
$IPTABLES -t nat -A OUTPUT -p tcp --dport 53 -j DNAT --to-destination 208.67.222.222:53
#
$IPTABLES "afwall" -m state --state NEW -m tcp -p tcp --sport 80 -j RETURN
$IPTABLES "afwall" -m state --state NEW -m tcp -p tcp --sport 443 -j RETURN
$IPTABLES "afwall" -m state --state RELATED,ESTABLISHED -j RETURN
Irgendwie so ...

Der ursprüngliche Beitrag von 16:17 Uhr wurde um 17:23 Uhr ergänzt:

@eldoblo

Terminal öffnen:

Code:
su
pm [COLOR=Red]disable[/COLOR] [B]com.sec.android.app.bluetoothtest[/B]
 
Zuletzt bearbeitet:
@ooo Jain.

Ist eine etwas längere Geschichte...
Arbeite an einer modularen afwall-start.
Beinhaltet im Vorspann alle Variablen und Werte, die leicht an die pers. Umgebung anzupassen sind.
Enthält einen Vorspann mit gültigen Standardregeln.
Dann im Body mehrere Umgebungsprofile (Ergänzung zu den afwall-Profilen)
Dann gibts Regeln gegen Nightmare :) u.ä. gesammelte Werke.
Zum Schluss einen Lockdown gegen "tropfendes Wildwasser".

Das ganze soll universell einsetzbar sein, also Geräte- und Umgebungsungebunden. Gerade für neue Benutzer, die erstmals eine Firewall anfassen und sich mit dem Einbau der Grundregeln schwer tun. Oder auch nur fragen was überhaupt blockiert werden kann, darf, soll.
Ebenso für Multi-Springer die verschiedene Umgebungen haben und öfters die Netzwerke wechseln.
Quasi ein Feinschliff der App-Kommunikation. Basierend auf Deinem z.V. gestellten Script.

Möchtest ne Kostprobe? Damit aufkommende Fragen etwas verständlicher werden.

Aber wenn's soweit ist, bekommen es alle hier.

Blockieren möchte ich nur einen Teil, die UserApps <10000

In der afwall-Wiki gibts tolle Beispiele und Anregungen. U.a. im Abschnitt DroidWall only glaube ich was gefunden zu haben.
Code:
VOIP_UID1=`dumpsys package org.linphone | grep userId | cut -d= -f2 - | cut -d' ' -f1 -`
Mal sehen, ob das Teil die UID auch mit afwall rausspuckt.
 
@eldoblo

Terminal öffnen:

Code:
su
pm [COLOR=Red]disable[/COLOR] [B]com.sec.android.app.bluetoothtest[/B]


Der ursprüngliche Beitrag von 17:25 Uhr wurde um 17:31 Uhr ergänzt:

@mratix - So ach! - Ja klar - der dumpsys mit dem grep / cut, um die ID zu bekommen, sollte funktionieren, weil das auf OS-Ebene läuft und nichts mit der AFWall oder DroidWall zu tun hat. - Das ist Linux-Shell-Scripting, weiter nix ... Hört sich interessant an.
 
@000,

klappt mit "su pm disable com.sec.android.app.bluetoothtest" leider auch nicht.

Gruß
 

Anhänge

  • Screenshot_2015-03-11-19-49-07.png
    Screenshot_2015-03-11-19-49-07.png
    89,3 KB · Aufrufe: 221
  • Screenshot_2015-03-11-19-48-07.png
    Screenshot_2015-03-11-19-48-07.png
    88,4 KB · Aufrufe: 240

Ähnliche Themen

M
Antworten
0
Aufrufe
126
martin1111
M
sensei_fritz
Antworten
9
Aufrufe
175
sensei_fritz
sensei_fritz
F
  • Felix76
Antworten
6
Aufrufe
911
Felix76
F
Zurück
Oben Unten