Jak uruchamiać moduły Xposed bez dostępu root za pomocą NPatch

Gdy zachodzi potrzeba grzebania w cudzej aplikacji na Androida, obejścia SSL pinningu lub włączenia ukrytego debugowania, zwykle pierwszym odruchem jest sięgnięcie po Magisk lub KernelSU. Jednak rootowanie telefonu używanego na co dzień tylko dla jednego narzędzia jest niewygodne. Aplikacje bankowe zaczynają się skarżyć, Play Integrity przestaje działać, a na urządzeniach firmowych root jest wręcz zabroniony przez polityki bezpieczeństwa.

Przez długi czas problem ten rozwiązywał projekt LSPatch. Pobierał gotowy plik APK, osadzał w nim runtime LSPosed oraz niezbędne hooki, po czym aplikacja mogła działać z modułami Xposed bez uprawnień systemowych. Gdy oryginalny LSPatch przestał być aktywnie rozwijany, jego fork o nazwie NPatch (Neo LSPatch) wypełnił powstałą lukę.

Co robi to narzędzie

Projekt pobiera zwykły plik APK i przepakowuje go. Do archiwum wstrzykiwane są pliki DEX loadera oraz natywne biblioteki (.so) odpowiedzialne za przechwytywanie wywołań ART (Android Runtime). Gdy uruchomiona zostanie spatchowana aplikacja, najpierw startuje ta osadzona warstwa. Inicjalizuje środowisko wykonawcze API Xposed bezpośrednio w izolowanym procesie aplikacji.

Dla reszty systemu to zwykły program użytkownika. Nie wymaga uprawnień superużytkownika, nie dotyka partycji systemowej /system i nie próbuje niczego zastępować zygote. Wszystkie modyfikacje i hooki są ściśle zamknięte w sandboxzie tego konkretnego pakietu.

Obsługiwane są wersje od Androida 9 wzwyż, kompatybilne z bazą kodu JingMatrix/LSPosed.

Jak działa proces patchowania

Pod maską NPatch bazuje na pracy kilku projektów open source:

• LSPosed obsługuje wywołania API Xposed i przechwytywanie metod runtime w ART.
• Xpatch dostarczył podstawową koncepcję wstrzykiwania kodu do APK bez interwencji systemowej.
• Apkzlib służy do rozpakowywania, modyfikowania archiwum zip i szybkiego przepakowywania bez pełnej dekompresji do smali.

W przeciwieństwie do klasycznej kombinacji apktool + jarsigner, gdzie dekompresja dużych zaciemnionych projektów często kończy się błędami i awariami, to podejście jest szybsze i bardziej niezawodne. Zasoby i manifest są dostosowywane bezpośrednio, a następnie loader jest wstrzykiwany.

Opcje użycia

Z narzędziem można pracować na dwa sposoby: na komputerze przez terminal lub bezpośrednio na telefonie.

Opcja 1. Konsola przez jar

Jeśli automatyzujesz assemblację buildów testowych na CI lub analizujesz oprogramowanie na stacji roboczej, wygodniej jest pobrać gotowy plik jar z release'ów:

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

Narzędzie pobiera źródłowy APK i moduły do osadzenia jako dane wejściowe. Wynikiem jest gotowy zmodyfikowany pakiet, który wymaga jedynie podpisania kluczem testowym i instalacji przez adb install.

Opcja 2. Menedżer na urządzeniu

Do codziennych zadań prościej jest pobrać manager.apk z sekcji release'ów na GitHubie.

1. Zainstaluj menedżera na urządzeniu z Androidem.
2. Wybierz zainstalowaną aplikację lub lokalny plik APK.
3. Określ moduły Xposed, które powinny załadować się przy starcie.
4. Menedżer buduje nowy pakiet instalacyjny i sugeruje usunięcie oryginału przed instalacją modyfikacji.

Ponieważ podczas przepakowywania podpis aplikacji nieuchronnie się zmienia, nie będziesz w stanie zaktualizować oryginalnego programu przez ten pakiet. Będziesz musiał go usunąć, tracąc dane lokalne, jeśli nie były zsynchronizowane.

Praktyczne przypadki użycia

Regularnie używam tych patcherów w reverse engineeringu i testowaniu mobilnych klientów.

• Obejście SSL Pinningu na potrzeby przechwytywania ruchu. Owinięcie ruchu w Burp Suite lub mitmproxy jest o wiele prostniejsze, gdy możesz osadzić moduł taki jak TrustMeAlready lub JustTrustMe bezpośrednio w APK. Nie trzeba wpychać certyfikatów do magazynu systemowego przez Magisk.
• Instrumentacja i zbieranie logów. Jeśli chcesz zobaczyć, jakie argumenty są przekazywane do prywatnych metod w zewnętrznym SDK, piszesz niewielki hook Xposed, wstrzykujesz go do builda i logujesz stos wywołań do logcat.
• Testowanie modułów na czystych urządzeniach. Deweloperzy modułów uważają to za przydatne do sprawdzania, jak ich kod zachowuje się w izolacji bez systemowego LSPosed.

Zastrzeżenia i ograniczenia

Podejście bez root ma naturalne granice, o których powinieneś wiedzieć od początku:

• Moduły systemowe nie będą działać. Jeśli hook jest zaprojektowany do zmiany zachowania SystemUI, pasków powiadomień lub usług Androida, NPatch jest tu bezsilny. Działa ściśle wewnątrz procesu użytkownika.
• Niektóre aplikacje z rygorystycznym anty-cheatem lub zaawansowaną ochroną własną (sprawdzanie integralności podpisu, wykrywanie obcych plików .so) wykryją manipulację i zakończą działanie przy starcie.
• Dokumentacja w repozytorium jest nadal skąpa. Większość szczegółów jest omawiana na czacie Telegram projektu, a świeże buildy często trzeba pobierać bezpośrednio z artefaktów GitHub Actions.

Czy warto wypróbować

Jeśli okresowo musisz zaglądać pod maskę obcych aplikacji na Androida lub szybko testować hipotezę bez przeflashowywania urządzenia, dodaj npatch.jar do swojego zestawu narzędzi. Projekt utrzymuje bazę kodu LSPatch na bieżąco i bez problemów radzi sobie z przepakowywaniem aplikacji na nowsze wersje Androida.