Pentesting des Applications Android

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

Bases des Applications Android

Il est fortement recommandé de commencer par lire cette page pour connaître les éléments les plus importants liés à la sécurité Android et les composants les plus dangereux d’une application Android :

Android Applications Basics

ADB (Android Debug Bridge)

C’est l’outil principal dont vous avez besoin pour vous connecter à un appareil Android (émulé ou physique).
ADB permet de contrôler les appareils soit via USB soit via Network depuis un ordinateur. Cet utilitaire permet la copie de fichiers dans les deux sens, l’installation et la désinstallation d’apps, l’exécution de commandes shell, la sauvegarde de données, la lecture des logs, entre autres fonctions.

Consultez la liste suivante des ADB Commands pour apprendre à utiliser adb.

Smali

Parfois il est intéressant de modifier le code de l’application pour accéder à des informations cachées (par exemple des mots de passe ou flags fortement obfusqués). Dans ce cas, il peut être utile de décompiler l’APK, modifier le code et le recompiler.
In this tutorial you can learn how to decompile and APK, modify Smali code and recompile the APK with the new functionality. Cela peut être très utile comme alternative pour plusieurs tests lors de l’analyse dynamique qui vont être présentés. Donc, gardez toujours cette possibilité en tête.

Other interesting tricks

Automated multi-source APK acquisition (justapk)

pip install justapk (Python 3.11+). La CLI renvoie du JSON sur stdout et les progrès sur stderr (compatible pipeline). Elle tente une chaîne de fallback déterministe à travers APK20 → F-Droid → APKPure (mobile API) → APKMirror (HTML scrape) → Uptodown (mobile API) → APKCombo (HTML scrape). Les sources protégées par Cloudflare utilisent curl_cffi avec impersonation d’empreinte TLS pour imiter de vrais clients et réduire les blocages par détection de bots.

justapk download <package>              # auto fallback
justapk download <package> -s apkpure   # pin a source / version / output dir
justapk search telegram
justapk info org.telegram.messenger
justapk convert app.xapk -o output/      # merges splits, re-signs with debug key

convert fusionne les XAPK/split APKs et les signe avec une debug key, donc la signature/provenance de l’APK résultant diffère de l’original (à utiliser pour tests/analyses, pas pour des installations en production).

  • Extraire l’APK depuis l’appareil :
adb shell pm list packages
com.android.insecurebankv2

adb shell pm path com.android.insecurebankv2
package:/data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk

adb pull /data/app/com.android.insecurebankv2-Jnf8pNgwy3QA_U5f-n_4jQ==/base.apk
  • Fusionnez tous les splits et les apks de base avec APKEditor:
mkdir splits
adb shell pm path com.android.insecurebankv2 | cut -d ':' -f 2 | xargs -n1 -i adb pull {} splits
java -jar ../APKEditor.jar m -i splits/ -o merged.apk

# after merging, you will need to align and sign the apk, personally, I like to use the uberapksigner
java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed

Techniques de malware Android (loaders, fileless DEX, persistence)

Native staging + fileless DEX loaders

Certains droppers Android intègrent une bibliothèque native (lib*.so) qui décrypte et écrit un second ELF (par ex., l.so) dans un chemin temporaire, le charge via JNI, puis charge la logique réelle en tant que DEX uniquement en mémoire en utilisant dalvik.system.InMemoryDexClassLoader. Cela réduit la visibilité statique du payload et évite d’écrire classes*.dex sur le disque.

Points pratiques pour le triage :

  • Recherchez des libs natives qui appellent dlopen ou System.loadLibrary très tôt, puis résolvent des méthodes Java via des chaînes obfusquées sur la pile (par ex., décodées par XOR sur la pile).
  • Surveillez InMemoryDexClassLoader dans les logs/strings ou les hooks, ce qui indique une exécution fileless DEX.

Quick Frida hook to dump the in‑memory DEX buffer:

Java.perform(() => {
const IM = Java.use('dalvik.system.InMemoryDexClassLoader');
IM.$init.overload('java.nio.ByteBuffer','java.lang.ClassLoader').implementation = function(buf, parent){
const arr = Java.array('byte', buf.array());
const fos = Java.use('java.io.FileOutputStream').$new("/sdcard/memdex.dex");
fos.write(arr); fos.close();
return this.$init(buf, parent);
};
});

Anti-analysis kill-switch

Les packed loaders se self-terminate souvent lorsque les vérifications d’émulateur ou d’analyse échouent (par ex., validation de CPU_ABI) en appelant :

android.os.Process.killProcess(android.os.Process.myPid());

Persistance via foreground service + MediaPlayer loop

Un pattern léger de persistance consiste à garder un foreground service actif avec une notification épinglée et à jouer en continu une boucle audio presque inaudible via MediaPlayer. Cela maintient le processus « actif » et réduit les kills de l’OS dus à l’inactivité. Recherchez l’utilisation de ForegroundService + MediaPlayer qui boucle un petit asset (souvent de quelques secondes).

Superposition Accessibility + détournement ACTION_SET_TEXT

Après qu’un utilisateur a accordé Accessibility, des banking trojans peuvent surveiller l’foreground app, afficher une superposition réaliste (souvent du WebView HTML stocké en Base64) et remplacer les champs de transaction en utilisant AccessibilityNodeInfo.ACTION_SET_TEXT. Cela permet la substitution silencieuse de l’adresse du destinataire pendant que la victime voit une interface plausible.

Exemple minimal de remplacement de texte:

Bundle args = new Bundle();
args.putCharSequence(AccessibilityNodeInfo.ACTION_ARGUMENT_SET_TEXT_CHARSEQUENCE,
"ATTACKER_USDT_ADDRESS");
node.performAction(AccessibilityNodeInfo.ACTION_SET_TEXT, args);

Legitimate push infrastructure as C2 gating

Au lieu de sockets personnalisés, certains malware utilisent Firebase Cloud Messaging (FCM) comme canal C2. Les messages FCM peuvent déclencher des contrôles de télémétrie (état de charge, % de batterie, température, inactivité de l’utilisateur) et gater des actions comme le mining ou la fraude pour la furtivité.

Encrypted native payload staging with filename‑derived keys

Les payloads natifs peuvent être livrés sous forme de blobs ELF chiffrés et déchiffrés avec CipherInputStream(), en utilisant une clé dérivée du SHA‑1 du nom de fichier téléchargé. Chaque nom de fichier/version produit une clé distincte, rendant la réutilisation statique des IOC plus difficile.

