PE-Bear : analyser un exécutable Windows (PE) rapidement

Introduction

PE-Bear est un outil de reverse engineering orienté « first view » : il vise à donner, très vite, une lecture claire d’un fichier PE (Portable Executable) — EXE, DLL, pilotes, etc. Son intérêt est particulièrement marqué en analyse de malwares, en triage d’incidents, et plus généralement dès qu’il faut comprendre « ce que contient » un binaire Windows sans lancer de gros frameworks.

Dans ce guide, on va couvrir l’application de bout en bout : ce qu’elle fait, comment l’installer proprement avec WinGet, comment la configurer et surtout comment l’utiliser de façon méthodique. L’objectif n’est pas seulement de cliquer dans l’interface, mais de comprendre quels signaux regarder, dans quel ordre, et ce que cela signifie.

Présentation générale : à quoi sert PE-Bear

PE-Bear en une phrase

PE-Bear est un outil graphique multiplateforme, Windows et Linux, d’analyse et d’édition légère de fichiers PE, pensé pour rester utilisable même face à des fichiers « atypiques » ou volontairement malformés. Son auteur (hasherezade) le positionne comme un outil de première analyse, rapide, flexible, et capable de gérer des cas limites.

Le projet open-source est hébergé sur GitHub: https://github.com/hasherezade/pe-bear

Ce qu’on appelle « PE » (Portable Executable)

Le format PE est le format standard des exécutables Windows. Schématiquement, un fichier PE contient :

• Un en-tête DOS et un stub (compatibilité historique).
• Une signature PE (PE\0\0), puis un en-tête COFF.
• Un « Optional Header » (qui est en réalité central pour les images exécutables).
• Une table de sections, puis les données brutes des sections.
• Des répertoires (Data Directories) qui pointent vers des structures clés : imports, exports, ressources, relocations, TLS, etc.

Comprendre cette structure est la base pour interpréter ce que PE-Bear affiche.

Positionnement : ce que PE-Bear fait bien (et ce qu’il ne cherche pas à faire)

PE-Bear est excellent pour :

• Lire rapidement les en-têtes et répertoires PE.
• Visualiser la structure et la « cartographie » des sections.
• Inspecter imports, exports, ressources, relocations, TLS et autres éléments de la table des data directories.
• Repérer des anomalies fréquentes (sections étranges, tailles incohérentes, attributs suspects, imports révélateurs).
• Démarrer une désassemblage rapide depuis un RVA/offset.

En revanche, PE-Bear n’a pas vocation à remplacer :

• Un débogueur (x64dbg/WinDbg),
• Un désassembleur/decompiler complet (IDA/Ghidra/Binary Ninja),
• Un framework d’analyse dynamique (sandbox, instrumentation).

Il s’insère plutôt comme un « microscope » statique rapide avant de passer à des outils plus lourds.

Pourquoi c’est important : impact concret et bénéfices en pratique

En analyse de sécurité (malware / triage)

En triage, la question n’est pas « comment fonctionne exactement ce binaire », mais :

• Est-ce un fichier PE valide ? est-il suspect ?
• Est-il packé/obfusqué ?
• Quelles DLL et quelles API importe-t-il (indices de capacités) ?
• Contient-il des ressources (payload, config chiffrée, icônes trompeuses) ?
• Présente-t-il des sections ou des tailles incohérentes (typique de packers et de fichiers corrompus) ?

PE-Bear est conçu précisément pour obtenir ces réponses vite.

En rétro-ingénierie et en debugging « système »

Pour un développeur bas niveau (drivers, reverse, instrumentation), PE-Bear sert aussi à :

• Vérifier des flags de compilation, l’architecture (PE32/PE64), des timestamps.
• Comprendre l’organisation mémoire du binaire (sections, alignements, RVA).
• Inspecter exports/imports pour vérifier une ABI, un ordinal, une dépendance.
• Comparer deux builds (fonctionnalité de comparaison sélective) pour repérer ce qui a changé.

