ADB über das Internet auf Android: sichere Setups mit und ohne Root

Du brauchst kein Root, um das ADB deines Handys aus einem anderen Land zu erreichen. Du brauchst eine Möglichkeit, ADB über TCP einzuschalten, und einen privaten Weg zwischen deinem Computer und dem Handy. Root ändert nur den ersten Teil: Das Handy kann ADB selbst einschalten und nach einem Neustart ohne Kabel wieder aktivieren. Alles andere in diesem Guide funktioniert auf einem Stock-Handy genauso.

Die beiden typischen Fehler sind mit und ohne Root dieselben. Entweder folgt man einem Tutorial, das Port 5555 am heimischen Router weiterleitet, oder man verlässt sich auf eine Verbindung, die im WLAN klappt und über mobile Daten unbemerkt scheitert.

Dieser Guide gilt für das Handy, das dir gehört: ein Zweitgerät für deine Tests, ein Handy zu Hause, auf das du unterwegs zugreifen willst, oder eine kleine Geräte-Farm. Fremde Geräte behandelt er nicht. Er erklärt, wie Remote-ADB funktioniert, wie du es mit und ohne Root einschaltest und welche drei Verbindungsmethoden ADB nie ins öffentliche Internet stellen. Schritte, die Root brauchen, sind mit Nur mit Root markiert.

Die Kurzfassung: Schalte TCP-ADB am Handy ein, mach es nur über einen verschlüsselten privaten Weg erreichbar und nutze diesen Weg von deinem Computer aus. Tailscale ist der einfachste Weg. Ein SSH-Reverse-Tunnel über einen kleinen eigenen Server ist der universellste. Einfaches Port-Forwarding von 5555 ist das eine Setup, das du vermeiden solltest.

Mit oder ohne Root: was sich ändert

Der praktische Unterschied liegt in der Zuverlässigkeit, nicht im Funktionsumfang. Ein Stock-Handy funktioniert aus der Ferne einwandfrei, bis es neu startet. Danach ist es nicht mehr erreichbar, bis jemand mit Handy und Computer den Zustand wiederherstellt. Bei einem Handy in einer anderen Stadt ist das der Grund, es zu rooten. Bei einem Handy, das du in die Hand nehmen kannst, oder bei einem kurzen Test brauchst du das nicht.

Was ADB wirklich schützt und was nicht

In den meisten Tipps zu Remote-ADB heißt es, ADB im Netzwerk habe „keine Verschlüsselung und keine Authentifizierung“. Das stimmt nur zur Hälfte, und die falsche Hälfte ist wichtig dafür, wie du alles einrichtest.

Das klassische Netzwerk-ADB, der adb tcpip 5555-Modus, ist unverschlüsselt. Die ADB-Designnotizen von Android beschreiben den alten Transport als Klartextpakete, während der mit Android 11 eingeführte WLAN-Modus die Sitzung in TLS verpackt.Quelle 2 Wer den Weg zwischen dir und dem Handy mitlesen kann, sieht alles, was du sendest.

Die Authentifizierung ist eine andere Sache. Bei einem normalen Produktions-Build verlangt ADB weiterhin, dass das Handy den RSA-Schlüssel deines Computers freigibt. Bei der ersten Verbindung meldet adb devices den Status unauthorized, und das Handy blendet einen Dialog ein: „Allow USB debugging?“ mit dem Fingerabdruck des Schlüssels. Laut Android-Dokumentation lassen sich adb-Befehle erst ausführen, wenn du das Gerät entsperrst und den Dialog bestätigst.Quelle 1 Die freigegebenen Schlüssel liegen auf dem Handy, und mit dem Häkchen bei „Always allow from this computer“ werden spätere Verbindungen ohne Rückfrage aufgebaut.

