Root-Zugriff unter Android, Stand 2018

Bereits 2013 habe ich über das Thema „Root-Zugriff unter Android“ geschrieben. Seitdem hat sich die Ausrichtung von Android selbst stark verändert.

Was vor fünf Jahren noch wenig verbreitet war, ist mittlerweile der Normalzustand: Filme werden mit Diensten wie Netflix auch auf mobilen Geräten betrachtet und Spiele wie Pokémon GO erwirtschaften enorme Umsätze (Stand Ende 2017 etwa 890 Mio. USD). Für die Anbieter solcher Dienste ist es natürlich wichtig, dass die Daten der Apps dabei nicht durch Dritte zugänglich sind – etwa um DRM-Mechanismen zu schützen.

Ein weiterer Bereich sind Bezahldienste, wie Google Pay, das 2015 vorgestellt wurde – auch hier ist es wichtig, dass keine Dritten an vertrauliche Daten gelangen können.

SafetyNet

Als Schutzmaßnahme hat Google bereits 2015 einen neuen Mechanismus unter dem Namen „SafetyNet“ eingeführt. Damit haben Anbieter von Apps die Möglichkeit, die Installation oder Benutzung von Apps zu verhindern, wenn das System bestimmte Sicherheitsanforderungen nicht erfüllt – etwa weil die Möglichkeit des Root-Zugriffs erkannt wurde oder eine modifizierte Android-Version eingesetzt wird.

Eine ausführlichere Beschreibung von findet man in der

Das bedeutet aber auch, dass die lange Zeit übliche Methode mit einer modifizierten Systempartition und Tools wie „SuperSU“ nicht mehr nutzbar ist, weil dann viele Apps die Benutzung verweigern.

Systemless Root

Die lange Zeit übliche Methode zur Bereitstellung des Root-Zugriff war es, das Programm /system/bin/su oder /system/xbin/su bereitzustellen und eine App zur Steuerung des Zugriffs zu installieren, wie SuperSU. Eine der Prüfungen von SafetyNet besteht daher darin, die Existenz dieses Programms zu erkennen.

Ein alternativer Ansatz ist es, nur noch das Boot-Image anzupassen, aber keine Änderungen mehr in /system vorzunehmen. Ein Vorteil dieser Methode ist, dass aus Sicht von SafetyNet kein Root-Zugriff besteht und Apps, die eine erfolgreiche SafetyNet-Prüfung voraussetzen, weiterhin nutzbar bleiben.

Root-Zugriff mit Magisk

Der Name „Magisk“ ist ein Kunstwort aus „Magic Mask“. Dieses Programm verbindet Root-Zugriff mit Erweiterungen durch Module zur Modifikation des Systems ohne Änderungen in /system vornehmen zu müssen – so als würde man dem System eine Maske aufsetzen. Hinzu kommt die Möglichkeit, die Existenz von Magisk vor Apps zu „verstecken“.

Ein großer Vorteil gegenüber SuperSU ist die Tatsache, dass der Quelltext von Magisk vollständig auf Github offengelegt ist. Siehe auch https://github.com/topjohnwu/Magisk. Das gilt auch für die Module zu Magisk, die man auf https://github.com/Magisk-Modules-Repo findet.

Installation

Voraussetzung für die Installation von Magisk ist ein Custom Recovery, wie TWRP, wie ich es in meinem Beitrag zu CarbonROM auf dem Sony Xperia Z3 Compact beschrieben habe. Nachdem man die aktuelle Version von https://github.com/topjohnwu/Magisk/releases heruntergeladen hat, wird diese dann in TWRP auf dem üblichen Weg installiert. Im Rahmen der Installation modifiziert das Installationsskript von Magisk das Boot-Image und richtet die App „Magisk-Manager“ ein, mit der dann im laufenden Betrieb die Konfiguration erfolgt.

Hatte man SuperSU bereits installiert, muss man in der Regel vor der Installation von Magisk das genutzte CustomROM in TWRP noch einmal neu schreiben lassen, um die Modifikationen durch SuperSU zuverlässig zu entfernen. Vorhandene Apps und Daten werden dabei nicht gelöscht. Das CustomROM darf auch keinen Root-Zugriff integriert haben. Alternativ kann man die vorgesehenen Wege zur Entfernung des Root-Zugriffs verwenden, wie etwa bei LineageOS, für das ein entsprechendes Skript für TWRP angeboten wird. Wird dieser Punkt nicht beachtet, ist es später schwierig bis unmöglich, eine erfolgreiche SafetyNet-Prüfung zu erreichen.

Magisk Manager

Über die App „Magisk Manager“ wird sowohl der Root-Zugriff als auch die Konfiguration von Magisk und Erweiterungen über Module vorgenommen.

Im Startbildschirm der App sieht man auf einen Blick, ob man bereits die aktuellste Version von Magisk installiert hat und hat die Möglichkeit, eine SafetyNet-Prüfung auszuführen. Letzteres erfordert den Zugriff auf Komponenten von Google, die nicht Bestandteil von Magisk sind, weshalb bei der erste Ausführung dieser Prüfung explizit zugestimmt werden muss.

Über das Menü erreicht man die verschiedenen Bereiche des Managers, wie die Steuerung des Root-Zugriffs oder die Installation zusätzlicher Module.

Modifikationen für SafetyNet

Mit der Funktion „Magisk Hide“ im Manager kann man die Existenz von Magisk gegenüber einzelnen Apps verbergen. Hier sollte man mindestens den Google Play Store und das Google Services Framework auswählen.

Wenn man ein CustomROM verwendet, ist es aber sehr wahrscheinlich, dass die SafetyNet-Prüfung dennoch bei „ctsProfile“ weiterhin einen Fehler zeigt. Das bedeutet, dass Apps, die SafetyNet voraussetzen, nicht ausführbar sind. Ursache dafür ist, dass das Gerät durch das CustomROM einen nicht freigegebenen Fingerprint liefert.

Eine Abhilfe dafür ist das Modul „MagiskHide Props Config“. Nachdem man dieses Modul installiert hat und das Gerät einmal neu gestartet wurde, kann man über eine Console (wahlweise mit einer entsprechenden Terminal-App auf dem Gerät selbst oder über eine ADB-Shell) mit folgenden Befehlen einen „erlaubten“ Fingerprint einstellen:

su
props

Siehe dazu auch die Beschreibung in der Dokumentation des Moduls, wo auch zusätzliche Maßnahmen beschrieben werden, falls dieser Schritt nicht ausreicht.

Besonderheiten bei TitaniumBackup

Wenn TitaniumBackup sich beschwert, dass die vorgefundene SU-Variante problematisch ist, kann man das getrost ignorieren bzw. die Warnung auch dauerhaft abschalten. Alle Funktionen von TitaniumBackup sind trotzdem nutzbar.

Öffentlichen Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Dies ist kein Kontaktformular! Wenn Du mir eine persönliche Nachricht schreiben möchtest, benutze die E-Mail-Adresse in meinem Impressum.