Kurz erklärt bedeutet Rooten einfach, ein kleines Progrämmchen namens „su“ am passenden Ort im Android-System abzuspeichern. Das hört sich einfacher an, als es in vielen Fällen ist und mit su alleine ist es dann doch nicht getan. Denn die Hersteller versuchen, ihr System vor einer solchen Änderung zu schützen. Deshalb gibt es nun eine neue Root-Methode von Chainfire, die einen Trick anwendet.
Mit einer neuen Root-Methode von Chainfire lassen sich viele Smartphones ohne Gefahr rooten, doch systemless Root ist kein Wundermittel, lediglich ein sehr clever programmierter Workaround, der in erster Linie Entwickler von Root-Apps betrifft. Aber auch als Root-App-Nutzer solltest du wissen, was beim Rooten passiert. Schließlich birgt das Rooten gewisse Risiken, gerade was zukünftige Updates betrifft. Dieser Artikel erklärt dir, wie systemless Root funktioniert, ob und wie es sich auf OTA-Updates auswirkt und wo die Vor- und Nachteile der neuen Methode liegen.
Mit der Einführung von Android Pay hat Google ein sehr großes Interesse daran, dass Android-Smartphones nicht gerootet werden, denn über die Root-Rechte könnten potentiell vertrauliche Daten ausgelesen oder die Bezahlfunktion manipuliert werden. Deshalb bringt Android 6 „Marshmallow“ erneut ein paar zusätzliche Sicherheitsfunktionen mit, die das Rooten erschweren oder dem Nutzer die Lust am Rooten vergehen lassen.
WICHTIG: Das hier ist keine Root-Anleitung und somit auch keine Anleitung, wie man die neue Root-Möglichkeit von Chainfire benutzt. Du findest aber einen entsprechenden Artikel im Android-User-Archiv. Wenn du noch keine Erfahrung mit Root-Rechten hast, dann liest du am besten unseren Grundlagenartikel zum Thema Root. Für das Verständnis des Artikels sind Grundlagenkenntnisse in Linux von Vorteil. Ich habe aber versucht, die Fachbegriffe so gut wie möglich zu erklären.
Root ohne System?
Der Begriff „systemless“ ist mehrdeutig. Einerseits versteht Chainfire darunter, dass das su-Binary nicht in die Partition /system installiert werden muss. Andererseits ist die neue Methode auch geräteunabhängig, funktioniert also auf praktisch jedem Androiden ab Version 6.0 „Marshmallow“ und für die meisten Samsung-Geräte auch schon mit Version 5.1 „Lollipop“. Benutzt du also SuperSU fürs Rooten, dann wählt das Tool nun automatisch die passende Lösung.
Google hat mit Android 6.0 die Sicherheit des Systems noch einmal verschärft und unter anderem die /system-Partition vorsätzlich so klein gehalten, dass Änderungen daran kaum möglich sind, ohne zum Beispiel nicht benötigte System-Apps zu löschen. Zusammen mit weiteren Verschärfungen am SE Linux System hat das Chainfire auf die Idee des Rootens ohne /system-Partition gebracht.
Und so funktioniert es
Beim klassichen Root-Vorgang werden das su-Binary, die SuperUser-App, Bibliotheken und Startscripte in die Verzeichnisse /system/bin, /system/etc/ und /system/xbin installiert. Die genaue Liste findet sich in den Scripten der SuperSu-Zip-Datei, die für den Root-Vorgang benötigt wird. Ein Daemon-Prozess kümmert sich mit Hilfe eines Init-Scripts dafür, dass beim Boot-Vorgang die Root-Rechte „aktiviert“ werden und im laufenden Android-System vorhanden sind. Chainfire empfiehlt diese Art zu rooten bis und mit Android 5.1.
„Systemless Root verändert keine Dateien unter /system, daher der Name.“
Der neue systemless Root-Vorgang lässt die /system-Partition außen vor und hängt statt dessen sämtliche benötigten Dateien und Bibliotheken unter dem Verzeichnis /su ein. In der ZIP-Datei befindet sich dazu ein vorgefertigtes Abbild su.img, das während des Root-Vorgangs in /data oder /cache abgelegt wird, anschließend wird das Ganze via Loopmount Device nach /su eingehängt. Auch die SuperSU-App (die APK-Datei, die es auch im Play Store zum Download gibt), landet vorübergehend unter /data oder /cache.
Um das Abbild während des Systemstarts einzuhängen und dem Android-System die neuen Pfade unter /su bekannt zu machen, sind lediglich ein paar Änderungen an der Initial Ramdisk notwendig, verändert wird also nur die /boot-Partition, aber nicht das Systemverzeichnis. In der Boot-Ramdisk legt Chainfire die Datei
/sbin/launch_daemonsu.sh
ab. Sie kümmert sich nicht nur darum, dass die Root-Rechte bei jedem Start zur Verfügung stehen, sondern biegt notfalls ein bereits bestehendes su-Binary auch über mount -o bind so um, dass dieses auf Chainfires su-Binary verweist. Die folgenden Zeilen im Script installieren bei Bedarf die SuperSU-App und räumen anschließend die nicht mehr benötigten Daten auf:
# do we have an APK to install ?
if [ -f "/cache/SuperSU.apk" ]; then
cp /cache/SuperSU.apk /data/SuperSU.apk
rm /cache/SuperSU.apk
fi
if [ -f "/data/SuperSU.apk" ]; then
log_print "installing SuperSU APK in /data"
APKPATH=eu.chainfire.supersu-1
for i in `ls /data/app | grep eu.chainfire.supersu | grep -v eu.chainfire.supersu.pro`; do
APKPATH=$i
rm -rf /data/app/$APKPATH
break;
done
log_print "target path: /data/app/$APKPATH"
mkdir /data/app/$APKPATH
chown 1000.1000 /data/app/$APKPATH
chmod 0755 /data/app/$APKPATH
chcon u:object_r:apk_data_file:s0 /data/app/$APKPATH
cp /data/SuperSU.apk /data/app/$APKPATH/base.apk
chown 1000.1000 /data/app/$APKPATH/base.apk
chmod 0644 /data/app/$APKPATH/base.apk
chcon u:object_r:apk_data_file:s0 /data/app/$APKPATH/base.apk
rm /data/SuperSU.apk
# just in case
REBOOT=true
fi
Der „Rest“ spielt sich in der Ramdisk ab: Chainfire modifiziert die fstab.* Datei, die sich im Wurzelverzeichnis befindet und nach dem Gerätenamen benannt ist (also beim Nexus 5 lautet sie fstab.hammerhead und fügt der Variablen $PATH das Verzeichnis /su/bin hinzu. Letzerer Schritt ist deshalb notwendig, weil das Linux-System nur in bestimmten Verzeichnissen nach Programmen sucht. Ohne diesen Eintrag würde Android somit das neue Binary gar nicht finden.
WICHTIG: systemless Root geht in jedem Fall von einem unveränderten System aus. Wenn du die neue Root-Methode benutzen möchtest, musst du dein Android-Gerät also zunächst wieder in den Ursprungszustand zurückversetzen.
Auch beim Patchen der Boot-Dateien gibt es einen wichtigen Punkt zu beachten. Die Scripte von Chainfire kommen aktuell nur mit dem Standard Boot Image Format von Android bzw. via Gip komprimierten Ramdisks klar. Falls du einen Custom Kernel benutzt und der Kernel-Entwickler eventuell mit bzip2 oder einer anderen Komprimierung arbeitet, dann klappt der systemless Root aktuell nicht. Du findest in jedem Fall nach dem geglückten Patch-Vorgang ein Backup des Original Boot-Abbilds unter /data/stock_boot_.img.gz.
Und die OTA-Dateien?
Wenn du die monatlichen Sicherheitsupdates von Google per OTA installieren möchtest, dann hilft dir auch der neue systemless Root-Vorgang nicht wirklich. Denn zwar bleibt die /system-Partition unangetastet, aber die Boot-Partition muss verändert werden, was zur Folge hat, dass die OTA-Updates abgebrochen werden. Doch so weit musst du gar nicht überlegen, denn zur Installation von SuperSU benötigst du in jedem Fall ein Custom-Recovery (Chainfire empfielt TWRP) und mit einem Custom Recovery bist du seit Android 5.1 „draußen“ was OTA-Updates anbelangt. TWRP bietet zwar ebenfalls die Option an, die Systempartition unangetastet zu lassen, wirklich brauchbar ist das Custom-Recovery so aber nicht und du darfst dann auch keine Root-Apps benutzen, die irgendetwas an der Systempartition ändern. Also schon ganz viele Einschränkungen, da kann man gleich aufs Rooten verzichten…
[Update: Mai 2016] Laut mehreren Berichten funktionieren die OTA-Updates weiterhin, wenn du für die Installation nicht den Updater des Systems sondern das Tool Flashfire benutzt!
Eine kleine Verbesserung gibt es aber trotzdem, denn theoretisch kannst du die Systempartition von Hand flashen, ohne dass sich das Android-System beschweren würde und musst lediglich ein Backup der ursprünglichen Boot-Dateien bereithalten, um das komplette OTA einspielen zu können. Dieses Backup erstellt SuperSU beim Flashen automatisch (siehe oben). Insofern ist es einfacher als früher, aber immer noch Handarbeit.
Gefahren/Nachteile
Einige Root-Apps (Apps, die Root-Rechte benötigen) suchen das su-Binary fest unter /system/bin/. Diese Apps funktionieren bei diesem neuen Root-Vorgang nicht mehr, weil das su-Binary unter /su/bin/ liegt. Hier sind die Devs gefragt, ihre Anwendungen so anzupassen, dass einfach nach dem su-Binary gesucht wird, ohne konkrete Pfadangabe.
Die Lösung von Chainfire, die benötigten Dateien einfach in einem Abbild zu speichern und dieses „on demand“ im Linux-Dateisystembaum einzuhängen ist so genial, dass sie leicht Nachahmer finden könnte. Doch auf die gleiche Art und Weise lässt sich auch eine Malware programmieren, die dann trotz schreibgeschützter Systempartition so ihre Binaries ausführen kann. Das ist jetzt nicht die Schuld von Chainfire, aber generell sollte man sich als Root-Nutzer immer bewusst sein, dass das Gefahrenpotential mit dem Rooten steigt.
Das von Chainfire generierte Verzeichnis /su ist zudem prädestiniert, um Zielpunkt von Angriffen zu werden. Hier müsste man die Methode so ändern, dass jedes Android-Gerät einen anderen Verzeichnisnamen benutzt.
Last but not least ist die Methode noch recht jung, kann also jetzt noch nicht erkannte Nebenwirkungen mit sich bringen…
Fazit: Katze und Maus
Die neue Methode von Chainfire ist so clever, dass er damit sogar Google austricksen konnte. Denn Android Pay funktioniert eigentlich auf gerooteten Geräten nicht. Die Prüfung von Google und vieler weiterer Apps beschränkt sich aber aktuell noch auf ein su-Binary irgendwo unter /system/bin oder einfach in /system. Das dürfte aber nur eine Frage der Zeit sein, dann prüfen auch alle Apps, die bisher mit Root-Rechten nicht funktionierten, ob es auf dem Gerät ein systemless Root gibt. Einen wirklichen Vorteil bringt die neue Methode dennoch mit: klappt beim Rooten etwas nicht, dann ist normalerweise das Android-System noch benutzbar. Zudem lässt sich der Root-Vorgang leichter rückgängig machen als mit der traditionellen Methode.
Vielen Dank, dass du diesen Artikel gekauft hast! Bei Fragen oder Problemen hilft dir unser Support über die E-Mail-Adresse andy@android-user.de. Bitte als Betreff den Support-Code 108272 angeben.