Jezail rooted Android pentesting toolkit (REST API + web UI)

  • S’exécute sur un rooted device (Magisk/rootAVD) et démarre un HTTP server on tcp/8080 avec une Flutter web UI et une REST API.
  • Installez le release APK avec les perms : adb install -g -r jezail.apk, puis lancez l’app (le server démarre automatiquement).
  • Endpoints : http://<device-ip>:8080/ (UI), http://<device-ip>:8080/api/json (API listing), http://<device-ip>:8080/api/swagger (Swagger).
  • Forward de port de l’émulateur pour atteindre l’UI/API depuis l’hôte : adb forward tcp:8080 tcp:8080 puis ouvrez http://localhost:8080.

Android Enterprise & Work Profile Attacks

Android Enterprise Work Profile Bypass

Case Studies & Vulnerabilities

Air Keyboard Remote Input Injection

Android Rooting Frameworks Manager Auth Bypass Syscall Hook

Abusing Android Media Pipelines Image Parsers

Firmware Level Zygote Backdoor Libandroid Runtime

Static Analysis

Tout d’abord, pour analyser un APK vous devriez regarder le code Java à l’aide d’un décompilateur.
Veuillez, lire ici pour trouver des informations sur les différents décompilateurs disponibles.

Looking for interesting Info

Rien qu’en regardant les strings de l’APK vous pouvez chercher des passwords, URLs (https://github.com/ndelphit/apkurlgrep), api keys, encryption, bluetooth uuids, tokens et tout ce qui semble intéressant… cherchez même des backdoors d’exécution de code ou des backdoors d’authentification (identifiants admin hardcodés dans l’app).

Firebase

Faites particulièrement attention aux firebase URLs et vérifiez si la configuration est incorrecte. More information about whats is FIrebase and how to exploit it here.

Basic understanding of the application - Manifest.xml, strings.xml

L’examen du Manifest.xml et des strings.xml d’une application peut révéler des vulnérabilités potentielles. Ces fichiers sont accessibles via des décompilateurs ou en renommant l’APK en .zip puis en le décompressant.

Les vulnérabilités identifiables à partir du Manifest.xml incluent :

  • Debuggable Applications : Les applications définies comme debuggable (debuggable="true") dans le Manifest.xml représentent un risque car elles permettent des connexions pouvant mener à l’exploitation. Pour en savoir plus sur la façon d’exploiter des applications debuggable, référez-vous à un tutoriel sur la découverte et l’exploitation d’applications debuggable sur un device.
  • Backup Settings : L’attribut android:allowBackup="false" doit être explicitement défini pour les applications manipulant des informations sensibles afin d’empêcher les backups non autorisés via adb, surtout quand le usb debugging est activé.
  • Network Security : Les configurations réseau personnalisées (android:networkSecurityConfig="@xml/network_security_config") dans res/xml/ peuvent préciser des détails de sécurité comme les certificate pins et les règles de trafic HTTP. Un exemple est d’autoriser le trafic HTTP pour certains domaines.
  • Exported Activities and Services : Identifier les activities et services exportés dans le manifest peut mettre en évidence des composants susceptibles d’être abusés. Une analyse complémentaire en test dynamique peut révéler comment exploiter ces composants.
  • Content Providers and FileProviders : Des content providers exposés pourraient permettre un accès ou une modification non autorisés des données. La configuration des FileProviders doit aussi être examinée attentivement.
  • Broadcast Receivers and URL Schemes : Ces composants peuvent être utilisés pour l’exploitation, avec une attention particulière à la manière dont les URL schemes gèrent les entrées (risques d’injection).
  • SDK Versions : Les attributs minSdkVersion, targetSDKVersion, et maxSdkVersion indiquent les versions Android supportées, soulignant l’importance de ne pas supporter des versions Android obsolètes et vulnérables.

Depuis le strings.xml, des informations sensibles telles que des API keys, des schemas personnalisés, et d’autres notes de développeurs peuvent être découvertes, soulignant la nécessité d’un examen attentif de ces ressources.

Tapjacking

Tapjacking est une attaque où une malicious application est lancée et se positionne par-dessus une application victime. Une fois qu’elle masque visiblement l’application cible, son interface utilisateur est conçue de façon à tromper l’utilisateur pour qu’il interagisse avec elle, tandis qu’elle retransmet l’interaction à l’application victime.
En pratique, elle empêche l’utilisateur de savoir qu’il effectue en réalité des actions sur l’application victime.

Find more information in:

Tapjacking

Task Hijacking

Une activity avec le launchMode défini sur singleTask sans aucun taskAffinity est vulnérable au Task Hijacking. Cela signifie qu’une application peut être installée et, si elle est lancée avant la vraie application, elle pourrait détourner le task de la vraie application (de sorte que l’utilisateur interagira avec la malicious application en croyant utiliser la vraie).

More info in:

Android Task Hijacking

Insecure data storage

Internal Storage

Sur Android, les fichiers stockés dans le stockage interne sont conçus pour être accessibles exclusivement par l’app qui les a créés. Cette mesure de sécurité est appliquée par le système Android et est généralement suffisante pour la plupart des applications. Cependant, les développeurs utilisent parfois des modes tels que MODE_WORLD_READABLE et MODE_WORLD_WRITABLE pour permettre le partage de fichiers entre différentes applications. Or, ces modes ne restreignent pas l’accès à ces fichiers par d’autres applications, y compris potentiellement malveillantes.

  1. Static Analysis :
  • Vérifiez soigneusement l’utilisation de MODE_WORLD_READABLE et MODE_WORLD_WRITABLE. Ces modes peuvent exposer des fichiers à des accès non souhaités ou non autorisés.
  1. Dynamic Analysis :
  • Vérifiez les permissions définies sur les fichiers créés par l’app. Plus précisément, contrôlez si des fichiers sont définis comme lisibles ou modifiables par tous. Cela peut représenter un risque majeur de sécurité, car toute application installée sur le device, quelle que soit son origine ou son intention, pourrait lire ou modifier ces fichiers.

External Storage

Lorsqu’on traite des fichiers sur le stockage externe, comme les SD Cards, certaines précautions doivent être prises :

  1. Accessibilité :
  • Les fichiers sur le stockage externe sont globalement lisibles et modifiables. Cela signifie que n’importe quelle application ou utilisateur peut y accéder.
  1. Problèmes de sécurité :
  • Étant donné la facilité d’accès, il est conseillé de ne pas stocker d’informations sensibles sur le stockage externe.
  • Le stockage externe peut être retiré ou accédé par n’importe quelle application, ce qui le rend moins sûr.
  1. Traitement des données provenant du stockage externe :
  • Effectuez toujours une validation des entrées sur les données récupérées depuis le stockage externe. C’est crucial car ces données proviennent d’une source non fiable.
  • Stocker des exécutables ou des fichiers class sur le stockage externe pour un chargement dynamique est fortement déconseillé.
  • Si votre application doit récupérer des fichiers exécutables depuis le stockage externe, assurez-vous que ces fichiers sont signés et vérifiés cryptographiquement avant d’être chargés dynamiquement. Cette étape est vitale pour maintenir l’intégrité de sécurité de votre application.

Le stockage externe peut être accédé dans /storage/emulated/0 , /sdcard , /mnt/sdcard

Tip

À partir d’Android 4.4 (API 17), la carte SD a une structure de répertoires qui limite l’accès d’une app au répertoire qui lui est spécifiquement dédié. Cela empêche une application malveillante d’obtenir un accès en lecture ou écriture aux fichiers d’une autre app.

Sensitive data stored in clear-text

  • Shared preferences : Android permet à chaque application de sauvegarder facilement des fichiers xml dans le chemin /data/data/<packagename>/shared_prefs/ et il est parfois possible de trouver des informations sensibles en clair dans ce dossier.
  • Databases : Android permet à chaque application de sauvegarder facilement des bases sqlite dans le chemin /data/data/<packagename>/databases/ et il est parfois possible de trouver des informations sensibles en clair dans ce dossier.

Broken TLS

Accept All Certificates

Pour une raison ou une autre, parfois des développeurs acceptent tous les certificats même si, par exemple, le hostname ne correspond pas, avec des lignes de code comme la suivante :

SSLSocketFactory sf = new cc(trustStore);
sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);

