Comment utiliser Binwalk : extraire les fichiers cachés

Qu'est-ce que binwalk ?

Binwalk est un outil open source qui analyse un fichier binaire à la recherche des signatures d'autres formats de fichiers, indique la position de chacune et les extrait au besoin. Craig Heffner l'a publié en 2010 pour rendre l'analyse des firmwares de routeurs moins fastidieuse, et il est aujourd'hui maintenu sous l'organisation ReFirmLabs sur GitHub.

Le principe tient en un paragraphe. Presque tous les formats de fichiers commencent par une séquence d'octets fixe appelée nombre magique : une archive ZIP démarre par PK\x03\x04, un PNG par \x89PNG, un flux gzip par \x1f\x8b. Binwalk parcourt le fichier entier octet par octet, compare ce qu'il voit à une bibliothèque de plusieurs centaines de signatures et affiche la liste des correspondances. La commande file fait la même chose, mais uniquement à la position zéro. Binwalk le fait partout.

Toute la différence est là. file challenge.png vous dit qu'il s'agit d'un PNG et s'arrête, parce que les huit premiers octets disent PNG et que file n'a aucune raison de continuer. Binwalk continue, et trouve l'archive que quelqu'un a ajoutée à l'octet 7858.

Deux usages dominent. En analyse de firmware, il découpe une image de mémoire flash .bin monolithique en chargeur d'amorçage, noyau et système de fichiers racine, ce qui vous permet de monter ce dernier et d'en lire le code. En forensique CTF, il répond à la question « y a-t-il autre chose dans ce fichier », qui est la question autour de laquelle la plupart des défis de forensique et de stéganographie sont bâtis.

Binwalk v2 ou binwalk v3 : lequel installer

C'est le point qui perd tout le monde en 2026, et aucun tutoriel antérieur à fin 2024 n'en parle. Il existe deux binwalk.

Binwalk 2.x est l'implémentation Python d'origine. C'est celle que décrivent dix ans de tutoriels, de write-ups et de réponses Stack Overflow. Kali le distribue sous le nom binwalk, en version 2.4.3.

Binwalk 3.x est une réécriture complète en Rust, sortie en version 3.1.0 le 31 octobre 2024. Elle est plus rapide, produit moins de faux positifs et embarque davantage d'extracteurs intégrés. Kali le distribue séparément sous le nom binwalk3, et la version 3.1.0-0kali3 est arrivée dans kali-rolling le 16 octobre 2025.

Installez celui dont vous avez besoin, ou les deux, puisque les binaires portent des noms différents et ne se marchent pas dessus :

sudo apt update
sudo apt install binwalk      # Python, v2.4.3, command: binwalk
sudo apt install binwalk3     # Rust, v3.1.0, command: binwalk3

Sur les autres distributions, ou si vous voulez la version amont la plus récente, la v3 s'installe via Cargo :

cargo install binwalk

Aucune des deux versions n'extrait grand-chose toute seule. Toutes deux appellent des utilitaires externes pour décompresser ce qu'elles trouvent, et le script de dépendances Ubuntu de la v3 en installe une longue liste : 7zip, sleuthkit, cabextract, unyaffs, srecord, device-tree-compiler, lz4, lzop, unrar, zstd, plus une version Debian de sasquatch pour les variantes SquashFS bricolées par les fabricants, dont les routeurs grand public sont truffés. Si une extraction annonce un système de fichiers puis ne produit rien, cherchez d'abord l'utilitaire manquant, pas une image corrompue.

Mon conseil, et il n'est pas très populaire : commencez par la v2. Tous les guides, tous les write-ups de CTF et tous les démontages de firmware que vous lirez cette année supposent les options de la v2, et la v2 conserve des fonctions que la v3 a abandonnées. La ligne de commande de la v3 tient en quatorze options, et la comparaison hexadécimale (-W), l'analyse d'opcodes (-A) et le découpage manuel (--dd) n'en font pas partie. Sortez binwalk3 quand vous attaquez une grosse image de firmware et que vous voulez de la vitesse.

Votre premier scan : lire la table des signatures

Lancez binwalk sans aucune option. C'est un scan de signatures en lecture seule, et c'est toujours le bon premier geste :

binwalk challenge.png

Voici une sortie réelle de binwalk 2.3.3 sur un PNG auquel une archive ZIP a été ajoutée, la construction classique en CTF :

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             PNG image, 64 x 64, 8-bit/color RGB, non-interlaced
41            0x29            Zlib compressed data, default compression
7858          0x1EB2          Zip archive data, at least v1.0 to extract, compressed size: 22, uncompressed size: 22, name: flag.txt
8024          0x1F58          End of Zip archive, footer length: 22