Pour éviter des erreurs coûteuses

Sans une vue PE correcte, il est facile de mal interpréter un fichier : confondre taille sur disque vs taille mappée, ignorer des imports retardés, se tromper sur l’entry point réel, ou passer à côté d’une section cachée. L’interface « structurée » de PE-Bear aide à réduire ces erreurs.

Installation et mise en œuvre : WinGet, vérifications, premier lancement

Prérequis : WinGet opérationnel

Sur Windows 10/11, WinGet est généralement disponible via le composant « App Installer » (Microsoft). Si la commande winget n’est pas reconnue, il faut d’abord corriger ce point avant de continuer.

Installation via WinGet (recommandé)

Le package WinGet de PE-Bear existe et peut être installé de manière reproductible.

Dans un terminal (PowerShell ou Windows Terminal) :

winget install -e --id hasherezade.PE-bear

winget install -e --id hasherezade.PE-bear

Le flag -e (exact) évite d’installer un autre paquet au nom proche. Une fois l’installation terminée, PE-Bear est disponible dans le menu Démarrer.

Vérifier ce que WinGet va installer (bon réflexe)

Avant installation, ou en cas de doute, utilisez search puis show.

winget search PE-bear
winget show -e --id hasherezade.PE-bear

winget search PE-bear
winget show -e --id hasherezade.PE-bear

Cela permet de vérifier l’éditeur, la version, et la source.

Premier lancement : recommandations de base

Au premier démarrage :

• Travaillez dans un répertoire de travail dédié (ex. C:\Samples\) et évitez d’ouvrir des échantillons directement depuis Downloads.
• Pour des échantillons potentiellement malveillants, privilégiez une VM et des règles d’hygiène standard (pas de double-clic, pas d’exécution, réseau contrôlé).
• Gardez en tête que PE-Bear fait une analyse statique. Ouvrir un fichier PE n’équivaut pas à l’exécuter, mais la prudence reste de mise sur des machines de production.

Utilisation détaillée : méthode d’analyse pas à pas dans PE-Bear

L’intérêt de PE-Bear, ce n’est pas seulement « voir des champs ». C’est d’appliquer une démarche répétable. Voici une méthode qui fonctionne bien.

Étape A — Valider l’identité du binaire (architecture, cohérence, anomalies)

Commencez par les informations globales :

• Type : PE32 vs PE32+ (PE64). Cela conditionne la lecture de structures et les offsets.
• Machine : x86, x64, ARM64.
• Entrypoint : RVA de l’entry point ; comparez-le à la section dans laquelle il tombe.
• Subsystem : console, GUI, driver.
• Timestamps et caractéristiques : utiles mais pas « preuve » (faciles à forger).

Recherchez des incohérences : un entrypoint dans une section atypique, des tailles impossibles, des alignements exotiques, un nombre de sections très élevé, etc.

Étape B — Lire la cartographie des sections (le cœur du « first view »)

PE-Bear met en avant la visualisation du layout des sections, ce qui aide à comprendre rapidement la structure :

• Nom des sections (.text, .rdata, .data, .rsrc, etc.) : un repère, mais pas une garantie.
• RVA / Raw offset : distinguez bien l’adresse virtuelle (mappée en mémoire) de l’offset dans le fichier.
• VirtualSize vs SizeOfRawData : un grand écart peut être normal (alignements) ou suspect (packing, sections surdimensionnées, données cachées).
• Permissions (R/W/X) : une section RWX est un signal d’alerte fréquent.

Conseil pratique : si vous devez n’en faire qu’une, c’est cette étape. Beaucoup d’indices « tombent » rien qu’en regardant les sections.

Étape C — Inspecter les Data Directories (imports, exports, ressources, relocations…)

Les data directories sont une sorte de table d’orientation vers les structures majeures du PE. Dans PE-Bear, vous pouvez naviguer rapidement entre elles.

