Google verschärft den ADB-Zugriff, das Rooten von Android wird zunehmend schwieriger.

Die Unterdrückung des Seitenladens und die Blockierung der BootLoader-Entsperrung lassen das heutige Android die einstigen treuen Fans zunehmend fremd empfinden. Dieses mobile Betriebssystem, das einst für Freiheit und Offenheit bekannt war, verliert ständig seine eigene Persönlichkeit. Mit einer schrittweisen, unmerklich zunehmenden Einschränkung hat Google Android zu einem Ökosystem verwandelt, das zwar als quelloffen und offen bezeichnet wird, aber in Wirklichkeit „selbst kontrolliert“ ist.

Heute scheint Android auf dem Weg zur Geschlossenheit noch einen Schritt weiter zu gehen. Kürzlich enthüllte das ausländische Technikmedium Android Authority, dass laut den offiziellen Protokollen von Googles Issue Tracker das Unternehmen neue Maßnahmen prüft, um den Zugriffsbereich des ADB-Daemons (im Folgenden kurz adbd genannt) einzuschränken.

ADB, also Android Debug Bridge, ist ein Befehlszeilen-Debugging-Tool im Android SDK. Seine Kernfunktionen umfassen die Geräteerkennung, die Installation und Deinstallation von Anwendungen, die Dateiübertragung, das Erfassen von Protokollen sowie systemweite Shell-Operationen. Der bekannte „USB-Debug-Modus“ wird auf Basis von ADB implementiert. ADB folgt einer Client-Server-Daemon-Architektur: Der Client läuft auf dem Entwicklungsrechner und sendet Befehle, der Server verwaltet die Kommunikation im Hintergrund, und der Daemon verbleibt auf dem Gerät, um die Befehle auszuführen.

adbd bietet Entwicklern nicht nur einen Kanal zum Zugriff auf den Hardware- und Softwarezustand des Geräts, sondern unterstützt auch das Debuggen von Anwendungen. Gleichzeitig ist es ein wichtiges Werkzeug für Gerätehersteller, ROM-Entwickler und Sicherheitsforscher, um Android-Geräte zu analysieren und zu verbessern. Bei verschiedenen Sicherheitsaudits, Leistungstests und Anwendungsoptimierungen spielt adbd eine Schlüsselrolle und hat einen tiefgreifenden Einfluss auf das gesamte Android-Ökosystem.

Laut Googles Plan soll der Zugriffsbereich von adbd in Zukunft auf Verbindungen über WLAN oder USB beschränkt werden, während lokale Loopback-Adressen wie 127.0.0.1 blockiert werden. Google begründet dies damit, dass die Maßnahme darauf abzielt, das verbleibende Risiko der Sicherheitslücke CVE-2026-0073 zu beheben, die eine Umgehung der drahtlosen ADB-Authentifizierung ermöglicht.

Da lokale Loopback-Verbindungen es dem Gerät ermöglichen, über interne Netzwerkprotokolle auf sich selbst zuzugreifen, kann ein Terminalemulator mithilfe solcher Verbindungen Debug-Befehle an das lokale System senden. Wenn adbd keine lokalen Loopback-Verbindungen mehr nutzen kann, wird die geräteseitige ADB in Zukunft praktisch unbrauchbar. Tatsächlich spielt Google wieder die „Sicherheitskarte“: Es zielt darauf ab, Tools wie den Termux-Terminalemulator und das Shizuku-Rechteerweiterungstool einzuschränken, die auf geräteseitigem ADB basieren, um Anpassungen ohne Root-Rechte zu ermöglichen.

Im Allgemeinen bezieht sich das „ROOT“, von dem Android-Nutzer häufig sprechen, auf das Entsperren des BootLoaders und den Eintritt in den Recovery-Modus, um Administratorrechte zu erlangen. Dieser Weg ist heute jedoch zunehmend schwierig geworden. Vor sieben oder acht Jahren haben Handyhersteller entweder aufgehört, Nutzern Kanäle zur Entsperrung des BootLoaders anzubieten, oder die Hürden für die Entsperrung stark erhöht.

Heute ist der Weg, auf dem Android-Nutzer offizielle ROOT-Berechtigungen von Handyherstellern erhalten wollen, so kompliziert wie die Reise zur Beschaffung der heiligen Schriften mit 81 Prüfungen. Heutzutage ist die konforme ROOT-Berechtigung fast nur „im Prinzip möglich“. Auf diese Weise müssen Nutzer andere Wege finden, um ihr Handy zu rooten und das Gerät vollständig in ihren eigenen Besitz zu bringen.

Termux und Shizuku sind von Android-Entwicklern an die Realität angepasste Lösungen, bei der Handyhersteller die BootLoader-Entsperrung verschärft haben. Sie ermöglichen es, ohne vollständige Root-Rechte einen Systemdienst mit höheren Berechtigungen über ADB zu erstellen, um Funktionen zu implementieren, die nur auf Basis von System-APIs erreichbar sind, wie Black Domain (Verwaltung/Einschränkung von Hintergrundprozessen von Anwendungen), Permission Dog (Verwaltung/Einschränkung von Anwendungsberechtigungen), Ice Box (Einfrieren von Anwendungen), Install Lion (Übernahme der Systemanwendunginstallation) und Auto Skip (Überspringen von Startanzeigen von Anwendungen).

Wenn Google den Zugriffsbereich von ADB verschärft, wird es Nutzern in Zukunft schwerfallen, Debug-Befehle über einen Emulator an das lokale System auf dem Handy zu senden. Auch wenn Googles ursprüngliche Absicht möglicherweise darin liegt, die Sicherheit des Android-Systems zu gewährleisten und zu verhindern, dass Hacker über diesen Kanal die Geräte der Nutzer angreifen, wird die Spielbarkeit von Android-Geräten weiter abnehmen.

Das ist offensichtlich kein gutes Zeichen. Wenn das zukünftige Android kaum noch die Installation von Anwendungen über Drittkanäle erlaubt und keine Funktionen ausführen kann, die Handyhersteller den Nutzern nicht zugänglich machen, wo liegt dann noch der Unterschied zu iOS?

Dass Apple eine „allumfassende“ Vormundschaft übernimmt, ergibt sich daraus, dass iOS ein stabiles, praktisches und benutzerfreundliches Ökosystem bietet. Im Gegensatz dazu teilt allein GMS das Android-Ökosystem in zwei Teile auf. Selbst bei GMS, das von Google selbst gewartet wird, ist der Play Store immer noch voll von verschiedenen gefälschten Anwendungen und sogar bösartigen Apps im eigentlichen Sinne.

Mit anderen Worten: Obwohl Google behauptet, das offene Ökosystem zur Sicherheit der Nutzer zu verschärfen, ist es selbst noch nicht in der Lage, „das Haus gründlich zu reinigen, bevor man Gäste einlädt“.

Dieser Artikel stammt aus dem WeChat-öffentlichen Account „San Yi Leben“ (ID: IT-3eLife), Autor: San Yi Jun, veröffentlicht mit Genehmigung von 36Kr.