Trois colonnes, et les deux premières donnent le même nombre en décimal et en hexadécimal. Lisez la table depuis le haut :

• Position 0, image PNG. Le fichier est bien ce qu'il prétend être. Attendu.
• Position 41, données compressées Zlib. C'est du bruit. Un PNG stocke ses pixels dans un bloc IDAT compressé en zlib, donc tout PNG valide produit cette ligne. Apprendre à distinguer les correspondances structurelles des correspondances intéressantes, c'est l'essentiel du métier.
• Position 7858, archive ZIP. Voilà la trouvaille. Binwalk a même analysé le répertoire central de l'archive et en a lu le nom de fichier : flag.txt.
• Position 8024, fin de l'archive ZIP. Le pied de l'archive, qui confirme qu'elle est complète et non tronquée.

Quand un scan renvoie cinquante lignes et qu'un seul format vous intéresse, filtrez avec -y pour inclure et -x pour exclure :

binwalk -y zip challenge.png

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
7858          0x1EB2          Zip archive data, at least v1.0 to extract, compressed size: 22, uncompressed size: 22, name: flag.txt
8024          0x1F58          End of Zip archive, footer length: 22

Dans la pratique, vous verrez des faux positifs, et le bon réflexe est de les attendre plutôt que de leur courir après. Des données compressées aléatoires contiennent parfois quatre octets qui ressemblent à un en-tête TIFF. Une correspondance avec une position plausible, une taille cohérente et un pied qui suit est réelle. Une correspondance isolée avec une taille absurde est une coïncidence.

Extraire avec -e, et le piège du compte root

Une fois que la table montre quelque chose qui vaut la peine, -e le sort du fichier :

binwalk -e challenge.png

Si vous êtes connecté en root, ce qui décrit beaucoup d'utilisateurs de Kali, cette commande échoue et déroule un mur de traceback Python. La ligne qui compte est celle-ci :

Extractor Exception: Binwalk extraction uses many third party utilities,
which may not be secure. If you wish to have extraction utilities executed
as the current user, use '--run-as=root' (binwalk itself must be run as root).

Ce n'est pas un bug, et mieux vaut le comprendre que le contourner à l'aveugle. Extraire, cela veut dire que binwalk confie des octets contrôlés par un attaquant à une pile de décompresseurs tiers, et ces décompresseurs ont un long historique de failles de traversée de répertoires. Refuser de faire cela en root est un garde-fou délibéré, ajouté en version 2.3.3. La solution honnête consiste à travailler sous un compte normal. Si vous tenez à rester root, vous devez le dire explicitement :

binwalk --run-as=root -e challenge.png

L'extraction atterrit dans un répertoire nommé d'après le fichier d'entrée, chaque morceau découpé portant le nom de sa position en hexadécimal :

_challenge.png.extracted:
-rw-r--r-- 1 user user   188 1EB2.zip
-rw-r--r-- 1 user user 12352 29
-rw-r--r-- 1 user user  8005 29.zlib
-rw-r--r-- 1 user user    22 flag.txt

Ce listing raconte une petite histoire. 1EB2.zip est l'archive ajoutée, découpée à la position hexadécimale 0x1EB2, et flag.txt est ce qui en est sorti quand binwalk l'a décompressée pour vous. Le duo 29 et 29.zlib, ce sont les données de pixels du PNG lui-même : le flux compressé et son contenu décompressé. Binwalk a extrait le vrai positif ennuyeux en même temps que l'intéressant, et c'est normal.

Binwalk 3 utilise la même option -e mais écrit par défaut dans un répertoire nommé extractions plutôt que _nomdufichier.extracted. Les deux versions acceptent -C pour choisir votre propre répertoire de sortie :

binwalk -e -C ./output challenge.png

Une option de la v2 mérite encore sa place dans votre mémoire musculaire. -z découpe les plages d'octets brutes et n'exécute aucun décompresseur externe :

binwalk -e -z suspicious.bin

Vous obtenez des fichiers plutôt qu'un contenu déjà analysé, ce qui est plus lent à exploiter et nettement plus sûr sur un échantillon auquel vous ne faites pas confiance.

Extraction récursive pour les firmwares

Les images de firmware s'emboîtent. Extrayez une image de routeur et vous obtenez un noyau compressé et un blob SquashFS. Extrayez ceux-là et vous obtenez le vrai noyau et une arborescence complète. Le faire à la main demande trois ou quatre passages de la même commande, alors binwalk l'automatise avec -M, nommée d'après les poupées matriochkas :