Daraus folgen zwei praktische Konsequenzen. Erstens ist ein offener Port bei einem Stock-Handy keine offene Tür für einen Fremden, aber eine offene Tür für jeden, der einen Schlüssel erlangt, dem das Handy bereits vertraut, und eine komplett offene Tür bei jedem Gerät, auf dem die Authentifizierung ausgeschaltet ist. Die Schadsoftware, die sich über Port 5555 verbreitet hat, hat meist genau solche Geräte gefunden: TV-Boxen, Projektoren, Entwickler-Builds und Handys, bei denen jemand das Secure-Flag ausgeschaltet hat. Zweitens braucht schon die allererste Verbindung von einem neuen Computer eine Hand am Bildschirm. Plane ein, deinen Schlüssel freizugeben, solange du neben dem Handy stehst, per USB-Kabel oder im Heim-WLAN, und setze das Häkchen, das ihn speichert.

Warum Wireless debugging für unbeaufsichtigten Fernzugriff ungeeignet ist

Wireless debugging wirkt wie die sicherere Wahl, und für einen Laptop im Heim-WLAN ist es das auch. Für den Fernzugriff arbeitet es gegen dich. Der Verbindungsport ist zufällig und ändert sich, wenn du die Funktion aus- und wieder einschaltest. Die Erkennung läuft über mDNS, das kein VPN überquert, und neuere Android-Versionen schalten die Funktion von selbst ab. Android 17 mit ADB 37 bringt „ADB Wi-Fi 2.0“, das Wireless debugging in Netzwerken ausschaltet, die du nicht als vertrauenswürdig markiert hast, und sich in markierten Netzwerken automatisch neu verbindet.Quelle 4 Für den Schreibtisch eines Entwicklers ist das ein hervorragendes Verhalten, für ein Handy, das du aus einem anderen Land erreichen musst, genau das Falsche.

Details zu dieser Funktion findest du in unserem Guide zu kabellosem ADB unter Android 17, der Kopplung, vertrauenswürdige Netzwerke und das Problem „gekoppelt, aber offline“ behandelt. Für den Fernzugriff ist der feste TCP-Port der bessere Baustein: Du kannst ihn mit oder ohne Root einschalten und dann mit etwas Stärkerem als dem Port selbst schützen.

Schritt 1: TCP-ADB aktivieren

Wähle den Abschnitt, der zu deinem Handy passt. Beide enden im selben Zustand: Der ADB-Daemon des Handys lauscht auf Port 5555, und Schritt 2 schützt ihn.

Ohne Root

Aktiviere auf einem beliebigen Android-Handy die Developer options und das USB debugging, verbinde das Handy per Kabel mit einem Computer, bestätige den Schlüssel, wenn das Handy fragt, und führe aus:

adb tcpip 5555

Zieh das Kabel ab. Das Handy nimmt jetzt ADB über das Netzwerk auf Port 5555 an, bis es neu startet. Bei manchen Builds wird die Einstellung außerdem zurückgesetzt, wenn du das USB debugging umschaltest. Antwortet der Port nicht mehr, führst du den Befehl also noch einmal aus. Weil die Einstellung beim Neustart verloren geht, braucht ein Handy ohne Root nach jedem Neustart jemanden mit einem Kabel. Für ein Handy, das du kontrollierst, ist das in Ordnung, für eines außer Reichweite ist es unpassend.

Ab Android 11 gibt es einen Weg, denselben Schritt ganz ohne Computer zu erledigen. Die Community nutzt ihn viel, wir haben ihn aber nicht auf jedem Gerät getestet. Du schaltest Wireless debugging ein, installierst Termux samt dem Android-Tools-Paket, koppelst Termux mit dem Handy selbst über den Kopplungscode, verbindest dich mit der eigenen Adresse des Handys und führst dort adb tcpip 5555 aus. Dafür muss das Handy in diesem Moment im WLAN sein. Sieh darin eine Notlösung für den Tag, an dem du dein Kabel vergessen hast, und schlage die genauen Befehle in einer aktuellen Termux-Anleitung nach, denn sie ändern sich mit dem Paket und der Android-Version.

Mit Root (Root erforderlich)