Une bonne façon de tester cela est d’essayer de capturer le trafic en utilisant un proxy comme Burp sans autoriser Burp CA à l’intérieur de l’appareil. Vous pouvez aussi générer avec Burp un certificat pour un hostname différent et l’utiliser.

Cryptographie défaillante

Mauvais processus de gestion des clés

Certains développeurs enregistrent des données sensibles dans le stockage local et les chiffrent avec une clé codée en dur/prévisible dans le code. Cela ne devrait pas être fait car un reversing pourrait permettre à des attaquants d’extraire les informations confidentielles.

Utilisation d’algorithmes non sécurisés et/ou obsolètes

Les développeurs ne devraient pas utiliser des deprecated algorithms pour effectuer des authorisation checks, stocker ou envoyer des données. Certains de ces algorithmes sont : RC4, MD4, MD5, SHA1… Si des hashes sont utilisés pour stocker des mots de passe par exemple, des hashes résistants au brute-force devraient être utilisés avec du salt.

Autres vérifications

  • Il est recommandé d’obfusquer l’APK pour rendre le travail du reverse engineer plus difficile pour les attaquants.
  • Si l’application est sensible (comme les applications bancaires), elle devrait effectuer ses propres vérifications pour savoir si le mobile est rooted et agir en conséquence.
  • Si l’application est sensible (comme les applications bancaires), elle devrait vérifier si un emulator est utilisé.
  • Si l’application est sensible (comme les applications bancaires), elle devrait vérifier sa propre intégrité avant de s’exécuter pour vérifier si elle a été modifiée.
  • Utilisez APKiD pour vérifier quel compiler/packer/obfuscator a été utilisé pour construire l’APK

Application React Native

Lisez la page suivante pour apprendre comment accéder facilement au code javascript des applications React :

React Native Application

Applications Xamarin

Lisez la page suivante pour apprendre comment accéder facilement au code C# d’une application xamarin :

Xamarin Apps

Superpacked Applications

According to this blog post superpacked is a Meta algorithm that compress the content of an application into a single file. The blog talks about the possibility of creating an app that decompress these kind of apps… and a faster way which involves to execute the application and gather the decompressed files from the filesystem.

Automated Static Code Analysis

L’outil mariana-trench est capable de trouver vulnerabilities en scanning le code de l’application. Cet outil contient une série de known sources (qui indique à l’outil les places où l’input est contrôlé par l’utilisateur), sinks (qui indique à l’outil dangerous places où une entrée malveillante pourrait causer des dommages) et des rules. Ces rules indiquent la combinaison de sources-sinks qui indique une vulnérabilité.

Avec ces connaissances, mariana-trench examinera le code et trouvera d’éventuelles vulnerabilities.

Secrets leaked

Une application peut contenir des secrets (API keys, passwords, hidden urls, subdomains…) en son sein que vous pourriez découvrir. Vous pouvez utiliser un outil tel que https://github.com/dwisiswant0/apkleaks

Bypass Biometric Authentication

Bypass Biometric Authentication (Android)

Autres fonctions intéressantes

  • Exécution de code: Runtime.exec(), ProcessBuilder(), native code:system()
  • Envoi de SMS: sendTextMessage, sendMultipartTestMessage
  • Fonctions natives déclarées comme native: public native, System.loadLibrary, System.load
  • Read this to learn how to reverse native functions
  • Exécution de code natif en mémoire via JNI (downloaded shellcode → mmap/mprotect → call):

In Memory Jni Shellcode Execution

Autres astuces

content:// protocol

Analyse dynamique

Tout d’abord, vous avez besoin d’un environnement où vous pouvez installer l’application et tout l’environnement (Burp CA cert, Drozer et Frida principalement). Par conséquent, un appareil rooté (émulé ou non) est fortement recommandé.

Analyse dynamique en ligne

Vous pouvez créer un compte gratuit sur : https://appetize.io/. Cette plateforme vous permet d’uploader et d’exécuter des APKs, donc elle est utile pour voir comment un apk se comporte.

Vous pouvez même voir les logs de votre application sur le web et vous connecter via adb.

Grâce à la connexion ADB vous pouvez utiliser Drozer et Frida dans les émulateurs.

Analyse dynamique locale

Utilisation d’un emulator

  • Android Studio (Vous pouvez créer des devices x86 et arm, et selon this latest x86 versions support ARM libraries sans avoir besoin d’un émulateur arm lent).
  • Apprenez à le configurer sur cette page :

AVD - Android Virtual Device

  • Genymotion (Version gratuite : Personal Edition, vous devez créer un compte. Il est recommandé de télécharger la version AVEC VirtualBox pour éviter des erreurs potentielles.)
  • Nox (Gratuit, mais il ne supporte pas Frida ou Drozer).

Tip

