Comment exécuter des modules Xposed sans accès root avec NPatch

Quand vous devez explorer une application Android tierce, contourner le SSL pinning ou activer un débogage caché, l'instinct habituel est de se tourner vers Magisk ou KernelSU. Mais rooter un téléphone utilisé au quotidien juste pour un utilitaire est peu pratique. Les clients bancaires commencent à se plaindre, Play Integrity tombe en panne, et sur les appareils d'entreprise le root est purement et simplement interdit par les politiques de sécurité.

Pendant longtemps, ce problème a été résolu par le projet LSPatch. Il prenait un APK prêt, y intégrait un runtime LSPosed et les hooks nécessaires, après quoi l'application s'exécutait avec les modules Xposed sans privilèges système. Lorsque le LSPatch original a cessé d'être activement maintenu, un fork appelé NPatch (Neo LSPatch) a pris le relais pour combler le vide.

Ce que fait cet outil

Le projet prend un fichier APK ordinaire et le reconditionne. À l'intérieur de l'archive, il injecte les fichiers DEX du chargeur et les bibliothèques natives (.so) responsables de l'interception des appels ART (Android Runtime). Lorsque l'application patchée se lance, cette couche embarquée démarre en premier. Elle initialise l'environnement d'exécution de l'API Xposed directement à l'intérieur du processus isolé de l'application.

Pour le reste du système, vous exécutez simplement un programme utilisateur ordinaire. Il n'a pas besoin de droits superutilisateur, ne touche pas à la partition système /system, et ne tente pas de remplacer zygote. Toutes les modifications et tous les hooks sont confinés strictement dans le bac à sable de ce package spécifique.

Les versions à partir d'Android 9 jusqu'aux versions actuelles d'Android compatibles avec la base de code JingMatrix/LSPosed sont prises en charge.

Comment fonctionne le processus de patching

En coulisses, NPatch s'appuie sur le travail de plusieurs projets open source :

• LSPosed gère les appels de l'API Xposed et l'interception des méthodes runtime dans ART.
• Xpatch a fourni le concept central d'injection de code dans un APK sans intervention système.
• Apkzlib est utilisé pour décompresser, modifier l'archive zip et reconditionner rapidement sans décompilation complète en smali.

Contrairement à la combinaison classique apktool + jarsigner, où la décompilation de grands projets obfusqués plante souvent avec des erreurs, cette approche est plus rapide et plus fiable. Les ressources et le manifest sont ajustés directement, après quoi le chargeur est injecté.

Options d'utilisation

Vous pouvez travailler avec l'outil de deux manières : sur un ordinateur via le terminal ou directement sur votre téléphone.

Option 1. Console via jar

Si vous automatisez l'assemblage de builds de test sur CI ou analysez des logiciels sur un poste de travail, il est plus pratique de récupérer le fichier jar prêt à l'emploi depuis les releases :

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

L'utilitaire prend en entrée l'APK source et les modules à intégrer. Le résultat est un package modifié prêt à l'emploi qui n'a plus qu'à être signé avec une clé de test et installé via adb install.

Option 2. Gestionnaire sur l'appareil

Pour les tâches quotidiennes, il est plus simple de télécharger manager.apk depuis la section releases sur GitHub.

1. Installez le gestionnaire sur votre appareil Android.
2. Sélectionnez une application installée ou un fichier APK local.
3. Spécifiez les modules Xposed qui doivent se charger au démarrage.
4. Le gestionnaire construit un nouveau package d'installation et suggère de supprimer l'original avant d'installer la modification.

Comme la signature de l'application change inévitablement lors du reconditionnement, vous ne pourrez pas mettre à jour le programme original par-dessus. Vous devrez le supprimer, ce qui entraînera la perte des données locales si elles n'étaient pas synchronisées.

Cas d'utilisation pratiques

J'utilise régulièrement ces patchers en reverse engineering et lors de tests de clients mobiles.

• Contourner le SSL Pinning pour l'interception de trafic. Encapsuler le trafic dans Burp Suite ou mitmproxy est beaucoup plus simple quand vous pouvez intégrer un module comme TrustMeAlready ou JustTrustMe directement dans l'APK. Pas besoin de pousser des certificats dans le truststore système via Magisk.
• Instrumentation et collecte de logs. Si vous avez besoin de voir quels arguments sont passés aux méthodes privées d'un SDK tiers, vous écrivez un petit hook Xposed, l'injectez dans le build, et loguez la pile d'appels dans logcat.
• Tester des modules sur des appareils propres. Les développeurs de modules trouvent cela utile pour vérifier comment leur code se comporte en isolation sans LSPosed système.

Avertissements et limitations

L'approche sans root a des limites naturelles que vous devez connaître à l'avance :

• Les modules système ne fonctionneront pas. Si un hook est conçu pour modifier le comportement de SystemUI, des tiroirs de notification ou des services Android, NPatch est impuissant ici. Il vit strictement à l'intérieur du processus utilisateur.
• Certaines applications avec un anti-cheat strict ou une auto-protection avancée (vérifications d'intégrité de signature, détection de fichiers .so étrangers) détecteront la manipulation et quitteront au démarrage.
• La documentation dans le dépôt est encore clairsemée. La plupart des détails sont discutés dans le chat Telegram du projet, et les builds récents doivent souvent être récupérés directement depuis les artifacts GitHub Actions.

Cela vaut-il la peine d'essayer

Si vous avez périodiquement besoin de fouiller dans les entrailles d'une application Android tierce ou de tester rapidement une hypothèse sans reflasher votre appareil, ajoutez npatch.jar à votre boîte à outils. Le projet maintient la base de code LSPatch à jour et gère le reconditionnement des applications pour les nouvelles versions d'Android sans problème.