apk-reverse

ACTION REQUISE (à exécuter immédiatement après la lecture)

Les références communautaires pour l'extraction de points d'entrée / l'adaptation Frida, etc. : ../references/community-security-skills.md ; l'analyse dynamique nécessite un appareil autorisé par le scope.

1. MAINTENANT : Lire ../field-journal/precedent-reverse.md — confirmer que l'opération de cette compétence est une opération régulière autorisée
2. MAINTENANT : Confirmer que la tâche actuelle correspond au champ d'application de cette compétence
3. SUIVANT : Lire ../tool-index.md, vérifier la disponibilité et le chemin réel des outils
4. SUIVANT : Si un outil manque, appeler le bootstrap, ne pas deviner le chemin
5. AGIR : Entrer dans la première étape du "flux de travail" et exécuter, ne pas rester en état de confirmation

Spécifications de travail pour le reverse engineering CLI d'APK

Champ d'application

Utiliser cette compétence en priorité lorsque la tâche correspond à l'un des scénarios suivants :

• Analyser la logique métier Java d'un APK
• Localiser les mécanismes de connexion, signature, anti-risque, vérification de certificat, détection root
• Consulter et modifier AndroidManifest.xml
• Consulter et modifier du smali
• Reconditionner un APK
• Effectuer du hook dynamique Java/natif avec Frida
• Basculer vers l'analyse native lorsque l'APK contient des fichiers .so

Outils CLI disponibles et vérifiés sur la machine actuelle

• jadx 1.5.5
• apktool 3.0.2
• frida-ps 17.9.6
• adb
• java

Scénarios où privilégier l'utilisation de scripts

Les flux suivants sont fréquents et les paramètres sujets à erreur : privilégier les scripts fournis par la compétence :

• Décompilation complète avec jadx + apktool et production d'un résumé : scripts/decode.ps1
• Vérification des appareils Frida, énumération des processus, injection spawn/attach : scripts/frida-run.ps1
• Reconstruction, alignement, signature, installation de l'APK : scripts/rebuild-sign-install.ps1
• Extraction rapide des composants clés et des permissions du Manifest : scripts/manifest-summary.ps1

Les commandes suivantes restent des appels directs, sans encapsulation dédiée :

• adb devices
• adb logcat
• frida-ps -U
• jadx --version
• apktool --version

Scripts fournis

scripts/decode.ps1

Utilisation :

• Exécute jadx et apktool de manière unifiée
• Crée par défaut un répertoire de sortie de tâche dans le même dossier que l'APK d'origine
• Produit un résumé incluant package, java_files, smali_dirs, so_files, etc.
• Compatible avec les cas où jadx rencontre des erreurs de décompilation partielles mais produit quand même des résultats utilisables

Exemple :

pwsh -File "<skill-root>\apk-reverse\scripts\decode.ps1" -ApkPath "D:\DOWNLOAD\app.apk" -Clean
pwsh -File "<skill-root>\apk-reverse\scripts\decode.ps1" -ApkPath "D:\DOWNLOAD\app.apk" -Name demo -SkipJadx

scripts/frida-run.ps1

Utilisation :

• Point d'entrée unifié pour les appareils, processus et spawn/attach Frida
• Évite les confusions entre -f, -n, -U lors de l'écriture manuelle des paramètres

Exemple :

pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -ListDevices
pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -Usb -ListProcesses
pwsh -File "<skill-root>\apk-reverse\scripts\frida-run.ps1" -Usb -Spawn -Package com.example.app -ScriptPath "D:\hooks\test.js"

scripts/rebuild-sign-install.ps1

Utilisation :

• Reconstruction de l'APK avec apktool b
• Alignement avec zipalign
• Signature et vérification avec apksigner
• Installation optionnelle directe via adb install

Exemple :

pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "C:\work\apktool_out" -Clean
pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "C:\work\apktool_out" -Install -Reinstall -DeviceSerial "127.0.0.1:7555"

Remarque :

• Génère et réutilise un keystore de débogage par défaut
• Sortie par défaut dans le même dossier que ProjectDir, facilitant le regroupement avec le package original et le répertoire de dépaquetage

scripts/manifest-summary.ps1

Utilisation :

• Extraire le nom du package
• Lister les permissions
• Lister les activity/service/receiver/provider
• Identifier l'activity de lancement principale

Exemple :

pwsh -File "<skill-root>\apk-reverse\scripts\manifest-summary.ps1" -ManifestPath "C:\work\apktool_out\AndroidManifest.xml"