Lors de la création d’un nouvel emulator sur n’importe quelle plate-forme, souvenez-vous que plus l’écran est grand, plus l’emulator sera lent. Sélectionnez donc des écrans petits si possible.

Pour installer google services (comme AppStore) dans Genymotion vous devez cliquer sur le bouton marqué en rouge de l’image suivante :

Notez également que dans la configuration de la Android VM dans Genymotion vous pouvez sélectionner Bridge Network mode (ceci sera utile si vous vous connectez à la Android VM depuis une autre VM avec les outils).

Utiliser un appareil physique

Vous devez activer les options de debugging et ce serait bien si vous pouvez le rooter :

  1. Settings.
  2. (FromAndroid 8.0) Select System.
  3. Select About phone.
  4. Press Build number 7 times.
  5. Go back and you will find the Developer options.

Une fois l’application installée, la première chose à faire est de l’essayer et d’étudier ce qu’elle fait, comment elle fonctionne et de vous familiariser avec elle.
Je suggère de réaliser cette analyse dynamique initiale en utilisant MobSF dynamic analysis + pidcat, ainsi nous pourrons apprendre comment l’application fonctionne pendant que MobSF capture beaucoup de données intéressantes que vous pourrez revoir plus tard.

Magisk/Zygisk quick notes (recommended on Pixel devices)

  • Patch boot.img with the Magisk app and flash via fastboot to get systemless root
  • Enable Zygisk + DenyList for root hiding; consider LSPosed/Shamiko when stronger hiding is required
  • Keep original boot.img to recover from OTA updates; re-patch after each OTA
  • For screen mirroring, use scrcpy on the host

Unintended Data Leakage

Logging

Les développeurs doivent être prudents à exposer des debugging information publiquement, car cela peut conduire à des sensitive data leaks. Les outils pidcat et adb logcat sont recommandés pour surveiller les logs de l’application afin d’identifier et protéger les informations sensibles. Pidcat est préféré pour sa facilité d’utilisation et sa lisibilité.

Warning

Note that from later newer than Android 4.0, applications are only able to access their own logs. So applications cannot access other apps logs.
Anyway, it’s still recommended to not log sensitive information.

Copy/Paste Buffer Caching

Le framework clipboard-based d’Android permet la fonctionnalité de copier-coller dans les apps, mais présente un risque puisque d’autres applications peuvent accéder au clipboard, exposant potentiellement des données sensibles. Il est crucial de désactiver les fonctions copy/paste pour les sections sensibles d’une application, comme les informations de carte de crédit, afin d’éviter des leaks.

Crash Logs

Si une application crashe et sauvegarde des logs, ces logs peuvent aider des attaquants, particulièrement lorsque l’application ne peut pas être reverse-engineered. Pour atténuer ce risque, évitez de logger lors des crashs, et si des logs doivent être transmis sur le réseau, assurez-vous qu’ils sont envoyés via un canal SSL pour la sécurité.

En tant que pentester, essayez de consulter ces logs.

Analytics Data Sent To 3rd Parties

Les applications intègrent souvent des services comme Google Adsense, qui peuvent involontairement leak des données sensibles à cause d’une mauvaise implémentation par les développeurs. Pour identifier des leaks potentiels, il est conseillé d’intercepter le trafic de l’application et de vérifier si des informations sensibles sont envoyées à des services tiers.

SQLite DBs

La plupart des applications utiliseront des bases de données SQLite internes pour sauvegarder des informations. Pendant le pentest, jetez un œil aux bases de données créées, aux noms des tables et des colonnes et à toutes les données enregistrées car vous pourriez trouver des informations sensibles (ce qui constituerait une vulnérabilité).
Les bases de données devraient être situées dans /data/data/the.package.name/databases comme /data/data/com.mwr.example.sieve/databases

Si la base de données enregistre des informations confidentielles et est cryptée, mais que vous pouvez trouver le mot de passe à l’intérieur de l’application, c’est toujours une vulnérabilité.

Enumérez les tables en utilisant .tables et énumérez les colonnes des tables avec .schema <table_name>

Drozer (Exploit Activities, Content Providers and Services)

From Drozer Docs: Drozer allows you to assume the role of an Android app and interact with other apps. It can do anything that an installed application can do, such as make use of Android’s Inter-Process Communication (IPC) mechanism and interact with the underlying operating system. .
Drozer est un outil utile pour exploiter les exported activities, exported services and Content Providers comme vous l’apprendrez dans les sections suivantes.

Exploiting exported Activities

Read this if you want to refresh what is an Android Activity.
Souvenez-vous aussi que le code d’une activity commence dans la méthode onCreate.

Authorisation bypass

Lorsqu’une Activity est exportée, vous pouvez invoquer son écran depuis une application externe. Ainsi, si une activity contenant des informations sensibles est exportée, vous pourriez bypasser les mécanismes d’authentication pour y accéder.

Learn how to exploit exported activities with Drozer.

Vous pouvez aussi démarrer une activity exportée depuis adb :

  • PackageName is com.example.demo
  • Exported ActivityName is com.example.test.MainActivity
adb shell am start -n com.example.demo/com.example.test.MainActivity

NOTE: MobSF détectera comme malveillant l’utilisation de singleTask/singleInstance comme android:launchMode dans une activity, mais d’après this, apparemment cela n’est dangereux que sur les anciennes versions (API versions < 21).

Tip

Notez qu’un contournement d’autorisation (authorisation bypass) n’est pas toujours une vulnérabilité ; cela dépend du fonctionnement du bypass et des informations exposées.

Fuite d’informations sensibles

Activities can also return results. Si vous parvenez à trouver une activity exportée et non protégée appelant la méthode setResult et retournant des informations sensibles, il y a une fuite d’informations sensibles.

Tapjacking

Si le Tapjacking n’est pas empêché, vous pourriez abuser de l’activity exportée pour amener l’utilisateur à effectuer des actions inattendues. Pour plus d’infos sur ce qu’est Tapjacking — suivez le lien.

Exploiting Content Providers - Accessing and manipulating sensitive information

Lisez ceci si vous voulez vous rafraîchir sur ce qu’est un Content Provider.
Les Content Providers servent essentiellement à partager des données. Si une app expose des content providers, vous pourriez être en mesure d’extraire des données sensibles depuis ceux-ci. Il est aussi intéressant de tester d’éventuelles SQL injections et Path Traversals, car elles pourraient être vulnérables.

Apprenez à exploiter les Content Providers avec Drozer.

Exploiting Services

