L'en-tête DEX : repérer un exécutable Dalvik déguisé en PNG
Le défi
Un échantillon de malware mobile était livré sous le nom icon.png dans les ressources d'une application, mais il ne s'affiche jamais comme une image. Ouvrez-le dans la visionneuse hexadécimale, comparez les premiers octets aux signatures de référence, et indiquez le vrai type de fichier.
Ce que tu vas apprendre
- Reconnaître les magic bytes DEX 64 65 78 0A ('dex\n') et le champ de version qui suit
- Lire les premiers octets en ASCII pour identifier un format grâce à sa signature imprimable
- Expliquer pourquoi Android charge le code selon son en-tête DEX, et non selon l'extension du fichier
- Distinguer DEX, PNG, ELF et ZIP grâce à leurs signatures distinctes
- Considérer les fichiers nommés comme des images dans les assets d'une application comme des cachettes potentielles de code
Compétences testées
Prérequis
- Connaissances de base sur les applications Android distribuées sous forme d'archives APK
- Aisance pour convertir des octets hexadécimaux en caractères ASCII
Comment ça marche
Les applications Android sont distribuées sous forme d'APK (qui sont eux-mêmes des archives ZIP), et le code compilé de l'application se trouve dans un fichier .dex - un exécutable Dalvik. Chaque DEX commence par un magic fixe : les octets 64 65 78 0A forment dex suivi d'un saut de ligne, et les quatre octets suivants (30 33 35 00 ici) constituent la chaîne de version 035 terminée par un octet nul. Cet en-tête de huit octets permet au runtime de reconnaître le bytecode qu'il peut charger.
Le fichier de ce challenge s'appelle icon.png, ce qui suggère une image, mais un vrai PNG commence par 89 50 4E 47. Les octets réels correspondent au magic DEX, donc le nom est un déguisement délibéré. Comme Android (et l'outillage de tout analyste) identifie le code exécutable par son en-tête plutôt que par son extension, glisser des octets DEX dans un icon.png cache la charge utile en pleine vue dans les assets d'une application, tout en restant chargeable.
La liste de référence inclut délibérément des formats binaires qui se ressemblent. 7F 45 4C 46 correspond à ELF (binaires Linux/natifs), 50 4B 03 04 au conteneur ZIP/APK, et 89 50 4E 47 au PNG qu'il prétend être. Seule la signature 64 65 78 0A correspond à un exécutable Dalvik.
Erreurs fréquentes
- Faire confiance à l'extension .png. Le nom promet une image, mais l'en-tête fait foi, et ce n'est pas un PNG.
- Confondre DEX et ELF. Les deux sont des formats exécutables, mais ELF commence par
7F 45 4C 46(« \x7fELF »), pas64 65 78 0A. - Lire uniquement l'hexadécimal en ignorant l'ASCII. La colonne ASCII épelle directement
dex, ce qui est l'indice le plus rapide. - Répondre « APK » ou « ZIP ». L'application qui contient le fichier peut être un APK/ZIP, mais l'en-tête de ce fichier précis est un DEX brut, pas un ZIP (
50 4B 03 04).
Comment s'en protéger
Les défenseurs mobiles doivent classer chaque ressource selon son contenu réel et considérer tout fichier ayant la forme d'un code dans un emplacement non prévu pour du code comme un signal d'alerte.
- Analyser le contenu de l'APK avec un détecteur de type basé sur le contenu, et signaler tout magic DEX trouvé en dehors des entrées
classes*.dexattendues. - Alerter sur les fichiers à extension image (
.png,.jpg) présents dansassets/oures/raw/dont les magic bytes correspondent à des formats exécutables. - Bloquer le chargement dynamique de code depuis les assets de l'application lorsque la plateforme le permet, et auditer toute utilisation de
DexClassLoader. - Maintenir une base de référence de signatures connues et valides afin que des charges utiles DEX renommées ou ajoutées ressortent lors de la revue.