Décrivez-moi le format de fichier PE de Windows et les parties que vous inspectez lors du triage d'un échantillon.
Réponse courte
Un fichier PE commence par l'en-tête DOS et son pointeur e_lfanew vers les en-têtes PE/NT, qui contiennent le File Header et l'Optional Header (point d'entrée, image base, sous-système). Il est divisé en sections — .text pour le code, .data, .rdata, .rsrc pour les ressources — chacune avec une adresse virtuelle et une taille brute. Lors du triage, on lit la table d'imports pour les API suspectes, la table des sections pour les noms étranges et l'entropie élevée qui suggèrent l'empaquetage, le timestamp et le rich header, les ressources embarquées et toute signature numérique. Les incohérences entre ces éléments en disent long avant même d'exécuter le fichier.
Le format Portable Executable (PE) est le conteneur que Windows utilise pour les fichiers .exe, .dll et .sys. Les recruteurs en parlent parce que la plupart des malwares Windows arrivent sous forme de PE, et qu'un analyste à l'aise peut lire l'intention d'un échantillon directement dans sa structure avant d'exécuter quoi que ce soit.
La structure
Tout PE s'ouvre sur l'en-tête DOS hérité (le magic MZ et le stub « This program cannot be run in DOS mode »). Son champ e_lfanew pointe vers les en-têtes PE/NT : le File Header (type de machine, nombre de sections, timestamp) et l'Optional Header (le point d'entrée, l'image base, le sous-système, et les répertoires de données qui localisent les tables d'imports et d'exports, les ressources et les relocations). Après les en-têtes vient la table des sections — typiquement .text (code), .data et .rdata (données et données en lecture seule), .rsrc (ressources comme les icônes et charges utiles embarquées) et .reloc.
Quoi inspecter et pourquoi
- Table d'imports. Les DLL et API auxquelles le binaire se lie sont l'indice de capacité le plus clair.
VirtualAlloc+WriteProcessMemory+CreateRemoteThreadhurle l'injection de processus ;InternetOpen/WinHttpConnectsignifie réseau ;CryptEncryptsuggère un ransomware. Une table d'imports presque vide avec seulementLoadLibrary/GetProcAddressimplique une résolution dynamique d'API pour masquer l'intention. - Sections. Des noms étranges (
.UPX0, chaînes aléatoires), une section à la fois inscriptible et exécutable, ou une taille brute nulle avec une grande taille virtuelle suggèrent tous un packer. Une entropie élevée (proche de 8,0) signale compression ou chiffrement — un fort indicateur d'empaquetage, bien que des ressources compressées légitimes affichent aussi un score élevé. - Ressources, timestamp, rich header, signature. Des exécutables embarqués dans
.rsrc, un timestamp falsifié ou mis à zéro, un rich header incohérent, ou une signature Authenticode manquante/invalide ajoutent chacun du poids.
Les meilleures réponses relient un champ à la conclusion qu'il soutient plutôt que de simplement énumérer des noms d'en-têtes.
Questions de suivi probables
- Que suggère une table d'imports dominée par GetProcAddress et LoadLibrary ?
- Pourquoi une entropie de section élevée est-elle un signal d'alerte, et quelle est sa limite en tant que signal ?
- Que peuvent vous apprendre le rich header ou le timestamp de compilation sur un échantillon ?