root Besonderheiten (systemless root)

[bbfh]

Hallo zusammen,

ich habe mein Oneplus3 nach der Anleitung hier gerooted und wurde dabei zum ersten mal mit dem Thema systemless root konfrontiert. Finde ich grundsätzlich ganz okay, aber so ganz verstanden habe ich es nicht.

Es funktioniert bei mir
Titanium Backup
AdAway
Better Battery Stats
Busybox
BuildProb Editor

Es funktioniert nicht (es kommt erst gar nicht zur Abfrage der root Rechte)
Es Datei Explorer
Tasker
Secure Settings

Mit Secure Settings und Tasker würde ich gerne GPS toggeln. Wlan toggeln funktioniert scheinbar schon. Für GPS braucht es aber die Root-Funktion von secure settings.

Hat das schon jemand zum laufen bekommen? Gibt es auch ein volles root (ohne systemless)? Ist dann Android Pay das einzige, was nicht mehr funktioniert?

 

[Yussuf76]

@bbfh
Im one plus forum habe ich im thread zum Thema root gelesen, das der es Explorer da ein problem hat, weil er root falsch abfragt.

 

[bbfh]

Wird dann wahrscheinlich für SecureSettings auch so sein. Hab jetzt mittlerweile auch gelesen, dass es an ES Datei Explorer liegt. Warten wir halt mal ab.

 

[rudolf]

Leider sind manche Apps nicht gerade sauber programmiert, so dass die root-abfrage scheitert. Diese Apps bekommen aber sicherlich bald ein update.
Systemless root heisst übrigends das der Bootloader geändert wird und die nötigen Programme in der /data partition landen. Also bleibt die /system Partition im Gegensatz zu früher unverändert. Und ein werksreset emtfernt root.
Der systemless root wird bei Android 6 standard sein.
Leider nur englisch, aber gut erklärt: What Is “Systemless Root” on Android, and Why Is It Better?

 

[ooo]

Systemless root heisst übrigends das der Bootloader geändert wird

Falsch. - Nicht der Bootloader (die bootloader-Partition) wird geändert, sondern der Inhalt des Boot-Images (die boot-Partition).
Die boot-Partition enthält einen Kernel und ein initrd-Image (ramdisk). - Die ramdisk wird von SuperSU (TWRP flashable .zip) im systemless-Mode inhaltlich verändert, wieder zusammen mit dem vorher entpackten Kernel in ein gepatchtes neues boot-Image überführt und abschließend geflasht (analog zu fastboot flash boot <new-boot-systemless>.img oder cat <new-boot-systemless>.img > /dev/block/mmcblk<n>).
[doublepost=1466623538,1466620270][/doublepost]Edit:

Und ein werksreset emtfernt root.

Auch das ist nicht richtig (bei systemless root). - Da die systemless gepatchte boot-Partition die Änderungen enthält (Änderungen an fstab bzgl. /su-Mount-Point für das in data oder im cache befindliche su.img, darin befindliche su binaries, overlapped file systems, bind mounts, default.prop etc. - nicht gemeint ist hier die in data befindliche .apk), ist die ROM nach einem regulären Factory Reset nach wie vor gerootet, evtl. sogar ganz ohne Kontrolle (fehlende SuperSU.apk), zumindest aber in einem undefinierten (fehlerhaften) Zustand. - Bei bereits gerooteten ROMs (CyanogenMod, pre-rooted CyanogenOS, pre-rooted Oxygen OS etc.) wird die integrierte Root-Funktiionalität wieder deaktiviert, das ist richtig, ist aber thematisch nicht relevant bzgl. "systemless root".

(Bei einem Factory Reset werden die Partitionen recovery, boot und system i. d. R. überhaupt nicht angefasst. - De-Rooten kann man mit dem Flashen des originalen boot.img. - Vollständig (ganz sauber) De-rooten kann man mit Factory Reset + Flashen des originalen boot.img)

Ramdisk backups

To reduce the impact of lost boot image backups for the future, starting v2.74, the SuperSU ZIP installer (and thus also CF-Auto-Root) will backup changed files in the boot image ramdisk to the ramdisk itself.

