Kiwi++Soft
Ehrenmitglied
- 32.707
Öfter hört man davon, dass es unter Lollipop Probleme mit Root geben soll/kann. Dazu möchte ich jetzt mal eine Erklärung liefern, damit es etwas klarer wird, um was es genau geht.
Wie wurden bis (einschließlich) Android 4.2 Root-Rechte an einen Prozess gegeben:
Dazu wurde in die /system Partition in das Verzeichnis /system/bin oder /system/xbin ein Binary eingefügt, das sogenannte su-Binary, das nicht nur die klassischen Unix-Rechte 755 vergeben, sondern das etwas unbekanntere Recht 6755, was anzeigt, dass ein Prozess der das Binary su aufruft, in den Benutzer/Gruppen-Kontext des Eigentümer des binary wechseln darf. Da das su-Binary dem User Root gehört, durfte der Prozess, der das su-Binary aufrief, in den Benutzer-Kontext von Root wechseln. Kurz gesagt: Er bekam 'Root-Rechte'!
Dieses su-Binary hat dann mit den Root-Rechten eine Shell gestartet (eine Shell ist ein prozess, der auf Kommandos hört und diese ausführt, so dass der der Prozess, der das su Binary gerufen hat, diesem Kommandos zu ausführen übergeben konnte.
Wie wurden ab Android 4.3 Root-Rechte an einen Prozess gegeben:
Seit Android 4.3 verhinder SELINUX, dass ein Kind-Prozess von Zygote (dass sind alle App-Prozesse) den Benutzer-Kontext wechseln kann. Daher funktionierte unter Android 4.3 das kalssische su-Binary nicht mehr!
Der Trick, den man dann nutzte, um Root-Rechte an einen App-Prozess zu geben, ist relativ einfach:
Man nutzt einen Hintergrund-Prozess (in Linux-Sprache Daemon genannt, hier der sogenannte su-deamon), der ähnlich einen Telnet-Deamon auf einen lokalen Socket hört und mit Root-Rechten die von dort empfangenen Shell-Kommandos in einer eigenen Shell ausführt.
Das su-Binary selbst hat dann keine Shell mehr unter anderem User-Kontext mehr gestartet (denn das ist seit Android 4.3 ja nicht mehr möglich), sondern diente nur als Client für den su-deamon.
Doch wie wurde dieser su-Daemon gestartet?
In dem Boot-Image eines Android-Gerätes ist in gezippter Form ein Image des root-Filesystems enthalten und darin eine Datei namens init.rc. In dieser wird ein Service zum 'Restoren' des Recovery aufgerufen. Dieser Service ruft ein Script /system/etc/install-recovery.sh
In dieses Script wurde das Starten des su-Daemon eingeklinkt.
Was hat sich zu Android 5.0 nun verändert?
Unter Lollipop wird der o.a. Recovery-Restore-Service jedoch so stark in seinen Möglichkeit eingezwängt, dass er nicht mehr als 'Träger-Service' für den 'su-deamon' dienen kann. Dies kommt dadurch, dass unter Android 5.0 jeder Service seinen eigenen SELINUX Kontext bekommt, der ihm genau nur das erlaubt, was für seine Aufgabe nötig ist. Somit kann ein Recovery-Install-Prozess viel weniger, als ein su-Daemon benötigen würde, um sinnvollen Root Access zu gewährleisten.
Folglich muss man einen alternativen Service in einem mit genug Rechten ausgestatten Kontext starten.
Dies könnte man beispielsweise in einer modifizierten init.rc tun!
Dafür muss jedoch das Boot-Image modifiziert werden. Das heißt, man benötigt ein Tool, dass das Boot-Image extrahiert, entpackt, das init.rc modifiziert und das geänderte Root-Filesystem wieder zu einem Boot-Image zurück verpackt und wieder hoch lädt.
Das ist zwar prinzipiell bei Geräten mit nicht gesperrten Bootloader möglich, aber das Rooten ohne den Bootloader zu öffnen ist damit schon mal nicht so einfach möglich. Bei vielen Geräten/Herstellern ist das öffnen des Bootloaders ein irreversibler Vorgang, den viele User scheuen!
Dazu kommt noch, dass die Hersteller hingehen können, und Android-Updates für ihre Geräte anbieten können, in denen sie auch den Bootloader updaten, und dann ist es u.U aus mit Bootloader öffnen.
Bei seinen neueren Geräten hat Acer beispielsweise gesperrte Bootloader verbaut. In den älteren Geräten konnte der Bootloader noch geöffnet werden. Aber jetzt bietet Acer seit ein paar Wochen für das A21x ein Update (für das 2 Jahre alte Android 4.1.1, auf immer noch eine Android 4.1.1 Version!!!) an, bei dem sie den Boot-Loader tauschen (womöglich gegen einen gesperrten, das werde ich demnächst mal untersuchen)!
Was muss also für ein Root unter Android 5.0 passieren:
Der Geräte-Spezifische Ansatz:
Die Entwickler, die ein bestimmtes Gerät betreuen, und dafür alternative Boot-Images anbieten (z.B. Custom-Kernel/Custom-ROMs) können leicht ein Boot-Image anbieten, das einen su-Daemon startet. Welcher das jetzt ist (Chainfire, Koush, oder, so wie bei den von mir betreuten Geräten, ein selbst geschriebener) spielt keine Rolle. Damit ist Root unter Android 5.0 möglich.
Der Generische Ansatz:
Hierfür müsste man ein 'PC-Tool' schreiben, das wie oben beschrieben, das Boot-Image modifiziert. Eventuell wäre auch vorstellbar, solch ein Tool für das Android-Gerät selbst zu schreiben, dass dann im Recovery-Modus gestartet werden könnte.
Voraussetzung (für beide Ansätze):
Beide Ansätze würden entweder ein Custom-Recovery oder einen 'Öffenbaren Bootloader' erfordern, oder es müsste ein Exploit gefunden werden, über den man ein modifiziertes Boot-Image in das Gerät einbringen kann.
Wichtiger Hinweis:
Dieses Thema ist eine technische Erklärung. Technische Fragen/Ergänzungen zu den hier vorgetragen Dingen können hier gestellt werden, aber Diskussionen um Konsequenzen, die nicht technischer Natur sind, bitte nur in diesem Thread: https://www.android-hilfe.de/forum/...ipop.1924/hat-es-sich-ausgerootet.623995.html
Wie wurden bis (einschließlich) Android 4.2 Root-Rechte an einen Prozess gegeben:
Dazu wurde in die /system Partition in das Verzeichnis /system/bin oder /system/xbin ein Binary eingefügt, das sogenannte su-Binary, das nicht nur die klassischen Unix-Rechte 755 vergeben, sondern das etwas unbekanntere Recht 6755, was anzeigt, dass ein Prozess der das Binary su aufruft, in den Benutzer/Gruppen-Kontext des Eigentümer des binary wechseln darf. Da das su-Binary dem User Root gehört, durfte der Prozess, der das su-Binary aufrief, in den Benutzer-Kontext von Root wechseln. Kurz gesagt: Er bekam 'Root-Rechte'!
Dieses su-Binary hat dann mit den Root-Rechten eine Shell gestartet (eine Shell ist ein prozess, der auf Kommandos hört und diese ausführt, so dass der der Prozess, der das su Binary gerufen hat, diesem Kommandos zu ausführen übergeben konnte.
Wie wurden ab Android 4.3 Root-Rechte an einen Prozess gegeben:
Seit Android 4.3 verhinder SELINUX, dass ein Kind-Prozess von Zygote (dass sind alle App-Prozesse) den Benutzer-Kontext wechseln kann. Daher funktionierte unter Android 4.3 das kalssische su-Binary nicht mehr!
Der Trick, den man dann nutzte, um Root-Rechte an einen App-Prozess zu geben, ist relativ einfach:
Man nutzt einen Hintergrund-Prozess (in Linux-Sprache Daemon genannt, hier der sogenannte su-deamon), der ähnlich einen Telnet-Deamon auf einen lokalen Socket hört und mit Root-Rechten die von dort empfangenen Shell-Kommandos in einer eigenen Shell ausführt.
Das su-Binary selbst hat dann keine Shell mehr unter anderem User-Kontext mehr gestartet (denn das ist seit Android 4.3 ja nicht mehr möglich), sondern diente nur als Client für den su-deamon.
Doch wie wurde dieser su-Daemon gestartet?
In dem Boot-Image eines Android-Gerätes ist in gezippter Form ein Image des root-Filesystems enthalten und darin eine Datei namens init.rc. In dieser wird ein Service zum 'Restoren' des Recovery aufgerufen. Dieser Service ruft ein Script /system/etc/install-recovery.sh
In dieses Script wurde das Starten des su-Daemon eingeklinkt.
Was hat sich zu Android 5.0 nun verändert?
Unter Lollipop wird der o.a. Recovery-Restore-Service jedoch so stark in seinen Möglichkeit eingezwängt, dass er nicht mehr als 'Träger-Service' für den 'su-deamon' dienen kann. Dies kommt dadurch, dass unter Android 5.0 jeder Service seinen eigenen SELINUX Kontext bekommt, der ihm genau nur das erlaubt, was für seine Aufgabe nötig ist. Somit kann ein Recovery-Install-Prozess viel weniger, als ein su-Daemon benötigen würde, um sinnvollen Root Access zu gewährleisten.
Folglich muss man einen alternativen Service in einem mit genug Rechten ausgestatten Kontext starten.
Dies könnte man beispielsweise in einer modifizierten init.rc tun!
Dafür muss jedoch das Boot-Image modifiziert werden. Das heißt, man benötigt ein Tool, dass das Boot-Image extrahiert, entpackt, das init.rc modifiziert und das geänderte Root-Filesystem wieder zu einem Boot-Image zurück verpackt und wieder hoch lädt.
Das ist zwar prinzipiell bei Geräten mit nicht gesperrten Bootloader möglich, aber das Rooten ohne den Bootloader zu öffnen ist damit schon mal nicht so einfach möglich. Bei vielen Geräten/Herstellern ist das öffnen des Bootloaders ein irreversibler Vorgang, den viele User scheuen!
Dazu kommt noch, dass die Hersteller hingehen können, und Android-Updates für ihre Geräte anbieten können, in denen sie auch den Bootloader updaten, und dann ist es u.U aus mit Bootloader öffnen.
Bei seinen neueren Geräten hat Acer beispielsweise gesperrte Bootloader verbaut. In den älteren Geräten konnte der Bootloader noch geöffnet werden. Aber jetzt bietet Acer seit ein paar Wochen für das A21x ein Update (für das 2 Jahre alte Android 4.1.1, auf immer noch eine Android 4.1.1 Version!!!) an, bei dem sie den Boot-Loader tauschen (womöglich gegen einen gesperrten, das werde ich demnächst mal untersuchen)!
Was muss also für ein Root unter Android 5.0 passieren:
Der Geräte-Spezifische Ansatz:
Die Entwickler, die ein bestimmtes Gerät betreuen, und dafür alternative Boot-Images anbieten (z.B. Custom-Kernel/Custom-ROMs) können leicht ein Boot-Image anbieten, das einen su-Daemon startet. Welcher das jetzt ist (Chainfire, Koush, oder, so wie bei den von mir betreuten Geräten, ein selbst geschriebener) spielt keine Rolle. Damit ist Root unter Android 5.0 möglich.
Der Generische Ansatz:
Hierfür müsste man ein 'PC-Tool' schreiben, das wie oben beschrieben, das Boot-Image modifiziert. Eventuell wäre auch vorstellbar, solch ein Tool für das Android-Gerät selbst zu schreiben, dass dann im Recovery-Modus gestartet werden könnte.
Voraussetzung (für beide Ansätze):
Beide Ansätze würden entweder ein Custom-Recovery oder einen 'Öffenbaren Bootloader' erfordern, oder es müsste ein Exploit gefunden werden, über den man ein modifiziertes Boot-Image in das Gerät einbringen kann.
Wichtiger Hinweis:
Dieses Thema ist eine technische Erklärung. Technische Fragen/Ergänzungen zu den hier vorgetragen Dingen können hier gestellt werden, aber Diskussionen um Konsequenzen, die nicht technischer Natur sind, bitte nur in diesem Thread: https://www.android-hilfe.de/forum/...ipop.1924/hat-es-sich-ausgerootet.623995.html