Öffne auf einem gerooteten Handy eine Terminal-App wie Termux und starte eine Root-Shell. Die Property, die den Port steuert, liest der ADB-Daemon selbst. Laut Daemon-Quellcode prüft er service.adb.listen_addrs, dann service.adb.tcp.port, dann persist.adb.tcp.port.Quelle 3

su
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Ein Neustart des Daemons beendet jede offene USB debugging-Sitzung. Führe ihn deshalb am Handy aus und nicht von einem per Kabel verbundenen PC. Prüfe, ob er lauscht:

getprop service.adb.tcp.port
ss -ltn | grep 5555

Manche Android-Builds liefern kein ss mit; auf anderen funktioniert netstat -ltn. Ist keines von beiden vorhanden, ist der Verbindungstest von deinem Computer aus in Schritt 2 der eigentliche Beweis.

Die Property service. geht beim Neustart des Handys verloren. Ein Handy, das du nach einem Stromausfall nicht mehr erreichst, ist kein Fernhandy. Mach die Einstellung also dauerhaft. Dafür gibt es zwei Wege, die sich gut kombinieren lassen. Der erste ist die persistente Property:

setprop persist.adb.tcp.port 5555

Der zweite ist ein Boot-Skript. Bei Magisk läuft ein Shell-Skript, das in /data/adb/service.d/ liegt und als ausführbar markiert ist, spät im Bootvorgang. KernelSU und APatch verwenden stattdessen ein kleines Modul mit einer Datei service.sh. Den genauen Ort entnimmst du der Dokumentation deines Root-Managers, denn er ändert sich zwischen Tools und Versionen.

#!/system/bin/sh
until [ "$(getprop sys.boot_completed)" = "1" ]; do sleep 5; done
setprop service.adb.tcp.port 5555
stop adbd
start adbd

Starte einmal neu und teste. Hersteller behandeln diese Properties unterschiedlich, und einige ROMs ignorieren oder überschreiben sie. Unter Android 11 und neuer hat eine SELinux-Regel bei einigen Builds zeitweise verhindert, dass ADB die Port-Property setzt, und wurde später gelockert.Quelle 5 Überlebt die Einstellung auf deinem Handy keinen Neustart, hilft das Boot-Skript. Lauscht der Daemon gar nicht, blockiert deine ROM womöglich die Property. Dann bleibt als Ausweg eine USB-Sitzung mit adb tcpip 5555 nach jedem Start, also die Methode ohne Root von oben.

So schaltest du es mit Root wieder aus:

setprop service.adb.tcp.port -1
setprop persist.adb.tcp.port ""
stop adbd
start adbd

Ohne Root erledigst du dasselbe, indem du das USB debugging in den Developer options ausschaltest oder das Handy neu startest.

An diesem Punkt lauscht das Handy auf jeder Netzwerkschnittstelle, die es hat. Das ist in Ordnung, solange nur du und dein vertrauenswürdiges Netzwerk diese Schnittstellen erreichen können. Genau dafür sorgt der nächste Schritt.

Schritt 2: Einen privaten Weg zum Handy wählen

Jede der folgenden Methoden funktioniert mit und ohne Root. Alle verfolgen dasselbe Ziel: Dein Computer bekommt eine verschlüsselte, authentifizierte Route zu Port 5555 am Handy, ohne dass eine eingehende Verbindung aus dem offenen Internet angenommen wird. Dieser zweite Punkt ist wichtiger, als er wirkt. Die meisten Handys im Mobilfunknetz hängen hinter Carrier-Grade NAT, sodass eine Router-Weiterleitung sie nicht erreichen könnte, selbst wenn du eine wolltest.

Methode A: Tailscale

Tailscale baut ein privates Netzwerk zwischen deinen Geräten auf und übernimmt die NAT-Überwindung für dich. Deshalb funktioniert es auch mit einem Handy im Mobilfunknetz. Installiere es auf dem Handy und auf deinem Computer und melde dich bei beiden mit demselben Konto an. Jedes Gerät erhält eine feste Adresse, die mit 100. beginnt. Die Adresse des Handys siehst du in der App und in der Admin-Konsole.

