Hallo werte Android-Nutzer, wie verhindert man, das Anlegen der Verzeichnisstruktur, siehe Anhang, beim Einstecken eines ext. USB Speicher-Sticks? In meinem Fall unter Android 11 & 12. Danke für sachdienliche Hinweise. LG Markus
Hat keiner eine Idee zum obigen Posting? Markus
Hallo! Das kann man nicht verhindern. Es sei denn man greift ganz tief in den Kernel ein. Gruß, René
:
Bearbeitet durch User
René H. schrieb: > Hallo! > > Das kann man nicht verhindern. Es sei denn man greift ganz tief in den > Kernel ein. > > Gruß, René Der "Koernel" treibt solchen Unfug nicht. Das sind die Brogrammieraeffchen bei Guggel! Hurtig voran zu einem System auf dem nur noch Furzapps laufen. Und natuerlich Guggel-S.P.A.M. Du koenntest es mit einem SD-Karten-Adapter mit herausgefuehrtem Schreibschutzschalter versuchen. Beim "Connect" sollte der auf R/O stehen. Dann laeuft die "Automatik" ins Leere. Ein USB-Stick mit einem solchen Schalter waere vllt auch brauchbar. Wenn du dann selbst schreiben willst: Schalter auf R/W. :) Android mountet externe Medien mit 666, so dass selbst ein R/O-Flag einer Datei ignoriert wird. Idi.... am Werk!
Man könnte die zuständige XML-Datei umschreiben, damit sie diesen Unsinn künftig unterlässt. Also quasi "am Kernel rumbasteln".
Markus W. schrieb: > Einstecken eines ext. USB Speicher-Sticks Wenn ich einen leeren USB-Stick mit bereits angelegtem exFAT Filesystem an den USB-Anschluss eines Pixel 7 Pro mit Android 14 stecke, bleibt er unverändert leer und ist voll funktionsfähig. Wenn ich ihn dann an den USB-Anschluss eines T Tablet mit Android 14 stecke, wird er nicht akzeptiert, weil es das exFAT nicht mag. Akzeptiere ich das Angebot, ihn zu formatieren, gibt es laut PC VFAT/FAT32, aber abgesehen vom FAT-üblichen LOST.DIR bleibt er leer. Mit der µSD-Karte im Tablet verhält es sich anders. Die hat obigen Salat drauf. Ist aber eine andere Baustelle. Also worum geht es wirklich: Stick am USB-Anschluss oder µSD im Slot vom Gerät?
:
Bearbeitet durch User
@A.K. USB-3.0 C Stick am USB-3.0 C-Port einer Mot. Edge. Wahrscheinlich sind es irgendwelche Skripte, die via systemd beim Anstecken eines ext. Dev. die Verzeichnisstruktur anlegen. Bei einer internen SD-Karte wuerde ich das noch akzeptieren, aber nicht bei einem Stick zum kurzfristigem Datenaustausch! LG und Danke fuer die Antworten. Markus
Markus W. schrieb: > Bei einer internen SD-Karte wuerde ich das noch akzeptieren, > aber nicht bei einem Stick zum kurzfristigem Datenaustausch! Warte mal erst, bis du mit einem Windows-System Daten austauscht... Da bekommst du die System Volume Information untergeschoben, und oft auch thumbs.db bis der Arzt kommt.
@Jens M., deswegen mache ich einen großen Bogen um Windoofs. Bin seit dreißig Jahren eingefleischter Linux Nutzer. Nur in der Arbeit kann ich mich nicht ganz von Windoofs trennen, da ist aber die IT für mein NB zuständig. LG+sSo. Markus
Tja, und die meisten Leute machen einen Bogen um Loonix-Nutzer, weil die sich oft für was besseres halten. Du hast ja sicherlich Root auf deinem Android, da dürfte es für dich ja kein Problem sein rauszufinden, wo das Skript sitzt, das die Ordnerstruktur erstellt, und es dann zu entfernen.
Wollt ihr nicht lieber mit vereinten Kräften gegen das besagte Motorola Edge von Lenovo schiessen, statt euch mit Windows und Linux zu verzetteln? Denn es geht hier weder um das Eine noch das Andere. :)
:
Bearbeitet durch User
Das geht nur mit Root, und selbst dann nicht für Luschen, weil jeder Hersteller das anders macht, teilweise auch an mehreren Stellen oder "ForceClose wenn nicht da", also selbst wenn man es erfolgreich unterbindet macht es Ärger. Interessant dran: Nutzen tut es auch keiner, die 324 Ordner sind immer alle Leer.
Jens M. schrieb: > die 324 Ordner sind immer alle Leer. Wenn damit die im Startbeitrag gemeint sind: Das sind doch bloss Standardordner, wie sie bei einer µSD im Slot Sinn ergeben. Weil man teilweise ja wählen kann, wo beispielsweise Fotos landen sollen. Also widerspiegeln sie die Struktur des primären Filesystems. Freilich ist das bei USB-Sticks grober Unfug. Es sieht ja so aus, als ob das nicht bei jedem Android-Gerät geschieht, sondern bloss bei diesem.
:
Bearbeitet durch User
Markus W. schrieb: > Wahrscheinlich sind es irgendwelche Skripte, die via systemd > beim Anstecken eines ext. Dev. die Verzeichnisstruktur anlegen. Android nutzt kein systemd...
Na keine Ahnung, ob nur bei diesem (Mot. Edge), da ich nur dieses in dreifacher Ausführung habe. (Frau, Mutter und ich.) Root-Access habe ich nicht, da auch Zahlungen damit erfolgen, so dass das ganze Google-Gedoense drauf sein muss. Wollte mir schon ein Fairphone vor einem Jahr zulegen, aber mich hat die G5 Funktionalität von Edge überzeugt und das bei unter 300 Euro, bei Alternate, vor drei Jahren. Markus
@Niklas G.,
> Android nutzt kein systemd...
habe es mir schon gedacht, war aber nicht sicher.
Auf jeden Fall, gibt es viele bash Skripte auf dem
Phone, wenn man mit adb drauf schaut.
Wenn Ihr eine Methode/Skript habt um das Gerät zu rooten
und wieder in den ungerooteten Zustand zurück zu setzen,
dann bitte ich um diese Info.
Markus
:
Bearbeitet durch User
(prx) A. K. schrieb: > Das sind doch bloss > Standardordner, wie sie bei einer µSD im Slot Sinn ergeben Die ergeben seltenst Sinn, wenn der Speicher nicht als Systemspeicher benutzt wird. Die ergeben auf /data Sinn, aber auch nur wenn sie benutzt werden, und bei vielen ist auch Intern nix drin. (prx) A. K. schrieb: > Es sieht ja so aus, als ob das nicht > bei jedem Android-Gerät geschieht, sondern bloss bei diesem. Sony, Samsung und Xiaomi machen das auch. Markus W. schrieb: > Root-Access habe ich nicht, da auch Zahlungen damit erfolgen, so dass > das ganze Google-Gedoense drauf sein muss. Das eine und das andere schließen sich nicht aus. Aber wenn man natürlich jeden Update mitmachen muss, ist root instabil, Roothide auch, und die Zahlungen sowieso. Markus W. schrieb: > Wenn Ihr eine Methode/Skript habt um das Gerät zu rooten > und wieder in den ungerooteten Zustand zurück zu setzen, > dann bitte ich um diese Info. Das bringt dir nix. Wenn du rootest, um die Dateien zu modifizieren, wird das System "uncertified", und damit muss man tricksen. Dann wieder ein unroot zu machen schließt dich nur selber aus, aktivierst du den Bootloader wieder ("schließen" genannt, vergleichbar mit Secureboot beim PC) ist das Ding tot. Mit offenem BL und root hast du alle Möglichkeiten, evtl. auch andere ROMs zu testen, die dir vllt besser gefallen.
Ich habe eigentlich immer Exoten SP. Davor ein Acer E39 mit drei SIM-Karten. Nun das Edge mit Dual-Sim. Für diese Geräte gibt es oft selten oder keine Custom-ROM's. Selber bin ich nicht so fit mir eins zu basteln. Habe zwar etwas Erfahrungen mit adb und fastboot und auch twrp um die Partitionen zu manipulieren, bin aber nicht so versiert, dass ich das mit Links hinkriege. Ab und zu schaue ich im Developer Forum von Lineage vorbei, aber bin da nicht auf dem Laufendem, wohin die Entwicklung geht und welche Custom-ROM Images es mittlerweile für welche Geräte gibt. Das kann man nämlich auch zu einem Zeit-fressendem Hobby machen und meine Interessen liegen woanders. Danke für die Ausführungen zum Thema. Markus
:
Bearbeitet durch User
Deshalb gibt es immer weniger Custom-ROMs: die meisten Leute wollen ihr Dings benutzen, und die Hersteller hauen immer schneller immer mehr Modelle raus, dagegen kann keiner mehr basteln. Leider.
Motopick schrieb: > Android mountet externe Medien mit 666, so dass selbst ein > R/O-Flag einer Datei ignoriert wird. Idi.... am Werk! Seit wann unterstützt FAT Unix Dateiberechtigungen? Zeig mal wie Du es "richtig" mountest.
Markus W. schrieb: > wie verhindert man, das Anlegen der Verzeichnisstruktur eine (Not)Lösung wäre sie zu löschen und als 0Byte Dateien mit den selben Namen, schreibgeschützt und unsichtbar an zu legen. Dann pfuscht Adroid nicht mehr darauf rum. Das geht auch mit dem Windows Mülleimer ($Recycle)
Alexander schrieb: > Motopick schrieb: >> Android mountet externe Medien mit 666, so dass selbst ein >> R/O-Flag einer Datei ignoriert wird. Idi.... am Werk! > > Seit wann unterstützt FAT Unix Dateiberechtigungen? Zeig mal wie Du es > "richtig" mountest. Bist du ahnungslos? Zunaechst einmal unterstuetzt ein FAT-FS u.a. ein R/O-Flag per Datei. Der Androidmount macht dieses Flag auf FS-Ebene unsichtbar, weil noch eine Mountmask verwendet wird. Ein einfacher Mount wuerde das Flag respektieren, und z.B. aus einem 666/777 ein 444/555 machen. Achim H. schrieb: > Markus W. schrieb: >> wie verhindert man, das Anlegen der Verzeichnisstruktur > > eine (Not)Lösung wäre sie zu löschen und als 0Byte Dateien mit den > selben Namen, schreibgeschützt und unsichtbar an zu legen. > Dann pfuscht Adroid nicht mehr darauf rum. > Das geht auch mit dem Windows Mülleimer ($Recycle) Das funktioniert eben nicht. Siehe oben.
Markus W. schrieb: > Wenn Ihr eine Methode/Skript habt um das Gerät zu rooten > und wieder in den ungerooteten Zustand zurück zu setzen, > dann bitte ich um diese Info. Bei Samsung-Geräten würde ich das lassen. Zumindest wenn man den "Secure Folder" nutzen möchte. Denn ein Samsung zu rooten, ohne den "Knox warranty void" zu triggern, ist alles andere als leicht. Sobald der Knox-Counter getriggert ist, kann der "Secure Folder" nicht mehr genutzt werden, und alle Inhalte darin sind für immer verloren.
Motopick schrieb: > Ein einfacher Mount wuerde das Flag respektieren, und z.B. aus > einem 666/777 ein 444/555 machen. Zeig mal
Ein Android 4 wo die Welt noch in Ordnung war:
1 | . |
2 | /mnt/ext_card/TESTDIR # touch TESTFILE |
3 | /mnt/ext_card/TESTDIR # ls -l TESTFILE |
4 | -rwxrwxr-x system sdcard_rw 0 2024-06-17 10:16 TESTFILE |
5 | /mnt/ext_card/TESTDIR # chmod 555 TESTFILE |
6 | /mnt/ext_card/TESTDIR # ls -l |
7 | -r-xr-xr-x system sdcard_rw 0 2024-06-17 10:16 TESTFILE |
8 | /mnt/ext_card/TESTDIR # mount | grep ext_card |
9 | /dev/block/vold/179:33 /mnt/ext_card vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0 |
10 | /mnt/ext_card/TESTDIR # echo TEST>TESTFILE |
11 | /mnt/ext_card/TESTDIR # su app_173 |
12 | /mnt/ext_card/TESTDIR $ ls -l |
13 | -r-xr-xr-x system sdcard_rw 5 2024-06-17 10:19 TESTFILE |
14 | /mnt/ext_card/TESTDIR $ echo TEST > TESTFILE |
15 | sh: cannot create TESTFILE: Permission denied |
16 | . |
(Edit: tags korrigiert. - Mod.)
:
Bearbeitet durch Moderator
Beitrag #7685978 wurde vom Autor gelöscht.
Motopick schrieb: > Ein Android 4 wo die Welt noch in Ordnung war: Also vor der Einführung von SELinux (MAC), wo böswillige Apps alle Daten von unvorsichtig geschriebenen Apps abgreifen konnten, sowieso alle manuell angelegten Dokumente/Bilder, und durch Übernehmen eines einzelnen Systemdienstes Vollzugriff aus das System erhielten (wie z.B. beim berühmten Stagefreight Bug - allerdings konnte man hier SELinux durch das Exploiten von Kernel-Bugs umgehen). PS: Nur weil in deinem Beispiel die Apps keinen Zugriff mehr haben, hat der StorageManagerService, welcher vermutlich die Ordner anlegt, den schon. PPS: In aktuellen Android-Versionen (IIRC >= 11) haben Apps per Default keinen Zugriff auf Dateien direkt auf dem Datenträger, der User muss es manuell erlauben. Das ist für den Datenschutz viel wichtiger als die Möglichkeit, per root-Shell die Permissions einstellen zu können...
:
Bearbeitet durch User
> Das ist für den Datenschutz viel wichtiger als die > Möglichkeit, per root-Shell die Permissions einstellen zu können... Fuer meinen Datenschutz wuerde es mir reichen, wenn Guggel keinen Zugriff auf die Daten meines(!) Telefons haette. Beim Android 4 ging das jedenfalls noch (recht einfach). Da sorgten genau nur 2 Regeln in den iptables fuer Ruhe. Um den Rest kann ich mich dann naemlich selbst kuemmern. Selbst Apfelbenutzer sind von Guggels Schnueffelwut nicht sicher. Den Apfel verkauft Nutzerdaten fuer ein erkleckliches Suemmchen an diesen Reklameverein.
Motopick schrieb: > Da sorgten genau nur 2 Regeln in den iptables fuer Ruhe. In einem Custom ROM kannst du das auch alles machen bzw. die Google-Dienste direkt ganz entfernen. Das hat nichts mit dem grundlegenden Sicherheitsmodell von Android zu tun.
Niklas G. schrieb: > Motopick schrieb: >> Da sorgten genau nur 2 Regeln in den iptables fuer Ruhe. > > In einem Custom ROM kannst du das auch alles machen bzw. die > Google-Dienste direkt ganz entfernen. Das hat nichts mit dem > grundlegenden Sicherheitsmodell von Android zu tun. Am experimenteller IT bin ich nicht interessiert. 2 handgedengelte Regeln sind mir da lieber. Ueber die habe naemlich ich die voellige Kontrolle. Den Blaehstore habe ich im uebrigen schon lange entfernt.
Motopick schrieb: > Am experimenteller IT bin ich nicht interessiert. > 2 handgedengelte Regeln sind mir da lieber. Handgedengelt ist nicht experimentell? Apps können trotzdem alle möglichen Daten an ihre eigenen Server senden, oder an die Unzahl von Drittanbietern für "Metrics". Und da Apps ja bei Android 4 auch an alle Daten dran kamen...
Niklas G. schrieb: > Motopick schrieb: >> Am experimenteller IT bin ich nicht interessiert. >> 2 handgedengelte Regeln sind mir da lieber. > > Handgedengelt ist nicht experimentell? Nicht mehr. Einige zusaetzliche Regeln wuerden Zugriffe mitzaehlen. Die Zaehler stehen auf 0. > Apps können trotzdem alle > möglichen Daten an ihre eigenen Server senden, oder an die Unzahl von > Drittanbietern für "Metrics". Und da Apps ja bei Android 4 auch an alle > Daten dran kamen... Auch das nicht, wenn ich nicht will. Wenn die "Apps" ihre DNS-Abfragen machen, haben sie schon verloren. Mehr Traffic bekommen sie naemlich nicht. Die landen dann als "127.0.0.1 ad.yieldlab.net" in der hosts. Ein tcpdump und ein strace findet sich im uebrigen auch auf dem Fon. Fuer unterwegs. Ein tcpdump auf Port 53 in eine Logdatei ist auch ein netter Backgrundjob. Und im neuen Wischfon ist die Defaultpolicy der Firewall ein "Deny All". Und die kann auch DNS-Abfragen und (versuchte) Zugriffe protokollieren.
Motopick schrieb: > Auch das nicht, wenn ich nicht will. Wenn die "Apps" ihre DNS-Abfragen > machen, haben sie schon verloren. Dann funktioniert die App aber halt überhaupt nicht mehr. Was bringt WhatsApp, wenn es nicht mit dem WhatsApp-Server kommuniziert? Oder benutzt du ausschließlich Taschenrechner-Apps? Da könntest du auch per SELinux die Permission entziehen, überhaupt Sockets zu öffnen, spart die Fummelei mit iptables.
okay ich nehms zurück. war mir nicht bewusst dass der vfat Treiber das kann.
Niklas G. schrieb: > Motopick schrieb: >> Auch das nicht, wenn ich nicht will. Wenn die "Apps" ihre DNS-Abfragen >> machen, haben sie schon verloren. > > Dann funktioniert die App aber halt überhaupt nicht mehr. Was bringt > WhatsApp, wenn es nicht mit dem WhatsApp-Server kommuniziert? Oder > benutzt du ausschließlich Taschenrechner-Apps? Es bleibt genug uebrig, dass es Wert ist, offline benutzt zu werden. Und Wuzzup scheidet ja wohl ganz aus. Aber pscht: Ich hab Telegram auf dem alten Schlaufon. Und das redet immer nur mit genau einer IP-Adresse. Und sonst nuex. > Da könntest du auch per SELinux die Permission entziehen, überhaupt > Sockets zu öffnen, spart die Fummelei mit iptables. Ich finde iptables nicht fummelig. Fuer einfache Basisfunktionen kann man sich ja Wrapper schreiben, die die Benutzung vereinfachen. Also z.B. eine IP/IP-Range auf die Denyliste zu setzen und/oder da wieder zu entfernen.
Motopick schrieb: > Aber pscht: Ich hab Telegram auf dem alten Schlaufon. > Und das redet immer nur mit genau einer IP-Adresse. Wie stellst du sicher dass es keine privaten Daten an diese IP-Adresse sendet?
Niklas G. schrieb: > Motopick schrieb: >> Aber pscht: Ich hab Telegram auf dem alten Schlaufon. >> Und das redet immer nur mit genau einer IP-Adresse. > > Wie stellst du sicher dass es keine privaten Daten an diese IP-Adresse > sendet? Ich koennte es mir mit dem ADT/NDK selbst bauen.
Motopick schrieb: > Ich koennte es mir mit dem ADT/NDK selbst bauen. Du benutzt keine proprietäre App welche eine Internetverbindung braucht? Play Store?
Niklas G. schrieb: > Motopick schrieb: >> Ich koennte es mir mit dem ADT/NDK selbst bauen. > > Du benutzt keine proprietäre App welche eine Internetverbindung braucht? > Play Store? Die sind wenn dann geh4x0rt. Oder gekrueppelt. Je nachdem. Aber immer werbefrei! :) Manches gibt es ja auch umsonst, wenn man kein Deutscher ist. Z.B. Navigon mit DACH-Karten war in den U.S.A. foellig kostenfrei. :) Motopick schrieb: > Den Blaehstore habe ich im uebrigen schon lange entfernt.
Motopick schrieb: > Die sind wenn dann geh4x0rt. Oder gekrueppelt. Je nachdem. Und dann braucht man noch iptables?
Niklas G. schrieb: > Motopick schrieb: >> Die sind wenn dann geh4x0rt. Oder gekrueppelt. Je nachdem. > > Und dann braucht man noch iptables? Ja sicher. Schon um den Reklameverein vor die Tuer zu setzen. Auch gut gegen Werbespam.
Motopick schrieb: > Ja sicher. Schon um den Reklameverein vor die Tuer zu setzen. > Auch gut gegen Werbespam. Na dann, aktuelle Android-Versionen haben wohl stattdessen eBPF.
Niklas G. schrieb: > Motopick schrieb: >> Ja sicher. Schon um den Reklameverein vor die Tuer zu setzen. >> Auch gut gegen Werbespam. > > Na dann, aktuelle Android-Versionen haben wohl stattdessen eBPF. Das ist mir egal. ipfwadm haette die 2 Regeln noch nicht gekonnt, bei ipchains waere ich mir nicht sicher. Mit beiden haetten die jetzigen "Pruefregeln" aber auch ihre Aufgabe erfuellt. Das hat zwar jetzt gar nichts damit zu tun, aber: Immerhin kann ich das exiftool ohne GUI benutzen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.