Xposed-modules uitvoeren zonder root-toegang met NPatch

Wanneer je in andermans Android-app wilt snuffelen, SSL-pinning wilt omzeilen of verborgen debugging wilt inschakelen, is de gebruikelijke reflex om naar Magisk of KernelSU te grijpen. Maar een dagelijks gebruikte telefoon rooten voor slechts één hulpprogramma is onhandig. Bank-apps beginnen te klagen, Play Integrity valt uit, en op zakelijke apparaten is root ronduit verboden door beveiligingsbeleid.

Lange tijd werd dit probleem opgelost door het LSPatch-project. Het nam een kant-en-klare APK, embedded een LSPosed-runtime en de noodzakelijke hooks erin, waarna de app zou draaien met Xposed-modules zonder systeemrechten. Toen de originele LSPatch niet langer actief werd onderhouden, kwam een fork genaamd NPatch (Neo LSPatch) om de leemte op te vullen.

Wat dit hulpmiddel doet

Het project neemt een gewoon APK-bestand en verpakt het opnieuw. Binnenin het archief injecteert het de DEX-bestanden van de loader en native libraries (.so) die verantwoordelijk zijn voor het onderscheppen van ART (Android Runtime)-aanroepen. Wanneer de gepatchte app opstart, start deze ingebedde laag eerst. Het initialiseert de Xposed API-uitvoeringsomgeving direct binnen het geïsoleerde app-proces.

Voor de rest van het systeem draai je gewoon een gewoon gebruikersprogramma. Het heeft geen superuser-rechten nodig, raakt de systeempartitie /system niet aan, en probeert niet zygote te vervangen. Alle modificaties en hooks zijn strikt beperkt binnen de sandbox van dat specifieke pakket.

Versies vanaf Android 9 tot huidige Android-releases compatibel met de JingMatrix/LSPosed-codebase worden ondersteund.

Hoe het patchproces werkt

Op de achtergrond bouwt NPatch voort op het werk van verschillende open-sourceprojecten:

• LSPosed verwerkt Xposed API-aanroepen en runtime-methode-interceptie in ART.
• Xpatch leverde het kernconcept van het injecteren van code in een APK zonder systeemingrijpen.
• Apkzlib wordt gebruikt voor het uitpakken, aanpassen van het zip-archief en snel opnieuw verpakken zonder volledige decompilatie naar smali.

In tegenstelling tot de klassieke apktool + jarsigner-combinatie, waarbij decompilatie van grote obfusceerde projecten vaak crasht met fouten, is deze aanpak sneller en betrouwbaarder. Resources en manifest worden direct aangepast, waarna de loader wordt geïnjecteerd.

Gebruiksopties

Je kunt op twee manieren met het hulpmiddel werken: op een computer via terminal of direct op je telefoon.

Optie 1. Console via jar

Als je testbuild-assemblage automatiseert op CI of software analyseert op een werkstation, is het handiger om het kant-en-klare jar-bestand uit de releases te pakken:

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

Het hulpprogramma neemt de bron-APK en modules om in te bedden als invoer. De uitvoer is een kant-en-klaar gewijzigd pakket dat alleen hoeft te worden ondertekend met een testkey en te worden geïnstalleerd via adb install.

Optie 2. Apparaatbeheerder

Voor alledaagse taken is het eenvoudiger om manager.apk te downloaden uit de releases-sectie op GitHub.

1. Installeer de beheerder op je Android-apparaat.
2. Selecteer een geïnstalleerde app of een lokaal APK-bestand.
3. Geef de Xposed-modules op die bij het opstarten moeten laden.
4. De beheerder bouwt een nieuw installatiepakket en suggereert het origineel te verwijderen voordat de modificatie wordt geïnstalleerd.

Omdat de app-handtekening onvermijdelijk verandert tijdens het opnieuw verpakken, kun je het oorspronkelijke programma niet meer over de gewijzigde versie updaten. Je zult het moeten verwijderen, waardoor lokale data verloren gaan als er geen synchronisatie was.

Praktische gebruiksscenario's

Ik gebruik deze patchers regelmatig bij reverse engineering en het testen van mobiele clients.

• SSL Pinning omzeilen voor verkeersinterceptie. Verkeer wrappen in Burp Suite of mitmproxy is veel eenvoudiger wanneer je een module zoals TrustMeAlready of JustTrustMe direct in de APK kunt inbedden. Geen noodzaak om certificaten naar de systeemstore te pushen via Magisk.
• Instrumentatie en logboekverzameling. Als je wilt zien welke argumenten worden doorgegeven aan privémethoden in een SDK van derden, schrijf je een kleine Xposed-hook, injecteer je deze in de build en log je de call stack naar logcat.
• Modules testen op schone apparaten. Module-ontwikkelaars vinden het nuttig om te controleren hoe hun code zich geïsoleerd gedraagt zonder systeem-LSPosed.

Valkuilen en beperkingen

De rootloze aanpak heeft natuurlijke grenzen waar je van tevoren van op de hoogte moet zijn:

• Systeemmodules werken niet. Als een hook ontworpen is om het gedrag van SystemUI, notitievensters of Android-services te veranderen, is NPatch hier machteloos. Het leeft strikt binnen het gebruikersproces.
• Sommige apps met strikte anti-cheat of geavanceerde zelfbescherming (signature-integriteitscontroles, detectie van vreemde .so-bestanden) zullen de manipulatie detecteren en bij het opstarten afsluiten.
• De documentatie in de repository is nog steeds schaars. De meeste details worden besproken in de Telegram-chat van het project, en verse builds moeten vaak rechtstreeks uit GitHub Actions-artifacts worden gehaald.

Is het de moeite waard om te proberen

Als je periodiek onder de motorkap van een Android-app van derden moet duiken of snel een hypothese wilt testen zonder je apparaat te flashen, voeg dan npatch.jar toe aan je gereedschapskist. Het project houdt de LSPatch-codebase actueel en verwerkt het opnieuw verpakken van apps voor nieuwere Android-versies zonder problemen.