Vom Computer aus:

adb connect 100.x.y.z:5555
adb devices

Beim ersten Mal fragt das Handy, ob du den Schlüssel freigibst. Deshalb solltest du diesen Schritt einmal mit dem Handy in der Hand machen. Die Tailscale-App braucht kein Root. Danach funktionieren adb shell, adb push, adb logcat und scrcpy, als läge das Handy auf deinem Schreibtisch.

Drei Einstellungen machen aus einer bequemen eine zuverlässige Lösung. Erstens erlaubt Tailscale standardmäßig jedem Gerät in deinem Netzwerk, jedes andere zu erreichen. In der Policy-Datei schränkst du das ein. Eine Regel, die nur deinem eigenen Konto den Zugriff auf das markierte Handy über Port 5555 erlaubt, sieht in der Zugriffsrichtlinie so aus:Quelle 6

{ "action": "accept", "src": ["you@example.com"], "dst": ["tag:phone:5555"] }

Zweitens schaltest du in der Admin-Konsole den Schlüsselablauf (Key Expiry) für das Handy aus. Sonst fällt es planmäßig aus deinem Netzwerk, und du kannst es aus der Ferne nicht wieder aufnehmen. Drittens gibst du der Tailscale-App in den Android-Einstellungen uneingeschränkte Akkunutzung. Nutzer berichten, dass die App bei aggressiver Energieverwaltung gestoppt wird oder alle paar Minuten die Verbindung verliert. Ein Abbruch mitten in einer Übertragung ist das übliche Symptom.Quelle 8

Zwei Einschränkungen solltest du kennen. Der integrierte SSH-Server von Tailscale läuft unter Android nicht, weil die Plattform für diese Funktion nur Client ist. Brauchst du eine Shell ohne ADB, nutze also den ADB-Port direkt oder den SSH-Tunnel weiter unten.Quelle 7 Nutze dafür auch nicht Tailscale Funnel. Es dient dazu, Webdienste im öffentlichen Internet zu veröffentlichen, und ist damit das Gegenteil von dem, was du erreichen willst.

Methode B: SSH-Reverse-Tunnel über deinen eigenen Server

Diese Methode braucht nichts von Dritten. Du mietest den kleinsten virtuellen Server, den du finden kannst, das Handy verbindet sich nach außen mit ihm und hält die Verbindung offen. Dein Computer verbindet sich mit demselben Server und erreicht das Handy darüber. Weil das Handy die Verbindung selbst aufbaut, funktioniert es hinter CGNAT und im Hotel-WLAN.

Installiere auf dem Handy in Termux, das kein Root braucht, den SSH-Client und erstelle einen Schlüssel:

pkg install openssh autossh
ssh-keygen -t ed25519

Lege auf dem Server einen eigenen Benutzer an und trage den öffentlichen Schlüssel des Handys in dessen Datei authorized_keys ein. Beschränke ihn so, dass der Schlüssel nichts tun kann, außer den einen vorgesehenen Port auf der Loopback-Schnittstelle zu öffnen:

restrict,port-forwarding,permitlisten="127.0.0.1:15555" ssh-ed25519 AAAA... phone

Halte den Tunnel dann am Handy offen. Mit den folgenden Optionen schlägt die Verbindung laut fehl, wenn der Port nicht gebunden werden kann, und hängt nicht unbemerkt in einem toten Netzwerk:

ssh -N -R 127.0.0.1:15555:127.0.0.1:5555 \
  -o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes tunnel@your-server.example

autossh kann diesen Befehl überwachen und neu starten, und das Termux:Boot-Add-on kann ihn nach einem Neustart starten, mit termux-wake-lock, damit die CPU wach bleibt, solange der Tunnel steht. Stelle auch die Akkuoption für Termux auf uneingeschränkt. Diese Bausteine hängen von deiner Android-Version ab und davon, wie aggressiv dein Hersteller Hintergrund-Apps beendet. Teste deshalb eine Stunde lang mit ausgeschaltetem Bildschirm, bevor du dich darauf verlässt.