Lisez ceci si vous voulez vous rafraîchir sur ce qu’est un Service.
Rappelez-vous que les actions d’un Service commencent dans la méthode onStartCommand.

Un Service est essentiellement quelque chose qui peut recevoir des données, les traiter et retourner (ou non) une réponse. Donc, si une application exporte des services, vous devriez vérifier le code pour comprendre ce qu’il fait et le tester dynamiquement afin d’extraire des informations confidentielles, contourner des mesures d’authentification…
Apprenez à exploiter les Services avec Drozer.

Exploiting Broadcast Receivers

Lisez ceci si vous voulez vous rafraîchir sur ce qu’est un Broadcast Receiver.
Rappelez-vous que les actions d’un Broadcast Receiver démarrent dans la méthode onReceive.

Un Broadcast Receiver attendra un type de message. Selon la manière dont le receiver traite le message, il pourrait être vulnérable.
Apprenez à exploiter les Broadcast Receivers avec Drozer.

Exploiting Schemes / Deep links

Vous pouvez rechercher des deep links manuellement, en utilisant des outils comme MobSF ou des scripts comme celui-ci.
Vous pouvez ouvrir un scheme déclaré en utilisant adb ou un navigateur :

adb shell am start -a android.intent.action.VIEW -d "scheme://hostname/path?param=value" [your.package.name]

Notez que vous pouvez omettre le nom du package et le mobile appellera automatiquement l’application qui doit ouvrir ce lien.

<!-- Browser regular link -->
<a href="scheme://hostname/path?param=value">Click me</a>
<!-- fallback in your url you could try the intent url -->
<a href="intent://hostname#Intent;scheme=scheme;package=your.package.name;S.browser_fallback_url=http%3A%2F%2Fwww.example.com;end">with alternative</a>

Code exécuté

Pour trouver le code qui sera exécuté dans l’App, allez à l’activité appelée par le deeplink et recherchez la fonction onNewIntent.

Informations sensibles

Chaque fois que vous trouvez un deep link, vérifiez qu’il ne reçoit pas de données sensibles (comme passwords) via des URL parameters, car toute autre application pourrait se faire passer pour le deep link et dérober ces données !

Parameters in path

Vous devez également vérifier si un deep link utilise un paramètre à l’intérieur du path de l’URL comme : https://api.example.com/v1/users/{username} , dans ce cas vous pouvez forcer un path traversal en accédant à quelque chose comme : example://app/users?username=../../unwanted-endpoint%3fparam=value .
Notez que si vous trouvez les endpoints corrects dans l’application vous pouvez être capable de provoquer un Open Redirect (si une partie du path est utilisée comme nom de domaine), un account takeover (si vous pouvez modifier les détails des utilisateurs sans token CSRF et que le vuln endpoint utilise la méthode correcte) et toute autre vuln. More info about this here.

More examples

Un interesting bug bounty report about links (/.well-known/assetlinks.json).

Inspection de la couche transport et échecs de vérification

  • Les certificats ne sont pas toujours correctement inspectés par les applications Android. Il est courant que ces applications ignorent les avertissements et acceptent des self-signed certificates ou, dans certains cas, reviennent à des connexions HTTP.
  • Les négociations pendant le handshake SSL/TLS sont parfois faibles, employant des suites de chiffrement insecure. Cette vulnérabilité rend la connexion susceptible aux attaques man-in-the-middle (MITM), permettant aux attaquants de déchiffrer les données.
  • Leakage of private information est un risque lorsque les applications s’authentifient via des canaux sécurisés puis communiquent sur des canaux non sécurisés pour d’autres transactions. Cette approche ne protège pas les données sensibles, telles que les session cookies ou les détails des utilisateurs, contre l’interception par des entités malveillantes.

Vérification des certificats

Nous allons nous concentrer sur la vérification des certificats. L’intégrité du certificat du serveur doit être vérifiée pour renforcer la sécurité. C’est crucial car des configurations TLS non sécurisées et la transmission de données sensibles sur des canaux non chiffrés peuvent poser des risques importants. Pour des étapes détaillées sur la vérification des certificats serveur et la correction des vulnérabilités, this resource fournit des conseils complets.

SSL Pinning

SSL Pinning est une mesure de sécurité où l’application vérifie le certificat du serveur par rapport à une copie connue stockée dans l’application elle-même. Cette méthode est essentielle pour prévenir les attaques MITM. La mise en place de SSL Pinning est fortement recommandée pour les applications traitant des informations sensibles.

Inspection du trafic

Pour inspecter le trafic HTTP, il est nécessaire d’installer le certificat de l’outil proxy (par ex., Burp). Sans l’installation de ce certificat, le trafic chiffré peut ne pas être visible via le proxy. Pour un guide sur l’installation d’un certificat CA personnalisé, click here.

Les applications ciblant API Level 24 and above nécessitent des modifications du Network Security Config pour accepter le proxy’s CA certificate. Cette étape est critique pour inspecter le trafic chiffré. Pour des instructions sur la modification du Network Security Config, refer to this tutorial.

Si Flutter est utilisé, vous devez suivre les instructions dans this page. Cela s’explique par le fait que, simplement ajouter le certificat dans le store ne fonctionnera pas car Flutter possède sa propre liste de CAs valides.

Détection statique du SSL/TLS pinning

Avant de tenter des runtime bypasses, cartographiez rapidement où le pinning est appliqué dans l’APK. La découverte statique vous aide à planifier les hooks/patches et à vous concentrer sur les bons chemins de code.

Tool: SSLPinDetect

  • Utilitaire open-source d’analyse statique qui décompile l’APK en Smali (via apktool) et scanne des motifs regex sélectionnés d’implémentations de SSL/TLS pinning.
  • Rapporte le chemin de fichier exact, le numéro de ligne et un extrait de code pour chaque correspondance.
  • Couvre les frameworks courants et les chemins de code personnalisés : OkHttp CertificatePinner, custom javax.net.ssl.X509TrustManager.checkServerTrusted, SSLContext.init with custom TrustManagers/KeyManagers, et Network Security Config XML pins.

Install

  • Prérequis : Python >= 3.8, Java on PATH, apktool
git clone https://github.com/aancw/SSLPinDetect
cd SSLPinDetect
pip install -r requirements.txt

Utilisation

# Basic
python sslpindetect.py -f app.apk -a apktool.jar

# Verbose (timings + per-match path:line + snippet)
python sslpindetect.py -a apktool_2.11.0.jar -f sample/app-release.apk -v