binwalk -Me firmware.bin

Cette seule commande analyse, extrait, puis réanalyse tout ce qu'elle vient d'extraire, jusqu'à une profondeur de huit niveaux par défaut. La sortie est longue. Redirigez-la dans un fichier et lisez-la ensuite.

Le contrôle de la profondeur compte plus qu'on ne l'imagine. Sur une grosse image, la récursion s'enfonce dans les données décompressées, produit des milliers de correspondances parasites et transforme l'exercice en remplissage de disque. Limitez-la :

binwalk -Me -d 2 firmware.bin

Le butin, au bout du compte, est en général un répertoire nommé quelque chose comme squashfs-root, contenant un système de fichiers Linux embarqué complet. C'est là que le travail intéressant commence : un /etc/passwd avec des empreintes en dur, des clés privées sous /etc, des scripts de démarrage dans /etc/init.d qui révèlent les services à l'écoute, et des binaires CGI dans /www, le terrain habituel de l'injection de commandes sur les équipements grand public.

Quand binwalk annonce un système de fichiers mais que le répertoire d'extraction reste vide, la cause est presque toujours un décompresseur manquant. Les fabricants modifient SquashFS avec des compressions non standard, le unsquashfs d'origine refuse, et sasquatch existe précisément pour ces variantes. Installez-le avant de conclure que l'image est chiffrée.

Analyse d'entropie : repérer le chiffrement sans signature

Il arrive qu'un scan ne renvoie rien. Pas de système de fichiers, pas de noyau, aucune signature digne de ce nom. La bonne question devient alors : ces données sont-elles chiffrées, compressées, ou simplement dans un format que binwalk ne connaît pas ? L'entropie y répond.

L'entropie mesure le caractère aléatoire de données, sur une échelle de 0 à 1. Le texte brut et le code non compressé restent bas, autour de 0,3 à 0,6, parce qu'ils se répètent. Les données compressées et chiffrées frôlent 1,0, parce que ces deux traitements détruisent la répétition par construction.

binwalk -E firmware.bin

La version 2 affiche les points où l'entropie bascule et génère un graphique, sauf si vous passez -N pour le supprimer. Sur le PNG de tout à l'heure :

DECIMAL       HEXADECIMAL     ENTROPY
--------------------------------------------------------------------------------
4096          0x1000          Rising entropy edge (0.956868)

Un front montant à 0x1000 et aucun front descendant, ce qui se lit « en-tête à faible entropie, puis données compressées jusqu'à la fin ». Pour un PNG, c'est exactement correct.

Lire un vrai graphique d'entropie de firmware relève de la reconnaissance de formes, et trois profils couvrent presque tout :

• Plat et haut sur tout le fichier. L'image est chiffrée, ou compressée d'un seul bloc. Rien à découper tant que vous n'avez pas la clé.
• En blocs, alternance de haut et de bas. Un firmware normal. Les zones basses sont les en-têtes, le remplissage et le code non compressé, les zones hautes sont les sections compressées, et les transitions sont vos limites d'extraction.
• Majoritairement bas avec un seul plateau haut. Une charge compressée posée dans un fichier par ailleurs ordinaire. Ce plateau est ce que vous êtes venu chercher.

L'entropie est un outil de tri, pas une preuve. Elle vous dit que des données sont compressées ou chiffrées et ne peut pas vous dire lequel des deux, parce qu'un bon compresseur et un bon chiffrement produisent des sorties statistiquement semblables.

Binwalk en forensique CTF : une méthode reproductible

Dans un défi de forensique ou de stéganographie, binwalk est la deuxième commande que vous tapez. Voici la séquence qui résout la majorité des problèmes du type « voici un fichier, trouvez le drapeau », dans l'ordre qui vous coûte le moins de temps :

1. Lancez file d'abord. Une seconde, et il vous dit si l'extension est honnête. Un .jpg que file appelle archive ZIP vous a déjà donné la réponse.
2. Lancez binwalk sans options. Lisez la table. Comparez ce qu'il a trouvé à ce que le format contient légitimement. Tout ce qui dépasse la fin attendue du fichier constitue le défi.
3. Lancez strings -n 8 fichier | less. Les drapeaux traînent en clair bien plus souvent qu'on ne l'avoue, et cette commande les attrape avant que vous ne passiez vingt minutes à découper.
4. Extrayez avec binwalk -e. Si le résultat est une archive protégée par mot de passe, c'est le chemin prévu, et le cassage relève d'un autre outil.
5. Sortez les spécialistes seulement après. zsteg pour les données LSB en PNG et BMP, steghide pour le JPEG et le WAV avec passphrase, exiftool pour les champs de métadonnées.