Leite von deinem Computer aus einen lokalen Port auf den Tunnel weiter und verbinde dich darüber:

ssh -N -L 5556:127.0.0.1:15555 you@your-server.example
adb connect 127.0.0.1:5556

Beachte den lokalen Port 5556. Dein eigener ADB-Server belegt oft schon 5555, und eine Kollision dort führt zu verwirrenden Fehlern. Die Remote-Weiterleitung ist an die Loopback-Adresse des Servers gebunden, sodass nichts im Internet sie direkt erreichen kann. Außerdem verweigert OpenSSH bei Remote-Weiterleitungen standardmäßig, eine öffentliche Schnittstelle zu binden, solange du nicht GatewayPorts geändert hast.

Erlaube auf dem Server nur Anmeldungen per Schlüssel und lass das Passwort für diesen Benutzer deaktiviert. Ein Reverse-Tunnel mit Passwort-Login auf einem aus dem Internet erreichbaren SSH-Server ist kaum sicherer als die Port-Weiterleitung, die er ersetzt.

Methode C: WireGuard auf deinem eigenen Server

WireGuard bringt dir denselben Effekt wie Tailscale, nur mit allen Teilen unter deiner Kontrolle. Betreibe einen WireGuard-Endpunkt auf einem Server mit öffentlicher Adresse, füge das Handy und deinen Computer als Peers hinzu und setze auf der Seite des Handys PersistentKeepalive = 25, damit Mobilfunknetze die NAT-Zuordnung aufrechterhalten. Die WireGuard-App für Android braucht kein Root, wechselt zwischen WLAN und LTE und kann als Always-on-VPN laufen. Von deinem Computer aus verbindest du dich dann genau wie bei Tailscale mit der WireGuard-Adresse des Handys auf Port 5555. Das ist die richtige Wahl, wenn du ein festes, dauerhaftes Setup willst und dir die Pflege des Servers nichts ausmacht.

Noch ein Hinweis zu einer beliebten Alternative: Cloudflare Tunnel ist für SSH dokumentiert, doch wir haben kein sauberes Setup für rohen ADB-Verkehr verifiziert und empfehlen es hier deshalb nicht.

Das Setup, das du vermeiden solltest: Port 5555 am Router weiterleiten

Es ist verlockend, den externen Port 5555 oder einen „raffinierten“ eigenen Port auf das Handy weiterzuleiten und es dabei zu belassen. Tu es nicht. Dabei läuft unverschlüsseltes ADB durch das öffentliche Internet, alles hängt an einer einzigen Schlüsselabfrage, und es fällt genau den Scannern auf, die nach so etwas suchen.

Das ist keine Theorie. 2020 meldeten Forscher von Keysight bei der Analyse des Trinity-Botnets rund 40.000 offene ADB-Geräte, die auf Shodan sichtbar waren, etwa ein Viertel davon Handys, und die Schadsoftware nutzte zum Verbinden adb connect selbst.Quelle 9 Ein konkurrierendes Botnet, Fbot, entfernte Trinity von infizierten Geräten, und Trinity war binnen Stunden zurück. Im Februar 2021 verbreitete sich das auf Mirai-Code aufbauende Botnet Matryosh über denselben Port.Quelle 10 Den externen Port zu ändern, bringt nichts, denn Scanner prüfen jeden Port.

Manche Guides gehen einen Kompromiss ein und leiten stattdessen den SSH-Port eines Termux-Servers weiter. Das ist besser, als ADB weiterzuleiten, veröffentlicht aber trotzdem einen SSH-Dienst auf deiner Heim-IP, und ein Termux-Login mit Passwort gehört nicht ins Internet. Ein Reverse-Tunnel oder ein Overlay-Netzwerk liefert dasselbe Ergebnis ganz ohne eingehenden Port.