Exemples de règles de pattern (JSON) Utilisez ou étendez les signatures pour détecter des styles de pinning propriétaires/personnalisés. Vous pouvez charger votre propre JSON et scanner à grande échelle.

{
"OkHttp Certificate Pinning": [
"Lcom/squareup/okhttp/CertificatePinner;",
"Lokhttp3/CertificatePinner;",
"setCertificatePinner"
],
"TrustManager Override": [
"Ljavax/net/ssl/X509TrustManager;",
"checkServerTrusted"
]
}

Notes et conseils

  • Analyse rapide des grandes apps via multi-threading et memory-mapped I/O ; les regex pré-compilées réduisent la surcharge / les faux positifs.
  • Pattern collection: https://github.com/aancw/smali-sslpin-patterns
  • Cibles de détection typiques à prioriser :
  • OkHttp: CertificatePinner usage, setCertificatePinner, okhttp3/okhttp package references
  • Custom TrustManagers: javax.net.ssl.X509TrustManager, checkServerTrusted overrides
  • Custom SSL contexts: SSLContext.getInstance + SSLContext.init with custom managers
  • Declarative pins in res/xml network security config and manifest references
  • Utilisez les emplacements trouvés pour planifier des Frida hooks, des patchs statiques ou des revues de config avant les tests dynamiques.

Bypassing SSL Pinning

Lorsque SSL Pinning est implémenté, il devient nécessaire de le bypasser pour inspecter le trafic HTTPS. Plusieurs méthodes sont disponibles pour cela :

  • Automatically modify the apk to bypass SSLPinning with apk-mitm. L’avantage principal de cette option est que vous n’aurez pas besoin de root pour bypasser le SSL Pinning, mais vous devrez supprimer l’application et réinstaller la nouvelle, et cela ne fonctionnera pas toujours.
  • You could use Frida (discussed below) to bypass this protection. Voici un guide pour utiliser Burp+Frida+Genymotion : https://spenkk.github.io/bugbounty/Configuring-Frida-with-Burp-and-GenyMotion-to-bypass-SSL-Pinning/
  • Vous pouvez aussi essayer de bypasser automatiquement SSL Pinning en utilisant objection: objection --gadget com.package.app explore --startup-command "android sslpinning disable"
  • Vous pouvez aussi essayer de bypasser automatiquement SSL Pinning en utilisant MobSF dynamic analysis (expliqué ci-dessous)
  • Si vous pensez toujours qu’il y a du trafic que vous ne capturez pas, vous pouvez essayer de forwarder le trafic vers Burp en utilisant iptables. Lire ce blog : https://infosecwriteups.com/bypass-ssl-pinning-with-ip-forwarding-iptables-568171b52b62

Recherche de vulnérabilités web courantes

Il est important de rechercher également les vulnérabilités web courantes au sein de l’application. Les informations détaillées sur l’identification et l’atténuation de ces vulnérabilités dépassent le cadre de ce résumé mais sont largement couvertes ailleurs.

Frida

Frida est un toolkit d’instrumentation dynamique pour développeurs, reverse engineers et chercheurs en sécurité.
Vous pouvez accéder à l’application en cours d’exécution et hooker des méthodes à l’exécution pour modifier le comportement, changer des valeurs, extraire des valeurs, exécuter du code différent…
If you want to pentest Android applications you need to know how to use Frida.

Anti-instrumentation & SSL pinning bypass workflow

Android Anti Instrumentation And Ssl Pinning Bypass

Dump Memory - Fridump

Vérifiez si l’application stocke des informations sensibles en mémoire qu’elle ne devrait pas stocker, comme des mots de passe ou des mnémotechniques.

Using Fridump3 you can dump the memory of the app with:

# With PID
python3 fridump3.py -u <PID>

# With name
frida-ps -Uai
python3 fridump3.py -u "<Name>"

Cela va dump la mémoire dans le dossier ./dump, et vous pouvez y grep avec quelque chose comme :

strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+$"

Données sensibles dans Keystore

Sur Android, le Keystore est l’endroit idéal pour stocker des données sensibles, cependant, avec des privilèges suffisants il est toujours possible d’y accéder. Comme les applications ont tendance à stocker ici des données sensibles en clair, les pentests doivent le vérifier en tant qu’utilisateur root ou une personne ayant un accès physique à l’appareil pourrait être en mesure de voler ces données.

Même si une app stocke des données dans le keystore, les données doivent être chiffrées.

Pour accéder aux données à l’intérieur du keystore vous pouvez utiliser ce script Frida: https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/tracer-cipher.js

frida -U -f com.example.app -l frida-scripts/tracer-cipher.js

Fingerprint/Biometrics Bypass

En utilisant le script Frida suivant, il pourrait être possible de bypass fingerprint authentication que les applications Android mettent en place pour protéger certaines zones sensibles :

frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app.package>

Images en arrière-plan

Lorsque vous mettez une application en arrière-plan, Android stocke un snapshot de l’application afin que, lorsqu’elle est ramenée au premier plan, il commence à charger l’image avant l’application pour donner l’impression que l’application s’est chargée plus rapidement.

Cependant, si ce snapshot contient des informations sensibles, une personne ayant accès au snapshot pourrait voler ces informations (notez que vous avez besoin de root pour y accéder).

Les snapshots sont généralement stockés à : /data/system_ce/0/snapshots

Android fournit un moyen d’empêcher la capture de screenshot en définissant le paramètre de layout FLAG_SECURE. En utilisant ce flag, le contenu de la fenêtre est considéré comme sécurisé, l’empêchant d’apparaître dans les screenshots ou d’être affiché sur des écrans non sécurisés.

getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);

Android Application Analyzer

Cet outil peut vous aider à gérer différents outils pendant l’analyse dynamique : https://github.com/NotSoSecure/android_application_analyzer

Intent Injection

Les développeurs créent souvent des composants proxy comme activities, services, et broadcast receivers qui traitent ces Intents et les transmettent à des méthodes telles que startActivity(...) ou sendBroadcast(...), ce qui peut être risqué.

Le danger vient du fait de permettre à des attaquants de déclencher des composants d’application non-exportés ou d’accéder à des content providers sensibles en détournant ces Intents. Un exemple notable est le composant WebView convertissant des URLs en objets Intent via Intent.parseUri(...) puis les exécutant, ce qui peut conduire à des injections d’Intent malveillants.