Pour analyser les fichiers .so, lib/arm64-v8a/*.so, lib/armeabi-v7a/*.so, combiner avec :

• ida-reverse
• radare2

Répartition des outils

jadx

Utilisé pour :

• Lecture du code Java décompilé
• Recherche de noms de packages, classes, méthodes
• Compréhension de l'APK au niveau logique supérieur

Commandes courantes :

jadx -d jadx_out app.apk
jadx --single-class com.example.LoginActivity -d jadx_out app.apk
jadx --deobf -d jadx_out app.apk

JEB Pro (outil commercial optionnel)

Utilisé pour :

• Validation croisée et décompilation approfondie des DEX / APK / ARM Android
• Complément d'analyse statique lorsque la sortie de JADX est incomplète ou fortement obscurcie
• Vérification des classes, méthodes et relations d'appel sur une même cible via une deuxième chaîne d'outils

Limites :

• JEB Pro est un logiciel commercial ; l'utilisateur doit l'obtenir et installer une licence valide par lui-même ; ce package ne télécharge, ne cracke ni ne contourne pas la licence.
• Utiliser uniquement si tool-index confirme que JEB est disponible sur la machine ; sinon continuer avec jadx, apktool, Ghidra, IDA ou radare2.
• Un éventuel bridge MCP tiers pour JEB n'est pas une dépendance de ce package. Avant toute installation, le code source, les permissions, le comportement réseau et la version doivent être audités conformément à ../ops/skill-supply-chain.md, puis confirmés explicitement par l'utilisateur.

apktool

Utilisé pour :

• Dépaqueter un APK
• Consulter et modifier AndroidManifest.xml
• Consulter et modifier du smali
• Reconstruire un APK

Commandes courantes :

apktool d app.apk -o apktool_out
apktool b apktool_out -o rebuilt.apk

frida

Utilisé pour :

• Observer dynamiquement les appels de méthodes Java
• Hooker les fonctions exportées natives
• Contourner la détection root, la vérification de certificat, la détection de débogage

Commandes courantes :

frida-ps -U
frida -U -f com.example.app -l hook.js
frida-trace -U -f com.example.app -j '*!*certificate*'

adb

Utilisé pour :

• Connexion aux appareils
• Installation d'APK
• Consultation des logs
• Récupération de fichiers

Commandes courantes :

adb devices
adb install -r app.apk
adb shell pm list packages
adb logcat
adb pull /data/local/tmp/file .

Flux de travail recommandé

1. Triage

Déterminer d'abord la composition générale de l'APK, sans se précipiter pour modifier le package ou hooker.

Actions suggérées :

1. Utiliser jadx -d jadx_out app.apk pour exporter le code Java
2. Utiliser apktool d app.apk -o apktool_out pour exporter le smali et les ressources
3. Examiner d'abord :
   • AndroidManifest.xml
   • Le package principal
   • application, activity, service, receiver
   • La présence de fichiers .so dans le répertoire lib/
4. Vérification rapide des formes de menace Issue #65 (échantillons/appareils autorisés ; voir ../reverse-engineering/references/nonpe-format-cookbook.md §7–8) :
   • Icône transparente/cachée (AU) : aapt dump badging + manifest theme/label/icon → E-android-hidden-icon-manifest
   • Caractéristiques de Magisk/scripts de wipe et curl|sh distant (AR/AS) → caractéristiques et URL comme preuve, ne pas exécuter les commandes destructrices
   • Chemins de persistance (AT) : service.d / priv-app etc. → E-android-persistence

2. Observation de la logique Java

Lire en priorité depuis jadx_out :

• MainActivity
• Application
• Classes liées à la connexion, au réseau, au chiffrement, à l'anti-risque
• Classes d'initialisation des SDK tiers

Mots-clés courants :

• login
• sign
• encrypt
• cipher
• token
• root
• certificate
• trust
• okhttp
• retrofit
• webview

Si le code Java est lisible, localiser d'abord la logique métier ici.

3. Confirmation au niveau smali et ressources

Quand le résultat de jadx est incomplet, fortement obscurci, ou qu'un patch est nécessaire, basculer vers apktool_out :

• Examiner smali*/
• Examiner res/values/strings.xml
• Examiner AndroidManifest.xml

Patcher en priorité :

• android:exported
• Les marqueurs de débogage
• Les valeurs de retour de détection root
• La logique de vérification de connexion
• Les branches de vérification de certificat

4. Reconstruction et installation

Après modification :

apktool b apktool_out -o rebuilt.apk

Ou utiliser le script pour une boucle fermée :

pwsh -File "<skill-root>\apk-reverse\scripts\rebuild-sign-install.ps1" -ProjectDir "apktool_out" -Install -Reinstall -DeviceSerial "127.0.0.1:7555"

Remarque :

• Cette compétence garantit uniquement la chaîne de reconstruction via apktool
• Si une installation formelle sur un appareil est nécessaire par la suite, une étape de signature est généralement requise
• Si la tâche entre dans la phase de signature/alignement, compléter avec apksigner / zipalign

5. Hook dynamique

En cas d'analyse statique insuffisante, utiliser Frida :

• Hooker la fonction de connexion
• Hooker les points clés OkHttp / Retrofit / WebView
• Hooker javax.crypto, MessageDigest
• Hooker les fonctions de détection root
• Hooker la logique SSL pinning

Principes :