Checkliste zur Absicherung

Autorisiere nur die Computer, die du wirklich benutzt, und widerrufe alte. In den Developer options löscht „Revoke USB debugging authorizations“ alle gespeicherten Schlüssel. Das ist eine gute Gewohnheit, bevor du das Handy jemand anderem gibst. Lass das ADB-Debugging auf jedem Handy ausgeschaltet, das es nicht braucht, und sieh den in Schritt 1 geöffneten Port als Teil derselben Entscheidung. Setze „Always allow“ nicht auf einem gemeinsam genutzten oder öffentlichen Computer.

Eine autorisierte ADB-Sitzung sieht, was der Shell-Benutzer sieht, und das ist schon viel: installierte Apps, lesbare Dateien, den Bildschirm und die Eingabe. Nur mit Root: Auf einem gerooteten Handy kann adb shell su deutlich mehr erreichen, wenn dein Root-Manager es der Shell gewährt. Stelle den Manager deshalb so ein, dass er bei der Shell nachfragt, statt sie stillschweigend zuzulassen.

Nur mit Root: Manche richten am Handy eine Firewall-Regel ein, damit Port 5555 nur auf der VPN-Schnittstelle antwortet. Die Idee ist gut, aber wir konnten nicht bestätigen, dass sie unter Android zuverlässig funktioniert. Der Netzwerk-Daemon des Systems kann Regeln bei Netzwerkwechseln umsortieren oder löschen, und die Standard-Tailscale-App legt keine Schnittstelle tailscale0 an, auf die du dich beziehen könntest. Wenn du es versuchst, wende die Regel aus deinem Boot-Skript erneut an und teste von einem Gerät aus, das nicht im VPN ist.

Arbeiten über eine langsame Verbindung

Ein Handy hinter einem Tunnel fühlt sich langsamer an als eines auf deinem Schreibtisch, und meist hilft es, weniger anzufordern. Verringere bei der Bildschirmspiegelung mit scrcpy Auflösung und Bitrate, zum Beispiel mit scrcpy -s 100.x.y.z:5555 -m 1280 -b 4M. Die Namen der Optionen unterscheiden sich leicht zwischen den Versionen, schau also in scrcpy --help nach. scrcpy kann den TCP-Modus auch für dich mit --tcpip aktivieren, und seine Dokumentation empfiehlt, die Verbindung zu trennen, wenn du fertig bist.Quelle 11 Ein direkter Tailscale-Pfad ist schneller als einer über die Server des Anbieters, und der Verbindungsstatus in der App zeigt, welchen du hast.

Bei mehreren verbundenen Geräten sagst du ADB mit adb -s 100.x.y.z:5555 ..., welches du meinst, oder nimmst -d für das USB-Gerät und -e für einen Emulator. Dateiübertragungen und adb logcat vertragen Latenz am besten.

Fehlerbehebung

Mit Root kannst du in einer Root-Shell mit getprop service.adb.tcp.port und getprop persist.adb.tcp.port prüfen, was das Handy tatsächlich verwendet. Ohne Root ist adb connect vom Computer aus der Test. Nutzt das Handy auch Wireless debugging, denk daran, dass dessen zufälliger TLS-Port getrennt gespeichert wird. Eine funktionierende kabellose Verbindung sagt also nichts über den festen Port aus.

Häufige Fragen

Braucht das Root? Nein. Ohne Root aktivierst du TCP-ADB einmal per USB und nutzt Tailscale, einen Reverse-Tunnel oder WireGuard genau wie beschrieben. Der Preis: Die Einstellung geht bei jedem Neustart verloren, also muss jemand ein Kabel anschließen. Root erspart diesen Schritt und fügt die Firewall- und su-Optionen hinzu. Sonst hängt nichts in diesem Guide davon ab.

Funktioniert das über mobile Daten? Ja, denn Tailscale, WireGuard und ein Reverse-Tunnel verbinden sich alle vom Handy nach außen. Eine Port-Weiterleitung am Router ist die Methode, die dort scheitert.