While this backup is not good enough to restore your original boot image to the exact state required to perform an incremental OTA, it should be good enough to be able to re-flash SuperSU even if the full boot image backup got lost - though I make no claims as to what happens if you mix it with custom kernels.

Quelle:
Chainfire – Google+

 

[bbfh]

Also, ich habe jetzt eine Lösung gefunden, mit der SuperSu wieder im Kompatibilitätsmodus läuft.

I have figured out a way to get Secure Settings to work on MM with Systemless…

Hat bei mir prima funktioniert. Nachteil: Android Pay funktioniert dann nicht mehr. Da ich nun rausgefunden habe, dass meine Bank das nicht unterstützt, kann ich da vorerst drauf verzichten. Dann sind mir SecureSettings lieber.

 

[ooo]

Hier ist mal eine (derzeit) aktuelle Liste der Flags/Switches/Variablen für den TWRP flashable <SuperSU>.zip:
(Achtung: Nicht jedes Flag/jedeVariable gilt für jede Version von SuperSU)

# Overridable variables (shell, /system/.supersu, /cache/.supersu, /data/.supersu):
#  SYSTEMLESS - Do a system-less install? (true/false, 6.0+ only)
#  PATCHBOOTIMAGE - Automatically patch boot image? (true/false, SYSTEMLESS only)
#  BOOTIMAGE - Boot image location (PATCHBOOTIMAGE only)
#  STOCKBOOTIMAGE - Stock boot image location (PATCHBOOTIMAGE only)
#  BINDSYSTEMXBIN - Poor man's overlay on /system/xbin (true/false, SYSTEMLESS only)
#  PERMISSIVE - Set sepolicy to fake-permissive (true/false, PATCHBOOTIMAGE only)
#  KEEPVERITY - Do not remove dm-verity (true/false, PATCHBOOTIMAGE only)
#  KEEPFORCEENCRYPT - Do not replace forceencrypt with encryptable (true/false, PATCHBOOTIMAGE only)
# Shell overrides all, /data/.supersu overrides /cache/.supersu overrides /system/.supersu

(Wie immer gilt: erst informieren, was was genau macht, Backup, dann probieren ...)

 

[rudolf]

@ooo
Bitte erkläre mir mal wie denn das Gerät noch gerootet sein soll wenn die su.img weg ist.

 

[ooo]

@rudolf - Okay, ich war auch nicht präzise im zweiten Teil. - Natürlich ist die /data/su.img erstmal "offiziell" weg (nach deinem Factory Reset), aber deine OTAs fliegen dir wegen dem gepatchten boot.img immer noch um die Ohren, wenn die Checksums durch das Stock-Recovery bzw. das updater-script überprüft werden. - Jemand Unbedarftes (oder ein Dritter, für den ein solches Gerät entsprechend vorbereitet wurde), der danach ein TWRP Restore von data vornimmt, bekommt das /data/su.img zurück und wundert sich dann mit einem systemless-gepatchten boot.img über sein plötzliches root (evtl. ohne SuperSU-Kontroll-App, obwohl er das vllt. gar nicht wollte), wenn er die Sicherheitslücke überhaupt bemerkt? - Ich finde so etwas irgendwie uncool ... (es gibt auch noch andere Möglichkeiten, die su.img - in "böser Absicht" - zu erhalten, was aber hier eher nicht hingehört ...)

Wer ohne Factory Reset manuell sauber de-rooten möchte (um data beizubehalten und OTAs zu installieren), muss die originale boot.img flashen und die Datei /data/su.img löschen (geht evtl. auch alles komplett mit fastboot boot <twrp>.img; TWRP > Install > Image > boot.img > boot > GO und TWRP > Advanced > Filemanager > /data/su.img > Delete file > GO). Und evtl. vorher das Verzeichnis /.subackup/ in Android löschen.

Und die Datei /data/su.img löschen muss man für ein OTA nicht. - Es genügt, die originalen Partitionen recovery, boot und system zu haben (manche Stock-ROMs schauen sich auch an, ob die logo-Partition noch original ist). - Nach dem OTA ist wieder systemless zu rooten (TWRP > Install > SuperSU.zip).