Erfahren Sie mehr über die neueren Komplikationen, die Verity und Marshmallow beim Rooten gesperrter Geräte mit sich bringen.
Während sich der Staub darauf legt Android 6.0-VersionZahlreiche Nexus-Benutzer suchen nach OTAs und Fabrikbilder, und bereiten Sie sich auf die neueste Version des Android-Betriebssystems vor.
Während Android 6.0 von außen (zumindest optisch) bemerkenswert ähnlich zu Android 5.0 und 5.1 (den Lollipop-Versionen) erscheint, gibt es eine Reihe bedeutender Änderungen innen. Einer von ihnen hat möglicherweise Auswirkungen auf das benutzerdefinierte ROM und die Root-Communitys. Zunächst ein kleiner Hintergrund. Wenn Sie daran nicht interessiert sind, fahren Sie einfach mit „Warum ist das wichtig“ fort.
Eine Funktion namens Verity
Das Problem (es ist ein Problem, wenn Sie rooten und Geräte ändern möchten) rührt von etwas her, auf das ich vor langer Zeit hingewiesen habe, als es AOSP zum ersten Mal auf den Markt brachte – die Einführung von dm-verity auf Android. Verity ist eine Sicherheitsfunktion, die ursprünglich in ChromeOS enthalten war und darauf ausgelegt ist, sichere und vertrauenswürdige Computergeräte bereitzustellen und zu verhindern, dass Schadsoftware ein Gerät verändert. Bereits in Android 4.4 kündigte Google Verity für Android an, und dann blieb alles ruhig. Zwar gab es einige
Mit Android 6.0 hat Google damit begonnen, die Gerätesicherheit zu verbessern. Eine der Grundvoraussetzungen hierfür besteht darin, zu verhindern, dass die Software auf einem Gerät ohne das Wissen des Benutzers – wie es viele hier tun – verändert wird Bei XDA ist Root eine Selbstverständlichkeit. Stellen Sie sich vor, das Gerät eines Benutzers wird ohne sein Wissen oder seine Zustimmung gerootet und der Root-Zugriff wird genutzt, um sein Gerät zu stehlen Daten. Aus diesem Grund hat Google damit begonnen, auf einigen Geräten eine Überprüfung der Systempartition zu implementieren. Sie haben auch kürzlich ihre aktualisiert Support-Seiten um dies abzudecken.
Was bedeutet das für gerootete Benutzer?
Mit der Wahrheit an Ort und Stelle, Alle an der Systempartition vorgenommenen Änderungen werden beim Booten oder Zugriff erkannt. Sie werden dann mit einem der oben beschriebenen Fehler konfrontiert. Bei einigen können Sie fortfahren, bei anderen möchten Sie sich schützen, indem Sie das Booten des Geräts verhindern. Es stehen drei Zustände zur Verfügung. Eines wird angezeigt, wenn der Bootloader entsperrt ist. Dies weist darauf hin, dass Sie möglicherweise einem Risiko ausgesetzt sind, bis Sie den Bootloader erneut sperren. Dies ist der Fall, da ein geändertes Kernel-Image Verity umgehen kann, da die Kernel-Ramdisk die Schlüssel enthält, die zur Überprüfung des Systemstatus verwendet werden.
Für Root-angehende Benutzer auf gesperrten Geräten sieht es eher unspaßig aus.
Der nächste Status wird (vermutlich) angezeigt, wenn Verity deaktiviert oder ausgeschaltet ist oder aufgrund von Änderungen an der Ramdisk nicht überprüft werden kann. Ich kann nicht sicher sein, da ich kein Nexus 5X oder 6P zur Untersuchung habe, aber mein Verdacht (basierend auf den Meldungen) ist es Wenn Sie ein anderes ROM laden, das dann seinen eigenen Kernel auf dem Gerät platziert, wird die Seite „Anderes Betriebssystem“ angezeigt erscheinen.
Der Endzustand ist die rote Warnung, die besagt, dass das Gerät beschädigt ist. Ich vermute, das bedeutet, dass das Image die Wahrheit enthält, aber die Überprüfung ist fehlgeschlagen, weil das System-Image geändert wurde. Auch hier können wir ohne Hardware nicht sicher sein, aber dieser Fehler scheint der zu sein, der auftritt, wenn ein Standardgerät durch eine bösartige Software verändert wurde.
Warum ist das wichtig?
Unter Android M (6.0) erfordert Root derzeit neben dem Dateisystem auch Änderungen am Kernel-Image. Dies bedeutet, dass selbst wenn wir die Wahrheit ignorieren (z. B. auf einem älteren Nexus-Gerät wie einem Nexus 7 2013) ist ein neues Kernel-Image erforderlich, um SELinux-Schutzmaßnahmen zu umgehen, die verhindern, dass der Root-Zugriff funktioniert.
Wenn Sie heute auf Android Marshmallow rooten möchten, müssen Sie ein modifiziertes Boot-Image verwenden.
Bisher gab es solche modifizierte Kernel SELinux in den permissiven Modus zu versetzen, aber das ist keine ideale Lösung, da Sie dadurch nicht die Sicherheitsvorteile des SELinux-Schutzes nutzen können. Und nach dem LampenfieberSagaIch gehe davon aus, dass Sie die Vorteile von SELinux und anderen Schutzmaßnahmen gegen Sicherheitslücken erkennen können.
XDA Senior Recognized Developer, Kettenfeuer, Meister aller Dinge, Root hat eine veröffentlicht aktualisierte Version von SuperSU Dadurch bleibt SELinux im Erzwingungsmodus, aber es müssen erneut Änderungen an der SELinux-Konfiguration des Boot-Images vorgenommen werden. Das bedeutet, dass Sie SuperSU sowie ein modifiziertes Boot-Image installieren müssen.
Und das ist alles schön und gut, bis US-Fluggesellschaften in den Mix einsteigen. Die Bastionen der Anti-Consumer-Choice, die Getreuen wie AT&T und Verizon, sind dafür bekannt, dass sie gerne Geräte sperren und Benutzer daran hindern, benutzerdefinierte Firmware über ihre Bootloader-Sperren zu installieren. Tatsächlich ist Verizon beim Sony Xperia Z3v besonders schlecht darin, nicht einmal Firmware-Updates an Benutzer weiterzugeben nicht für den Empfang von Marshmallow eingestellt während der Rest der Z3-Reihe (und in der Tat die Z2-Reihe) dies tun wird. Verdammt, sie haben Lollipop immer noch nicht einmal auf dem Gerät bereitgestellt, obwohl es verfügbar ist etwas Zeit (November 2014) auf dem regulären Z3.
Anstelle einer inoffiziellen Bootloader-Freischaltung (diese sind heutzutage ziemlich selten, abgesehen von durchgesickerten technischen Bootloadern für einige Samsung-Geräte) scheint dies höchst unwahrscheinlich dass Sie ohne göttliches Eingreifen Root auf Android 6.0 erhalten – die Kombination von dm-verity (um zu verhindern, dass Ihr Telefon startet, wenn Änderungen daran vorgenommen werden Systempartition) und die Notwendigkeit von SELinux-Änderungen in der Ramdisk (um Root funktionieren zu lassen), werden die Dinge für Root-anstrebende Benutzer davon voraussichtlich eher uninteressant machen gesperrte Geräte.
Android Pay?
Endlich Android Pay. Es klingt wahrscheinlich völlig unabhängig vom Rest dieses Artikels, ist aber tatsächlich ziemlich relevant. Android Pay setzt auf das Neue SafetyNet-APIs innerhalb des proprietären Service-Frameworks von Google, das Gerätestatusbescheinigungen darüber liefern soll, ob ein Gerät gerootet oder anderweitig verändert ist oder in einem nicht genehmigten Zustand läuft.
Während es eine gibt Projekt Wenn man sich die Spoofing-Antworten auf SafetyNet ansieht, ist derzeit ein Xposed-Plugin erforderlich, und angesichts der Funktionsweise dürfte sich daran auch nichts ändern. Xposed erfordert Root und nimmt Änderungen an der Systempartition vor. Das macht es schwierig, dies auf einem Bootloader-gesperrten Gerät durchzuführen. Selbst dann kommt es bei solchen Dingen nur zu einem Katz-und-Maus-Spiel mit Google. Mit SafetyNet werden gerootete Geräte (oder überhaupt modifizierte Geräte) als „nicht CTS-konform“ angesehen, was ein Euphemismus für modifizierte Geräte ist.
Über SafetyNet wurde noch viel mehr geschrieben in diesem Teardown-Blogbeitrag, aber es scheint durchaus, dass wir einige Bereiche identifizieren können, in denen Google hart durchgreifen möchte. Erstens mögen sie Root, Xposed und alles, was die Systempartition verändert, nicht. Zweitens scheint Google darüber nachzudenken, Nutzer zu erkennen, die die Werbeblockierung aktiviert haben – die SSL-Handshake-Prüfung erfolgt pubads.g.doubleclick.net Meiner Meinung nach möchte Google unbedingt wissen, ob Sie Werbung auf Ihrem Gerät blockieren. Wenn man bedenkt, dass Root dort normalerweise eine Voraussetzung ist, die VPN-API jedoch möglicherweise dazu verwendet werden könnte Dies ohne Root, es sieht so aus, als ob Google zumindest eine Vorstellung davon haben möchte, wer (oder wie viele Personen) blockiert Anzeigen. Das Blockieren von Werbung ist ein aktuelles Thema, da Apple darauf drängt, es im Webbrowser zu unterstützen (wohl zu fördern). Menschen dazu bewegen, mehr Apps zu nutzen, bei denen sie das Erlebnis kontrollieren und nicht blockierbare Werbung anbieten können), und diese Schritte sind der Fall interessant.
Abschluss
Wenn Sie heute unter Android Marshmallow (6.0) rooten möchten, müssen Sie ein modifiziertes Boot-Image verwenden. Es bleibt zwar abzuwarten, ob dies auf unbestimmte Zeit so bleibt, es scheint jedoch wahrscheinlich, dass dies noch einige Zeit der Fall sein wird – SELinux-Änderungen machen es viel schwieriger, Root-Zugriff zu erhalten, ohne das Boot-Image zu ändern. Und da das Ändern des Boot-Images einen entsperrten Bootloader erfordert, könnte dies das Ende von Root (und Xposed) bedeuten und andere Root-Funktionen) auf Geräten, die mit Bootloadern ausgeliefert werden, die von Endbenutzern nicht entsperrt werden können. Dm-verity taucht ebenfalls auf und scheint auf neuen Geräten im Erzwingungsmodus aktiviert zu sein. Dadurch wird es schwierig, /system zu ändern, selbst wenn Sie Root-Zugriff erhalten würden, ohne erneut über einen entsperrten Bootloader zu verfügen.
Ändert sich dadurch Ihre Sicht auf vom Bootloader gesperrte Geräte? Hat Android das Stadium erreicht, in dem Sie immer noch ein Gerät mit Bootloader-Sperre kaufen würden, wenn Ihr Mobilfunkanbieter Ihnen ein gutes Angebot machen würde?, Oder interessieren Sie sich nur für entsperrte Geräte? Welche Root-Apps oder -Funktionen würden Sie bei einem gesperrten Bootloader vermissen?
Teilen Sie Ihre Gedanken gerne unten in den Kommentaren mit.