Points essentiels

  • Intent Injection est similaire au problème Open Redirect du web.
  • Les exploitations consistent à passer des objets Intent en tant qu’extras, qui peuvent être redirigés pour exécuter des opérations non sécurisées.
  • Cela peut exposer des composants non-exportés et des content providers aux attaquants.
  • La conversion d’URL en Intent par WebView peut faciliter des actions non désirées.

Android Client Side Injections and others

Vous connaissez probablement ce type de vulnérabilités depuis le Web. Il faut être particulièrement vigilant avec ces vulnérabilités dans une application Android :

  • SQL Injection: Lors de la gestion de requêtes dynamiques ou de Content-Providers, assurez-vous d’utiliser des requêtes paramétrées.
  • JavaScript Injection (XSS): Vérifiez que le support JavaScript et Plugin est désactivé pour tout WebViews (désactivé par défaut). More info here.
  • Local File Inclusion: Les WebViews devraient avoir l’accès au système de fichiers désactivé (activé par défaut) - (webview.getSettings().setAllowFileAccess(false);). More info here.
  • Eternal cookies: Dans plusieurs cas, lorsque l’application android termine la session, le cookie n’est pas révoqué ou peut même être sauvegardé sur le disque
  • Secure Flag in cookies

Analyse automatique

MobSF

Analyse statique

Évaluation des vulnérabilités de l’application en utilisant une interface web agréable. Vous pouvez aussi effectuer une analyse dynamique (mais vous devez préparer l’environnement).

docker pull opensecurity/mobile-security-framework-mobsf
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

Remarquez que MobSF peut analyser les applications Android(apk), IOS(ipa) and Windows(apx) (les applications Windows doivent être analysées depuis un MobSF installé sur un hôte Windows).
De plus, si vous créez un fichier ZIP contenant le code source d’une application Android ou IOS (allez au dossier racine de l’application, sélectionnez tout et créez un ZIPfile), il pourra l’analyser également.

MobSF permet aussi de diff/Compare des analyses et de s’intégrer à VirusTotal (vous devrez définir votre clé API dans MobSF/settings.py et l’activer : VT_ENABLED = TRUE VT_API_KEY = <Your API key> VT_UPLOAD = TRUE). Vous pouvez aussi définir VT_UPLOAD à False, auquel cas le hash sera upload au lieu du fichier.

Analyse dynamique assistée avec MobSF

MobSF peut aussi être très utile pour l’analyse dynamique sur Android, mais dans ce cas vous devrez installer MobSF et genymotion sur votre hôte (une VM ou Docker ne fonctionneront pas). Note : Vous devez démarrer d’abord une VM dans genymotion et puis MobSF.
L’analyseur dynamique de MobSF peut :

  • Extraire les données de l’application (URLs, logs, presse-papiers, captures d’écran faites par vous, captures d’écran faites par “Exported Activity Tester”, emails, bases de données SQLite, fichiers XML, et autres fichiers créés). Tout cela est fait automatiquement sauf pour les captures d’écran : vous devez appuyer quand vous voulez une capture d’écran ou appuyer sur “Exported Activity Tester” pour obtenir les captures d’écran de toutes les activités exportées.
  • Capturer le trafic HTTPS
  • Utiliser Frida pour obtenir des informations runtime

À partir des versions Android > 5, il va démarrer automatiquement Frida et définira les paramètres de proxy globaux pour capturer le trafic. Il ne capturera que le trafic de l’application testée.

Frida

Par défaut, il utilisera aussi certains Frida scripts pour bypass SSL pinning, root detection et debugger detection et pour monitor interesting APIs.
MobSF peut aussi invoke exported activities, capturer des screenshots de celles-ci et les save pour le rapport.

Pour démarrer le test dynamique, appuyez sur le bouton vert : “Start Instrumentation”. Appuyez sur “Frida Live Logs” pour voir les logs générés par les Frida scripts et sur “Live API Monitor” pour voir toutes les invocations aux méthodes hookées, les arguments passés et les valeurs retournées (cela apparaîtra après avoir appuyé sur “Start Instrumentation”).
MobSF permet aussi de charger vos propres Frida scripts (pour envoyer les résultats de vos Frida scripts à MobSF utilisez la fonction send()). Il propose également plusieurs scripts pré-écrits que vous pouvez charger (vous pouvez en ajouter d’autres dans MobSF/DynamicAnalyzer/tools/frida_scripts/others/), il suffit de les sélectionner, appuyer sur “Load” et appuyer sur “Start Instrumentation” (vous pourrez voir les logs de ces scripts dans “Frida Live Logs”).

De plus, vous avez quelques fonctionnalités auxiliaires Frida :

  • Enumerate Loaded Classes: Il affichera toutes les classes chargées
  • Capture Strings: Il affichera toutes les chaînes capturées pendant l’utilisation de l’application (très bruyant)
  • Capture String Comparisons: Peut être très utile. Il montrera les 2 chaînes comparées et si le résultat était True ou False.
  • Enumerate Class Methods: Entrez le nom de la classe (comme “java.io.File”) et il affichera toutes les méthodes de la classe.
  • Search Class Pattern: Recherche les classes par motif
  • Trace Class Methods: Trace une classe entière (voir les entrées et sorties de toutes les méthodes de la classe). Rappelez-vous qu’en standard MobSF trace plusieurs méthodes intéressantes de l’API Android.

Une fois que vous avez sélectionné le module auxiliaire que vous souhaitez utiliser, vous devez appuyer sur “Start Instrumentation” et vous verrez toutes les sorties dans “Frida Live Logs”.

Shell

MobSF propose aussi un shell avec quelques commandes adb, des MobSF commands, et des commandes shell courantes en bas de la page d’analyse dynamique. Quelques commandes intéressantes :

help
shell ls
activities
exported_activities
services
receivers

HTTP tools