• Hooker d'abord la couche Java, puis voir si un hook natif est nécessaire
• Afficher d'abord les paramètres et les valeurs de retour, puis décider de modifier activement ou non les valeurs de retour

Suggestions :

• Pour les commandes simples et uniques, utiliser directement frida-*
• Pour les flux d'injection nécessitant une réutilisation stable, privilégier scripts/frida-run.ps1

6. Délégation native .so

Si l'APK contient des fichiers .so critiques :

• Utiliser apktool ou jadx pour trouver lib/**/*.so
• Pour un simple export de symboles, chaînes de caractères ou triage rapide, utiliser radare2
• Pour une analyse approfondie, décompilation, renommage, restauration de types, utiliser ida-reverse

Passer rapidement à l'analyse native face à ces signaux :

• La couche Java n'est qu'un wrapper JNI
• La logique de signature principale n'est pas en Java
• La logique critique disparaît après System.loadLibrary()
• La vérification de certificat/anti-risque se trouve dans les fichiers .so

Exigences de sortie

Au minimum, préciser :

• Les composants d'entrée et les classes clés
• Si la logique critique se trouve en Java, smali ou .so
• Les points sensibles identifiés : connexion, signature, root, SSL, WebView, JNI
• Si un patch a été effectué, décrire ce qui a été modifié
• Si un hook a été effectué, décrire quelle classe/méthode/fonction exportée a été hookée

Interdictions

• Ne pas modifier aveuglément du smali dès le début
• Ne pas écrire de hook sans avoir consulté le manifest et l'entrée principale
• Ne pas considérer une décompilation Java incomplète comme une "logique non analysable"
• Ne pas persister à analyser la couche Java quand les fichiers .so portent clairement la logique principale

Aide-mémoire des commandes rapides

# Décompiler le Java
jadx -d jadx_out app.apk

# Dépaqueter l'APK
apktool d app.apk -o apktool_out

# Reconstruire l'APK
apktool b apktool_out -o rebuilt.apk

# Appareils et processus
adb devices
frida-ps -U

# Lancer et injecter
frida -U -f com.example.app -l hook.js

---

Contexte de routage

Entrée amont : skills/SKILL.md (contrôle principal), routing.md Sortie aval :

• Logique principale dans .so → ida-reverse/ ou radare2/
• Hook/vérification dynamique nécessaire → reverse-engineering/tools-dynamic.md (section Frida)
• Méthodologie générale de reverse engineering → reverse-engineering/SKILL.md

Modules associés de même niveau : reverse-engineering/ (analyse .so et utilisation avancée de Frida)

---

Bootstrap à la demande

Les scripts d'entrée de cette compétence sont intégrés au système de bootstrap unifié. En cas d'outil manquant, une erreur n'est pas directement levée mais une tentative d'installation automatique est effectuée.

Périmètre d'automatisation

Outil	Installation automatique	Méthode d'installation	Remarque
jadx	✓	GitHub Release ZIP	Téléchargement et extraction automatiques dans %USERPROFILE%\Tools\jadx\
apktool	✓	GitHub Release JAR + wrapper	Téléchargement automatique du jar et génération du bat dans %USERPROFILE%\Tools\apktool\
JEB Pro	✗	Installation manuelle par l'utilisateur avec licence valide	Outil optionnel de validation croisée Android / ARM ; tout bridge MCP tiers nécessite un audit séparé
frida / frida-ps	✓	pip install frida-tools	Nécessite Python installé
adb	✓	winget / chemin de repli	Installation automatique d'Android Platform-Tools
zipalign	✗	Installation manuelle Android Build-Tools	sdkmanager "build-tools;35.0.0"
apksigner	✗	Installation manuelle Android Build-Tools	Idem

Points de déclenchement du bootstrap

• scripts/decode.ps1 : appelle automatiquement bootstrap-reverse.ps1 si jadx ou apktool manque
• scripts/rebuild-sign-install.ps1 : appelle automatiquement le bootstrap si adb ou apktool manque
• scripts/frida-run.ps1 : vérification manuelle pour l'instant (frida est généralement installé via pip)

En cas d'échec du bootstrap

Si l'installation automatique échoue, le script lèvera une erreur explicite avec un lien d'installation manuelle. Causes courantes :

• Réseau inaccessible (GitHub API / PyPI injoignable)
• winget indisponible (version de Windows trop ancienne)
• Java non installé (apktool dépend du JDK)

Auto-vérification avant de déclarer la tâche terminée (DOIT passer)

• Ai-je exécuté chaque étape du flux de travail (et pas seulement lu) ?
• Ai-je utilisé les vrais chemins d'outils basés sur tool-index ?
• Ai-je produit des preuves reproductibles (commandes/scripts/captures d'écran/rapports) ?
• Ai-je complété et renseigné les éléments de la Checklist requis par RULES ?
• En cas d'indice d'icône cachée/wipe/persistance : ai-je enregistré la preuve E-android-* conformément au cookbook U–AV (dans le périmètre autorisé) ?