Alors que l'ingénierie inverse des applications Android, il est relativement courant d'effectuer une analyse dynamique en conjonction avec une analyse statique afin d'obtenir des informations d'exécution de l'application.
Il existe de nombreuses façons d'obtenir ces informations à partir d'applications tierces
- Utiliser les crochets Frida pour imprimer les arguments de la fonction
- Patcher l'application pour qu'elle soit débogable
- Corrigez l'application pour enregistrer les informations sensibles
Les méthodes ci-dessus ont plusieurs défauts, Frida ne peut accrocher qu'une fonction spécifique avant ou après la fonction, et le braconnage des applications est relativement complexe et provoque presque toujours des bogues dans l'application.
De plus, de nombreux packers / malwares détectent les APK modifiés et plantent pour rendre intentionnellement l'analyse plus difficile.
De meilleures solutions pour le débogage des applications Android tierces
Je suis un grand fan du débogueur Android Studio (JDWP sous le capot), car vous pouvez facilement configurer des points d'arrêt, modifier le code et même y ajouter de la logique, le tout au moment de l'exécution, à partir de votre IDE préféré.
Malheureusement, pour ce faire, vous devez recompiler les applications, ce qui a une forte probabilité d'échec.
Comme mon appareil est enraciné et hautement personnalisé, j'ai décidé de trouver un moyen de rendre toutes les applications débogables.
Recherche AOSP
Afin de déboguer une application, Android Studio communique avec l'application en utilisant JDWP sur la communication ADB, comme le montre le graphique de très haut niveau :
Si vous êtes intéressé par une explication plus approfondie de l'implémentation, c'est votre jour de chance, car pour une raison quelconque, quelqu'un des gars de l'AOSP a écrit un domcatuion assez décent à
/combustion propre/core/adb/jdwp_service.cpp
D'autres recherches de l'AOSP ont révélé la
Cela, s'il est défini comme indicateur pour zygote lors de l'initialisation d'une nouvelle application, rendra l'application débogable.
Plus intéressante est la fonction "applyDebuggerSystemProperty »
Apparemment, il existe déjà un support pour mes besoins de débogage et tout ce que j'ai à faire est de définir la propriété système ro.debuggable sur 1.
Modification de l'image de démarrage
Apparemment, toutes les propriétés système ro.* se trouvent sous l'image de démarrage de l'appareil et ne peuvent pas être définies à l'aide de la commande standard "adb shell setprop".
De plus, remonter seul ne fera pas l'affaire.
Il existe des méthodes spécifiques à l'appareil pour flasher les images de démarrage modifiées, mais la plupart d'entre elles ne sont pas simples et nécessitent une connaissance relativement importante du processus de démarrage Android.
J'ai décidé de trouver une approche plus simple et heureusement pour moi, quelqu'un a déjà construit un module magisk qui fait exactement cela
Paramètres cachés
Installez-le et vous pourrez modifier la propriété à partir du shell adb.
Également à partir d'Android 10 et supérieur système en tant que racine est implémenté afin que vous puissiez simplement passer aux propriétés système ro. * à l'aide de montages
monter -o rw,remonter /
vi /default.prop
# remplacer ro.debuggable=0 par ro.debuggable=1 dans /default.prop
reboot
Débogage
Tout est débogable maintenant - utilisez simplement "attach debugger" (utilisez Java uniquement sinon cela échoue) !
Si vous souhaitez déboguer des fichiers smali et non Java, utilisez ce plugin :
https://github.com/JesusFreke/smalidea
Vous voulez en savoir plus ?
Une réunion de conseil gratuite incluse.