Lorsque le trafic HTTP est capturé, vous pouvez voir une vue brute du trafic capturé dans le bouton “HTTP(S) Traffic” en bas ou une vue plus agréable dans le bouton vert “Start HTTPTools”. Depuis la deuxième option, vous pouvez send les captured requests vers des proxies comme Burp ou Owasp ZAP.
Pour ce faire, power on Burp –> turn off Intercept –> in MobSB HTTPTools select the request –> appuyez sur “Send to Fuzzer” –> select the proxy address (http://127.0.0.1:8080\).

Une fois que vous avez terminé le dynamic analysis avec MobSF, vous pouvez cliquer sur “Start Web API Fuzzer” pour fuzz http requests et look for vulnerabilities.

Tip

Après avoir effectué un dynamic analysis avec MobSF, les proxy settings peuvent être mal configurés et vous ne pourrez pas les corriger depuis le GUI. Vous pouvez corriger les proxy settings en exécutant :

adb shell settings put global http_proxy :0

Assisted Dynamic Analysis with Inspeckage

Vous pouvez obtenir l’outil depuis Inspeckage.
Cet outil utilisera des Hooks pour vous indiquer ce qui se passe dans l’application pendant que vous effectuez une dynamic analysis.

Yaazhini

C’est un excellent outil pour effectuer une static analysis avec une GUI

Qark

Cet outil est conçu pour rechercher plusieurs security related Android application vulnerabilities, soit dans le source code, soit dans des packaged APKs. L’outil est aussi capable of creating a “Proof-of-Concept” deployable APK et des ADB commands, pour exploiter certaines des vulnerabilities trouvées (Exposed activities, intents, tapjacking…). Comme avec Drozer, il n’est pas nécessaire de rooter l’appareil de test.

pip3 install --user qark  # --user is only needed if not using a virtualenv
qark --apk path/to/my.apk
qark --java path/to/parent/java/folder
qark --java path/to/specific/java/file.java

ReverseAPK

  • Affiche tous les fichiers extraits pour une consultation facile
  • Décompile automatiquement les fichiers APK au format Java et Smali
  • Analyse AndroidManifest.xml pour détecter les vulnérabilités et comportements courants
  • Analyse statique du code source pour détecter les vulnérabilités et comportements courants
  • Informations sur l’appareil
  • et plus encore
reverse-apk relative/path/to/APP.apk

SUPER Android Analyzer

SUPER est une application en ligne de commande utilisable sous Windows, MacOS X et Linux, qui analyse des fichiers .apk à la recherche de vulnérabilités. Elle procède en décompressant les APK et en appliquant une série de règles pour détecter ces vulnérabilités.

Toutes les règles sont centralisées dans un fichier rules.json, et chaque entreprise ou testeur peut créer ses propres règles pour analyser ce dont il a besoin.

Téléchargez les derniers binaires depuis la download page

super-analyzer {apk_file}

StaCoAn

StaCoAn est un outil multi-plateforme qui aide les développeurs, bugbounty hunters et ethical hackers à effectuer une analyse statique de code sur des applications mobiles.

Le principe consiste à glisser-déposer le fichier de votre application mobile (un fichier .apk ou .ipa) dans l’application StaCoAn : elle générera un rapport visuel et portable pour vous. Vous pouvez ajuster les paramètres et les wordlists pour obtenir une expérience personnalisée.

Télécharger la dernière release:

./stacoan

AndroBugs

AndroBugs Framework est un système d’analyse de vulnérabilités Android qui aide les développeurs ou hackers à trouver d’éventuelles vulnérabilités de sécurité dans les applications Android.
Windows releases

python androbugs.py -f [APK file]
androbugs.exe -f [APK file]

Androwarn

Androwarn est un outil dont le principal objectif est de détecter et d’avertir l’utilisateur des comportements potentiellement malveillants développés par une application Android.

La détection est effectuée via l’analyse statique du Dalvik bytecode de l’application, représenté en Smali, à l’aide de la bibliothèque androguard.

Cet outil recherche les comportements courants des applications “malveillantes” tels que : Telephony identifiers exfiltration, Audio/video flow interception, PIM data modification, Arbitrary code execution…

python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3

MARA Framework

MARA est un framework d’ingénierie inverse et d’analyse d’applications mobiles. C’est un outil qui rassemble des outils couramment utilisés d’ingénierie inverse et d’analyse d’applications mobiles, afin d’aider à tester les applications mobiles contre les menaces de sécurité mobile OWASP. Son objectif est de rendre cette tâche plus simple et plus conviviale pour les développeurs d’applications mobiles et les professionnels de la sécurité.

Il peut :

Koodous

Utile pour détecter du malware : https://koodous.com/

Obfuscating/Deobfuscating code

Notez que selon le service et la configuration que vous utilisez pour obfusquer le code, les secrets peuvent ou non être obfusqués.

ProGuard

D’après Wikipedia: ProGuard est un outil open source en ligne de commande qui réduit, optimise et obfusque le code Java. Il est capable d’optimiser le bytecode ainsi que de détecter et supprimer les instructions inutilisées. ProGuard est un logiciel libre et est distribué sous la GNU General Public License, version 2.

ProGuard est distribué dans l’Android SDK et s’exécute lors de la compilation de l’application en mode release.

DexGuard

Trouvez un guide pas à pas pour déobfusquer l’apk sur https://blog.lexfo.fr/dexguard.html

(D’après ce guide) La dernière fois que nous avons vérifié, le mode d’opération de Dexguard était :

  • charger une ressource en tant qu’InputStream;
  • alimenter le résultat vers une classe héritant de FilterInputStream pour la déchiffrer;
  • faire une obfuscation inutile pour faire perdre quelques minutes à une personne effectuant du reverse engineering;
  • passer le résultat déchiffré à un ZipInputStream pour obtenir un fichier DEX;
  • finalement charger le DEX résultant comme Resource en utilisant la méthode loadDex.

DeGuard

DeGuard inverse le processus d’obfuscation effectué par les outils d’obfuscation Android. Cela permet de nombreuses analyses de sécurité, y compris l’inspection du code et l’identification des bibliothèques.

Vous pouvez téléverser un APK obfusqué sur leur plateforme.

[Deobfuscate android App]https://github.com/In3tinct/deobfuscate-android-app

C’est un outil LLM pour trouver d’éventuelles vulnérabilités de sécurité dans les apps Android et déobfusquer le code d’applications Android. Utilise l’API publique Gemini de Google.

Simplify

C’est un déobfuscateur Android générique. Simplify exécute virtuellement une app pour comprendre son comportement puis essaie d’optimiser le code afin qu’il se comporte de manière identique mais soit plus facile à comprendre pour un humain. Chaque type d’optimisation est simple et générique, donc peu importe le type spécifique d’obfuscation utilisé.

APKiD

APKiD vous donne des informations sur comment un APK a été créé. Il identifie de nombreux compilers, packers, obfuscators, et d’autres trucs bizarres. C’est PEiD pour Android.

Manual

Lisez ce tutoriel pour apprendre quelques astuces sur comment inverser une obfuscation personnalisée

Labs

Androl4b

AndroL4b est une machine virtuelle de sécurité Android basée sur ubuntu-mate qui inclut une collection des derniers frameworks, tutoriels et labs de différents passionnés et chercheurs en sécurité pour le reverse engineering et l’analyse de malware.

References

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks