Vous voulez connaître les méthodes de protection courantes des applications Android et leurs méthodes d'analyse inverse correspondantes ?
Dans ce partage, plusieurs aspects de la sécurité de l'application Android sont abordés, notamment le code obscurci, le renforcement global de Dex, le renforcement de Dex fractionné et le renforcement de la machine virtuelle. Ces contenus sont devenus une tendance majeure dans la protection de la sécurité des applications Android en Chine ces dernières années.
Le code Java est très facile à décompiler. En tant que langage interprété multiplateforme, le code source Java est compilé en "bytecode" intermédiaire et stocké dans des fichiers de classe. En raison de la nécessité d'être multiplateforme, ces bytecodes contiennent une grande quantité d'informations sémantiques et sont facilement décompilés en code source Java. Les développeurs masquent souvent les fichiers de classe compilés pour mieux protéger le code source Java.
L'obscurcissement consiste à réorganiser et traiter le programme publié afin que le code traité remplisse la même fonction que le code prétraité. Le code obscurci est difficile à décompiler Même si la décompilation réussit, il est difficile d'obtenir l'identité du programme. .Une vraie sémantique. ProGuard est un projet open source qui peut obscurcir, réduire et optimiser le bytecode.
L'organigramme de traitement Proguard est présenté ci-dessous, comprenant quatre liens principaux : compression, optimisation, obfuscation et pré-vérification :
Compression (Shrink) : détecte et supprime les classes, champs, méthodes et attributs inutiles ;
Optimiser : optimisez le bytecode et supprimez les instructions inutiles. Optimisez le code, les classes de nœuds sans entrée seront ajoutées avec private/static/final, les paramètres inutilisés seront supprimés et certaines méthodes peuvent devenir du code en ligne
Obfuscate : utilisez a, b, c, d Renommez les classes, les champs et ; des méthodes avec des noms aussi courts et dénués de sens ;
Preveirfy : contrôle en amont du code traité sur la plate-forme Java pour garantir que le fichier de classe chargé est exécutable.
Dans le partage, Zhong Yaping a montré un exemple de l'effet Apk après avoir utilisé Proguard pour décompiler Dex2jar :
Après le traitement de Proguard
L'obfuscateur Proguard peut non seulement protéger le code, mais également rationaliser La taille du programme compilé réduit l'utilisation de la mémoire.
Zhong Yaping a partagé un outil étranger appelé DEGUADR, qui utilise des méthodes statistiques pour désobscurcir le code destiné à la décompilation. Bien que la précision de cet outil ne soit pas de 100 %, il peut quand même aider partiellement à décompiler le code.
Exemple d'utilisation de DEGUADR pour désobscurcir :
Le site Web com.xxxxx.common.util.CryptoUtil fournit également un service de décompilation, comme indiqué ci-dessous :
java.lang.String a(byte[]) -> encodeToStringjava.lang.String a(byte[],boolean,java.lang.String) -> a byte[] a(byte[],byte[]) -> encrypt byte[] b(byte[]) -> getKey byte[] b(byte[],byte[]) -> decrypt byte[] d(java.lang.String) -> getKey java.lang.String a(byte,char[]) -> a java.lang.String a(java.io.File) -> getHash java.lang.String a(java.lang.String) -> c java.lang.String b(java.lang.String) -> encode
Avec le développement continu de la technologie de sécurité, une nouvelle « technologie de renforcement » est apparue pour améliorer la force de protection d'Android. Le renforcement DEX consiste à emballer et à protéger les fichiers DEX pour éviter qu'ils ne soient piratés par des outils de décompilation statique et que le code source ne soit divulgué. La première à apparaître est la solution technologique globale de renforcement.
Le principe de la technologie de renforcement globale est tel qu'indiqué ci-dessus, y compris le remplacement de application/classes.dex, le déchiffrement/le chargement dynamique du classes.dex d'origine, l'appel des méthodes liées à l'application d'origine et la définition de l'objet d'application d'origine/ nom des variables internes pertinentes du système Quatre liens majeurs. L'étape la plus critique consiste à décrypter/charger dynamiquement le fichier classes.dex d'origine, à chiffrer le fichier de code source dex final compilé, puis à utiliser le démarrage de l'application du nouveau projet dans un nouveau projet pour décrypter le code du projet d'origine et le charger en mémoire, et Ensuite, le processus actuel est remplacé par le code déchiffré, ce qui peut bien cacher le code source et empêcher la décompilation directe.
Il existe deux méthodes couramment utilisées pour l'analyse globale inversée du renforcement Dex. La première consiste à rechercher violemment dexn035 dans la mémoire, puis à le vider. Voici un exemple de l'effet sur un système 32 bits :
Une autre méthode consiste à utiliser HookdvmDexFileOpenPartial(void* addr, int len, DvmDex**).
À mesure que l'échelle de l'entreprise se développe dans une certaine mesure, de nouvelles fonctions et de nouvelles bibliothèques de classes sont constamment ajoutées. Tandis que le code se développe rapidement, le package apk correspondant La taille a. a également augmenté de façon spectaculaire, de sorte que la solution globale de renforcement simple ne peut pas bien répondre aux exigences de sécurité. En plus de la solution de renforcement globale, des solutions techniques de renforcement fractionné ont émergé.
Mais comme indiqué ci-dessus, lorsque le fichier dex est renforcé, certaines des données manquantes seront parfois remplacées par des données décryptées. cette division et ce remplacement peuvent également conduire à des données inexactes. Vous devez comprendre la structure des données du fichier dex pour déterminer quel type de données doit être fractionné.
La structure du fichier Dex est extrêmement complexe. L'illustration suivante sélectionne les contenus les plus importants. En fait, un fichier dex est un fichier assemblé avec la classe comme noyau. Les parties les plus importantes sont les données de classe et le code de classe, qui ont leurs propres interfaces et données d'instructions spécifiques. Si vous choisissez de diviser ces deux parties, même si elles sont divisées, cela ne fonctionnera pas. Les données de classe et les données de bytecode ne seront pas divulguées et la décompilation ne sera pas complète, la sécurité est donc élevée.
L'analyse inverse du renforcement divisé Dex est la suivante, peut être remplacé par classdata pour assembler un nouveau fichier dex Bien qu'il ne soit pas complètement cohérent avec le fichier dex d'origine, il restaure également dans une certaine mesure l'apparence des données divisées.
Cependant, il convient de noter que cette méthode ne convient que pour que la transformation des données fractionnées soit effectuée en une seule fois, c'est-à-dire pour dire, essayez d'éviter de l'utiliser lorsqu'il existe d'autres idées de protection, et même si nécessaire, essayez de le restaurer uniquement lorsque cette classe est utilisée.
De plus, il existe un outil de niveau inférieur appelé dexhunter. Cet outil est plus avant-gardiste, mais il présente également certaines limites. Par exemple, certaines données de commande seront optimisées, ainsi que le code résultant. l'interface n'est pas très belle, etc.
Le traitement des octets est un moyen de renforcer les machines virtuelles, peut également être considéré comme une sorte de division et de renforcement dex. Ce qui suit est un code système Android conventionnel qui a été renforcé par une machine virtuelle
Remplacez les trois instructions int v0, v1, v2 et mul-int v0, v1, v2, puis effectuer une compilation de durcissement. Après cette opération, même si les données remplacées sont restaurées, elles ne seront pas restaurées en tant que add-int v0, v1, v2, sub-int v0, v1, v2, mul-int v0, v1, v2, ces trois instructions sont remplacées, puis renforcées et compilées. Après cette opération, même si les données remplacées sont restaurées, elles ne seront pas transformées en Le bytecode précédent avait un facteur de sécurité plus élevé.
GetStaticDoubleFieldSetStaticDoubleField GetDoubleField SetDoubleField …
(byte , object , int, long ...)#🎜🎜 ## 🎜🎜 ## 🎜🎜#La seconde est la méthode d'appel par réflexion, telle que :#🎜🎜 ## 🎜🎜CallObjectMethodA(JNIEnv * env, objet jobject, méthode jmethoID, … )CallvoidMethodAllBooleanMethoda CallshortMethodmethoda ...# 🎜🎜 ## 🎜 🎜#CallStaticVoidMethodACallStaticBooleanMethodA CallStaticShortMethodA CallStaticObjectMethodA …
(byte, int, long,double …)
Analyse inverse du renforcement de machine virtuelle via l'interface HOOKJNIL'utilisation de l'interface HOOK JNI permet de comprendre le processus d'appel général du APP sans avoir besoin d’ingénierie inverse sous-jacente. Cependant, pour des processus d'appel complexes, ou lorsqu'il existe un grand nombre de méthodes de virtualisation, cette méthode d'analyse inverse semblera déroutante pour les instructions qui n'ont pas besoin d'être renvoyées vers la couche Java pour être exécutées, comme les opérations arithmétiques et logiques ; il ne peut pas être surveillé arriver. Analyse inverse de durcissement de la machine virtuelle : analyser le mappage des opcodes d'instructionD'un autre côté, l'analyse inverse peut également être effectuée en analysant le mappage des opcodes d'instruction. Les méthodes suivantes peuvent être utilisées lorsque vous utilisez la même version de renforcement ou relation de mappage :
Établir une relation de mappage.
Il est lié à la structure de la machine virtuelle, il doit donc être établi en fonction de la relation de mappage de la relation de décalage pour effectuer une analyse inverse.
#
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!