Imports Les imports répondent à : « de quoi ce binaire a besoin pour fonctionner ? ». En pratique :

• Regardez les DLL importées (ex. kernel32.dll, advapi32.dll, wininet.dll, ws2_32.dll).
• Regardez les API (ex. création de processus, injection, crypto, réseau, persistance).
• Faites attention aux imports minimaux + section suspecte : c’est typique d’un binaire packé qui résout ses API dynamiquement.

Exports Utile surtout pour les DLL :

• Confirmez le nom des fonctions exportées, ordinals, et la cohérence avec une ABI attendue.
• Repérez les « forwarding exports » (exports qui redirigent vers une autre DLL) si présents.

Ressources (RSRC) Les ressources peuvent contenir : icônes, version info, manifests, mais aussi des blobs de données.

• Vérifiez VersionInfo et manifest (UAC, requestedExecutionLevel).
• Inspectez les ressources de type binaire : elles peuvent cacher une configuration ou un payload.

Relocations / TLS / Debug Selon le cas, ces répertoires indiquent :

• Relocations : compatibilité ASLR et présence d’une table de relocation.
• TLS : callbacks TLS (un moyen d’exécuter du code avant l’entry point classique).
• Debug : présence de symboles/paths (rare en malware, mais pas impossible).

Étape D — Détection de packers par signatures

PE-Bear embarque un mécanisme de signatures (historiquement issu d’une base type PEiD). Cela ne doit pas être interprété comme une vérité, mais comme un indice.

Bon usage :

• Si un packer est détecté, vérifiez si les sections ressemblent à un binaire packé (peu d’imports, section .text anormale, entropie élevée suggérée par l’aspect des données).
• Si rien n’est détecté, ne concluez pas à « non packé » : les packers modernes ou custom échappent souvent à ce type de détection.

Étape E — Désassemblage rapide depuis un RVA/offset

PE-Bear propose un désassemblage « rapide » (capstone) utile pour :

• Vérifier si l’entry point semble légitime.
• Examiner un prologue de fonction.
• Confirmer une hypothèse (ex. un appel réseau ou une routine de déchiffrement).

Pratique : partez de l’entry point, puis suivez quelques jumps/calls pour déterminer si vous êtes dans un stub de dépack ou dans du code « métier ».

Étape F — Comparer deux binaires (diff sélectif)

La comparaison est utile pour :

• Vérifier l’impact d’un changement de compilation.
• Identifier une modification malveillante sur un binaire légitime.
• Comparer deux échantillons d’une même famille.

Méthode : comparez en priorité les sections, imports/exports, ressources et l’entry point. C’est souvent là que les divergences significatives apparaissent le plus vite.

Étape G — Édition légère : ajouter sections/imports (avec prudence)

PE-Bear permet certaines modifications (par exemple ajout d’éléments, sections ou imports). C’est puissant, mais cela doit rester un outil de laboratoire :

• Modifier un PE peut casser les signatures, la validité du binaire, ou son chargement.
• Toute modification doit être suivie d’une revalidation (structure, checks, chargement) et idéalement d’un test dans un environnement isolé.

Conclusion

PE-Bear est un excellent outil de « première analyse » pour les fichiers PE : rapide à installer, agréable à utiliser, et surtout très efficace pour obtenir une compréhension structurée d’un exécutable Windows avant d’aller plus loin. En adoptant une méthode (en-têtes → sections → répertoires → imports/ressources → désassemblage rapide), vous obtenez des résultats fiables et reproductibles, que ce soit en triage malware ou en rétro-ingénierie plus classique.

L’approche la plus productive consiste à traiter PE-Bear comme une étape standard de votre pipeline : il vous donne des signaux tôt, vous aide à décider « quel outil ouvrir ensuite », et vous évite de perdre du temps sur des hypothèses fragiles.