Ist es sicher, es dauerhaft eingeschaltet zu lassen? Es ist so sicher wie der Weg, der es schützt. Hinter einem Overlay-Netzwerk mit Zugriffsrichtlinie ist die Angriffsfläche klein. Lass es nur an, wenn du es wirklich nutzt, und schalte es aus, wenn nicht.

Kann das jemand ohne die Schlüsselabfrage missbrauchen? Bei einem normalen Build muss ein neuer Computer am Handy freigegeben werden. Bei jedem Build, in dem die Debugging-Authentifizierung deaktiviert ist, kann man sich auch ohne verbinden. Deshalb solltest du diesen Port unabhängig vom Build nie ins Internet stellen.

Warum nicht einfach eine Remote-Desktop-App nehmen? Für die Bildschirmnutzung ist das in Ordnung, und eine Bildschirmfreigabe-App braucht überhaupt kein Root. ADB ist das richtige Werkzeug, wenn du aus der Ferne Shell-Befehle, Installationen, Dateiübertragungen oder Logs brauchst.

Bevor du dich darauf verlässt

Teste alles mit dem Handy im Mobilfunknetz und dem Computer in einem anderen Netzwerk. Starte das Handy neu und prüfe, was von allein zurückkommt: Bei einem gerooteten Handy sollte es zurückkommen, bei einem Handy ohne Root solltest du genau wissen, was du neu machen musst. Probiere es auch eine Weile mit ausgeschaltetem Bildschirm. Erreichst du das Handy nach einem dieser Tests nicht mehr, hast du das Problem gefunden, solange es noch günstig zu beheben ist.

Suchst du noch ein Handy für solche Projekte und möchtest eines, das du rooten kannst? Unser Katalog rootbarer Handys zeigt, welche Modelle sich sauber entsperren lassen, und der Guide zu Magisk-Modulen behandelt die Modulseite des Boot-Skripts, das Root voraussetzt. Für eine Linux-Shell, die ohne Root auskommt, lies Linux-Terminal von Android vs. Termux.

Quellen und Umfang

Wir haben diesen Guide im Oktober 2026 anhand der Android-Dokumentation und des Quellcodes sowie anhand von Veröffentlichungen von Herstellern und Sicherheitsforschern erarbeitet. Nicht jede Android-Version und jede ROM wurde getestet. Das Verhalten der Properties, Boot-Skripte, der Trick zum Aktivieren am Handy selbst, der Firewall-Ansatz und das Akkuverhalten von Termux unterscheiden sich je nach Gerät. Prüfe deshalb jeden Punkt auf deinem eigenen Handy, bevor du dich darauf verlässt.

• Quelle 1: Android Developers, Android Debug Bridge (adb) Quelle öffnen
• Quelle 2: Android Quelle öffnen Project, ADB-Wi-Fi-Designnotizen: Legacy-TCP ist unverschlüsselt, der WLAN-Modus nutzt TLS Quelle öffnen
• Quelle 3: Android Quelle öffnen Project, adbd main.cpp, Port-Auswahl über Properties Quelle öffnen
• Quelle 4: Android Developers Blog, Wireless debugging and ADB Wi-Fi 2.0 Quelle öffnen
• Quelle 5: OmniROM, Änderung der SELinux-Richtlinie für adbd-Properties Quelle öffnen
• Quelle 6: Tailscale, Access control lists Quelle öffnen
• Quelle 7: Tailscale, Tailscale SSH platform support Quelle öffnen
• Quelle 8: Tailscale-Community-Forum, Android-Verbindungsabbrüche und Akkunutzung Quelle öffnen
• Quelle 9: Keysight, TrinityP2P malware over ADB Quelle öffnen
• Quelle 10: The Hacker News, Matryosh-DDoS-Botnet, Februar 2021 Quelle öffnen
• Quelle 11: scrcpy-Dokumentation, Connection Quelle öffnen