Wie man Xposed-Module ohne Root-Zugriff mit NPatch ausführt

Wenn man in einer fremden Android-App herumschnüffeln, SSL-Pinning umgehen oder verstecktes Debugging aktivieren muss, greift man normalerweise zu Magisk oder KernelSU. Aber ein Daily-Treiber-Phone nur für ein einziges Tool zu rooten ist umständlich. Banking-Apps fangen an zu meckern, Play Integrity funktioniert nicht mehr, und auf Firmengeräten ist Root aufgrund von Sicherheitsrichtlinien sowieso verboten.

Lange Zeit wurde dieses Problem durch das LSPatch-Projekt gelöst. Es nahm eine fertige APK, bettete eine LSPosed-Runtime und die nötigen Hooks ein, danach lief die App mit Xposed-Modulen ohne Systemrechte. Als das ursprüngliche LSPatch nicht mehr aktiv weiterentwickelt wurde, sprang ein Fork namens NPatch (Neo LSPatch) ein, um die Lücke zu füllen.

Was dieses Tool macht

Das Projekt nimmt eine normale APK-Datei und verpackt sie neu. In das Archiv werden die DEX-Dateien des Loaders und native Bibliotheken (.so) injiziert, die für das Abfangen von ART-Aufrufen (Android Runtime) verantwortlich sind. Wenn die gepatchte App startet, wird diese eingebettete Schicht zuerst geladen. Sie initialisiert die Xposed-API-Ausführungsumgebung direkt im isolierten App-Prozess.

Für den Rest des Systems läuft einfach ein gewöhnliches Benutzerprogramm. Es braucht keine Superuser-Rechte, greift nicht auf die Systempartition zu /system und versucht nicht, zygote zu ersetzen. Alle Modifikationen und Hooks sind strikt auf die Sandbox des jeweiligen Pakets beschränkt.

Versionen ab Android 9 bis zu aktuellen Android-Versionen, die mit der JingMatrix/LSPosed-Codebasis kompatibel sind, werden unterstützt.

So funktioniert der Patching-Prozess

Unter der Haube baut NPatch auf der Arbeit mehrerer Open-Source-Projekte auf:

• LSPosed übernimmt Xposed-API-Aufrufe und Runtime-Methoden-Interception in ART.
• Xpatch lieferte das Kernkonzept der Code-Injektion in eine APK ohne Systemeingriff.
• Apkzlib wird zum Entpacken, Modifizieren des ZIP-Archives und schnellen Neuverpacken ohne vollständige Dekompilierung zu Smali verwendet.

Im Gegensatz zur klassischen apktool + jarsigner-Kombination, bei der das Dekompilieren großer obfuscierter Projekte oft mit Fehlern abbricht, ist dieser Ansatz schneller und zuverlässiger. Ressourcen und Manifest werden direkt angepasst, danach wird der Loader injiziert.

Nutzungsoptionen

Man kann mit dem Tool auf zwei Arten arbeiten: am Computer über das Terminal oder direkt auf dem Handy.

Option 1. Konsole über JAR

Wenn man die Test-Build-Assemblierung auf CI automatisiert oder Software auf einem Workstation analysiert, ist es praktischer, die fertige JAR-Datei aus den Releases zu holen:

# Базовый синтаксис запуска утилиты
java -jar npatch.jar [аргументы]

Das Tool nimmt die Quell-APK und die einzubettenden Module als Eingabe. Die Ausgabe ist ein fertiges modifiziertes Paket, das nur noch mit einem Test-Key signiert und über adb install installiert werden muss.

Option 2. Manager auf dem Gerät

Für alltägliche Aufgaben ist es einfacher, manager.apk aus dem Releases-Bereich auf GitHub herunterzuladen.

1. Den Manager auf dem Android-Gerät installieren.
2. Eine installierte App oder eine lokale APK-Datei auswählen.
3. Die Xposed-Module angeben, die beim Start geladen werden sollen.
4. Der Manager erstellt ein neues Installationspaket und schlägt vor, das Original vor der Installation der Modifikation zu entfernen.

Da sich die App-Signatur bei der Neuverpackung zwangsläufig ändert, kann man das Originalprogramm nicht darüber aktualisieren. Man muss es entfernen und verliert dabei lokale Daten, falls diese nicht synchronisiert waren.

Praktische Anwendungsfälle

Ich nutze diese Patcher regelmäßig bei Reverse Engineering und beim Testen von Mobile-Clients.

• SSL-Pinning für Traffic-Interception umgehen. Traffic in Burp Suite oder mitmproxy zu wrappen ist viel einfacher, wenn man ein Modul wie TrustMeAlready oder JustTrustMe direkt in die APK einbetten kann. Kein Need, Zertifikate über Magisk in den System-Store zu pushen.
• Instrumentierung und Log-Sammlung. Wenn man sehen muss, welche Argumente an private Methoden in einem Drittanbieter-SDK übergeben werden, schreibt man einen kleinen Xposed-Hook, injiziert ihn in den Build und loggt den Call-Stack nach logcat.
• Module auf sauberen Geräten testen. Modul-Entwickler finden es nützlich zu überprüfen, wie ihr Code sich isoliert ohne System-LSPosed verhält.

Fallstricke und Einschränkungen

Der rootlose Ansatz hat natürliche Grenzen, die man vorher kennen sollte:

• System-Module funktionieren nicht. Wenn ein Hook das Verhalten von SystemUI, Notification-Shades oder Android-Services ändern soll, ist NPatch machtlos. Es lebt strikt im User-Prozess.
• Einige Apps mit striktem Anti-Cheat oder fortgeschrittenem Selbstschutz (Signatur-Integritätsprüfungen, Erkennung fremder .so-Dateien) erkennen die Manipulation und beenden sich beim Start.
• Die Dokumentation im Repository ist noch dünn. Die meisten Details werden im Telegram-Chat des Projekts besprochen, und aktuelle Builds müssen oft direkt aus den GitHub-Actions-Artefakten gezogen werden.

Lohnt es sich?

Wenn man regelmäßig unter die Haube einer Drittanbieter-Android-App schauen oder schnell eine Hypothese testen muss, ohne das Gerät neu zu flashen, sollte man npatch.jar zum Werkzeugkasten hinzufügen. Das Projekt hält die LSPatch-Codebasis aktuell und bewältigt das Neuverpacken von Apps für neuere Android-Versionen problemlos.