Ich versuche, Dateien in das Verzeichnis /system/priv-app zu schreiben. Ich boote in die Wiederherstellung (TWRP) und führe die Adb-Shell aus.
~ # mount /system
~ # mount
rootfs on / type rootfs (rw,seclabel)
...
/dev/block/mmcblkXXXX on /system type ext4 (rw,seclabel,relatime,data=ordered)
Ich kann dann ausführen:
~ # mkdir /system/tmp
~ # touch /system/tmp/test
Das funktioniert gut: Ich habe kein Problem damit, /system zu ändern. (Ich kann auch Dinge aus /system/priv-app löschen.) Aber wenn ich dann versuche, nach /system/priv-app zu schreiben , bekomme ich Folgendes:
~ # mkdir /system/priv-app/test
mkdir: can't create directory '/system/priv-app/test': Read-only file system
~ # mount
rootfs on / type rootfs (rw,seclabel)
...
/dev/block/mmcblkXXXX on /system type ext4 (ro,seclabel,relatime,data=ordered)
Jetzt ist /system plötzlich schreibgeschützt gemountet! Berechtigungen und Besitz sind in /system und /system/priv-app identisch und ich laufe als root.
~ # ls -al /
...
drwxr-xr-x 18 root root 4096 Nov 25 07:32 system
~ # ls -al /system
...
drwxr-xr-x 59 root root 4096 Aug 5 1972 priv-app
In TWRP ist SELinux auf permissiv eingestellt:
~ # getenforce
Permissive
Ich verwende Lineage OS 14.1 (Android Nougat) auf einem Moto G 2015 (alias Moto G3). Es ist mit dem offiziellen Addon Lineage su verwurzelt. Ich habe auch Magisk ausprobiert und das gleiche Ergebnis erhalten.
Mir gehen die Ideen aus und ich kann die richtigen Suchbegriffe nicht finden, weil ich eine Menge Dinge ausprobiert habe und nichts gefunden habe.
Wie kann ich das Schreiben in /system/priv-app aktivieren?
Der Schutz von Android vor bösartigem Code war schon immer eine Priorität von Google, OEMs und SOC-Anbietern. Sogar der /system-Schreibschutz wurde von einigen OEMs auf Kernel-Ebene implementiert . Und standardmäßig wird Android /systemschreibgeschützt bereitgestellt, um beabsichtigte oder versehentliche Änderungen zu vermeiden, damit AVB/dm-verity ordnungsgemäß funktioniert. Nur OTA-Updates können die Systempartition ändern.
Wenn jedoch dm-verity beim Rooten des Geräts oder beim Flashen des benutzerdefinierten Kernels/ROM deaktiviert ist, können wir /system read/writeÄnderungen vornehmen. Einige Programme haben jedoch einen eingebauten Code, um zu prüfen, ob /system gemountet ist rw, und wenn ja, setzen Sie den Status auf zurück ro. Solid Explorer sagt:
Wenn der Einhängepunkt im r/o-Modus gemountet wird, wird er vorübergehend wieder in r/w gemountet. Nachdem der Vorgang abgeschlossen ist (erfolgreich oder nicht), stellt die App die Partition wieder in den R/O-Zustand.
TWRP hat auch eine Option mount_sys_ro_chk und mountet standardmäßig /system read-only .
Die Lösung besteht also darin, den Einhängepunkt in /systemetwas anderes zu ändern, da dies normalerweise nicht überprüft wird.
roEin weiterer Faktor, der das Mounten einer Partition erzwingen kann, ist die Mount-Option des Linux-Kernels errors=remount-ro . Diese Mount-Option ist normalerweise Standard für ein neu erstelltes Dateisystem:
~# tune2fs -l /dev/block/bootdevice/by-name/system | grep Error
Errors behavior: Remount read-only
Das Dateisystem wird also schreibgeschützt gemountet, wenn ein Fehler auftritt, zB Max Mount Counterreicht und e2fscknicht ausgeführt wird. Dies ist jedoch bei Android selten der Fall. Sie können das Kernel-Protokoll für solche Fehler anzeigen:
~# dmesg | grep mount
Das Ändern des Standardverhaltens wird nicht empfohlen und kann wirklich schädlich sein:
~# mkdir /system-temp
~# mount -o rw,errors=continue /dev/block/bootdevice/by-name/system /system-temp
die.cauchy