L'étape 5 est celle par laquelle les gens commencent, et commencer là fait perdre du temps. Les données ajoutées sont bien plus fréquentes dans les défis débutants et intermédiaires que la vraie stéganographie sur bit de poids faible, parce qu'il faut dix secondes à l'auteur pour les fabriquer avec cat. Notre guide des techniques de stéganographie explique quoi faire quand binwalk revient bredouille et que le drapeau est réellement caché dans les pixels, et la lecture des métadonnées avec ExifTool couvre les champs que binwalk ne regarde jamais.

Une habitude à prendre : quand -e ne donne rien alors que la table des signatures montre clairement une archive, découpez-la à la main avec dd en utilisant la position affichée par binwalk. L'octet 7858 du scan précédent donne :

dd if=challenge.png of=carved.zip bs=1 skip=7858

C'est rustique et ça marche toujours, ce qui explique pourquoi cette commande doit rester en tête à côté des options plus élégantes.

Quand binwalk n'est pas le bon outil

Savoir où un outil s'arrête vaut autant que savoir le manier, et binwalk a quatre limites nettes.

Il ne trouve pas les données cachées dans les pixels. La stéganographie sur bit de poids faible modifie des octets existants au lieu d'en ajouter, donc il n'y a aucune signature à reconnaître ni aucune position à signaler. Binwalk analysera une image encodée en LSB et vous dira, à juste titre, que rien n'y a été ajouté. Passez à zsteg ou stegsolve.

Il ne lit pas les métadonnées. Les balises EXIF, les paquets XMP, les trames ID3 et les propriétés de document PDF sont des champs structurés à l'intérieur du format, pas des fichiers imbriqués. C'est le domaine d'ExifTool.

Ce n'est pas un outil de forensique disque. Pour une image disque complète avec table de partitions et fichiers supprimés à récupérer, foremost, scalpel et The Sleuth Kit comprennent des structures de systèmes de fichiers que binwalk traite comme un flux d'octets indifférencié.

Il ne peut rien contre le chiffrement. Si l'entropie reste plate à 1,0 sur toute l'image, il ne reste plus aucune structure à reconnaître. Cela devient un problème de récupération de clé, et le plus souvent un problème matériel.

Considérations légales et éthiques

Deux risques sont propres à cet outil, et les deux méritent un instant de réflexion avant de le pointer sur un fichier inconnu.

Le premier, c'est que l'extraction exécute du code que vous n'avez pas écrit sur des données que vous ne contrôlez pas. La CVE-2022-4510 en est l'illustration : les versions 2.1.2b à 2.3.3 de binwalk contenaient une faille de traversée de répertoires dans le greffon d'extraction PFS, et une image de système de fichiers forgée pouvait écrire des fichiers partout où le processus avait accès. Déposez un module malveillant dans .config/binwalk/plugins et la prochaine exécution de binwalk le lance. La faille a été corrigée en 2.3.4, mais la leçon générale survit au correctif. Lancez -e sur des échantillons non fiables dans une machine virtuelle ou un conteneur, gardez l'outil à jour, et utilisez -z quand seuls les octets vous intéressent.

Le second est juridique plutôt que technique. Un firmware est un logiciel protégé par le droit d'auteur, et sa rétro-ingénierie s'inscrit dans une mosaïque d'exceptions propres à chaque juridiction. Aux États-Unis, le Bibliothécaire du Congrès a reconduit l'exception au titre de la section 1201 du DMCA pour la recherche de sécurité de bonne foi sur des appareils acquis légalement, lors du neuvième réexamen triennal, en vigueur depuis le 28 octobre 2024. Ces exceptions sont assorties de conditions, et elles ne valent pas autorisation générale.

Les analyses que vous pouvez mener sans hésiter :

• Les firmwares d'appareils qui vous appartiennent, téléchargés depuis le site de support public du fabricant
• Les fichiers fournis par un client dans le cadre d'une mission signée dont le périmètre les nomme
• Les défis CTF et les images d'entraînement volontairement vulnérables
• Les projets de firmware open source comme OpenWrt

Trouver un identifiant en dur dans un produit commercialisé, c'est le début d'un processus de divulgation, pas la fin d'un projet de recherche. Signalez-le au fabricant, laissez-lui un délai raisonnable, et publiez ensuite.

Questions fréquentes