Comparateur hexadécimal

À propos du comparateur hexadécimal

Hex File Compare est un diff au niveau de l'octet pour fichiers binaires. Il lit jusqu'à 64 Ko en début de chaque fichier et les affiche côte à côte au format hex-dump canonique inauguré par `od -x` d'Unix et popularisé par HxD : colonne d'offset à gauche en hexadécimal, 16 octets par ligne en paires hex de deux caractères, puis une colonne ASCII à droite où les octets imprimables (0x20–0x7E) apparaissent comme caractère et le reste sous forme de points. Les lignes qui diffèrent sont surlignées ; avec « Différences uniquement » activé, les lignes identiques sont masquées et un balayage de 64 Ko se réduit aux quelques octets qui comptent. Usages professionnels courants : vérifier qu'un patch binaire s'est appliqué proprement (comparer avant/après, compter les différences, vérifier les offsets contre le manifeste), reverse-engineering d'un firmware (diff entre deux versions pour repérer les changements de bootloader ou de table de chaînes), forensique de fichiers (comparer une copie suspecte à une bonne connue pour trouver la frontière de la corruption), validation d'intégrité de téléchargements dont le checksum ne correspond pas pour voir *où* les octets divergent. Pour ce cas d'intégrité, l'outil calcule désormais aussi dans votre navigateur un checksum SHA-256 et CRC32 de chaque fichier entier, et vous laisse coller un SHA-256 publié pour obtenir un verdict réussite/échec par fichier instantané — vous confirmez ainsi *qu'ils* diffèrent et *quelle* copie est authentique. La comparaison s'exécute entièrement dans votre navigateur : le début de chaque fichier est lu via l'API FileReader dans un Uint8Array puis parcouru octet par octet, le hachage utilise l'API native crypto.subtle.digest, et vos fichiers ne quittent pas l'appareil, pas même pour l'analytique.

Quelle quantité est comparée et pourquoi 64 Ko maximum ?

Jusqu'à 64 Ko (65 536 octets) depuis le début de chaque fichier. Le plafond est un choix UX et non une contrainte technique : afficher plus de ~4 000 lignes hex dans un tableau DOM commence à ramer sur mobile, et la majeure partie de la forensique binaire se déroule dans les premiers Ko de toute façon — headers, magic numbers, signatures, blobs de certificat, métadonnées ELF/PE/Mach-O et points d'entrée de patches vivent près du début. Pour des diffs profonds en fin de fichier (logs roulants, payloads chiffrés ajoutés), utilisez un outil bureau comme HxD, 010 Editor, GHex (Linux), ou `cmp -l file_a file_b` sous Unix qui stream tout le fichier et signale chaque octet divergent en octal.

Comment cela se compare-t-il à `diff`, `cmp`, `git diff` et `vbindiff` ?

`diff` est orienté lignes et suppose UTF-8 ou ASCII texte ; sur du binaire il donne une sortie inutilisable. `cmp -l a b` est orienté octet mais produit une liste plate (offset, byte_a, byte_b en octal) sans contexte — précis mais difficile à lire. `git diff --binary` n'encode que des deltas, sans affichage lisible. `vbindiff` (Visual Binary Diff) est l'analogue le plus proche et notre source d'inspiration : vue hex à deux panneaux avec défilement synchronisé, colonne ASCII et différences surlignées. La différence est que vbindiff tourne dans un terminal ; cet outil tourne dans le navigateur, accepte le glisser-déposer et ne nécessite aucune installation. Pour des fichiers massifs ou des vérifications CI scriptées, préférez `cmp -l` chaîné à `wc -l` pour un compte rapide ou `radiff2 -x` (le diff hex de radare2) pour une sortie structurée.

Pourquoi certains octets sont-ils affichés en points dans la colonne ASCII alors qu'ils ressemblent à des lettres ?

La colonne ASCII suit la plage imprimable stricte 0x20–0x7E (espace au tilde), convention de `od -c` POSIX d'origine et de `hexdump` BSD. Tout octet hors de cette plage est remplacé par un seul point pour garder chaque ligne exactement à 16 caractères et aligner les colonnes. Cela inclut : tabulation (0x09), nouvelle ligne (0x0A), nul (0x00), tous les octets 0x80–0xFF (ASCII étendu et octets de continuation UTF-8) et DEL (0x7F). Si vous devez voir du texte UTF-8 dans le binaire (noms de fichiers dans un ZIP, chaînes dans un Mach-O, JSON dans un blob enveloppé), copiez l'offset et ouvrez le fichier dans un visualiseur conscient d'UTF-8 comme 010 Editor ou utilisez `strings fichier | grep` pour un dump rapide.

Quels sont les magic numbers (signatures binaires) les plus utiles ?

Les premiers octets de presque tout format déclarent ce qu'il est — les connaître transforme le hex-diff en activité consciente du format. Magic numbers clés (octets depuis 0x00) : PNG 89 50 4E 47 0D 0A 1A 0A, JPEG FF D8 FF (puis E0/E1/E2/E3/DB pour JFIF/EXIF/etc.), GIF 47 49 46 38 (« GIF8 »), PDF 25 50 44 46 (« %PDF »), ZIP/JAR/DOCX/XLSX 50 4B 03 04 (« PK\03\04 »), RAR4 52 61 72 21 1A 07 00, RAR5 52 61 72 21 1A 07 01 00, 7Z 37 7A BC AF 27 1C, GZIP 1F 8B, BZIP2 42 5A 68 (« BZh »), ELF (exécutables Linux) 7F 45 4C 46 (« \x7FELF »), Windows PE/EXE 4D 5A (« MZ ») avec pointeur d'en-tête PE à l'offset 0x3C, Mach-O (macOS) FE ED FA CE/CF ou CE/CF FA ED FE, WAV 52 49 46 46 (« RIFF ») puis « WAVE », MP4 commence par des octets de taille puis 66 74 79 70 (« ftyp ») à l'offset 4, SQLite 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00. Si votre hex démarre autrement, le fichier est probablement chiffré, compressé ou corrompu.

Comment repérer un patch binaire (mise à jour DLL/EXE, delta firmware) dans le diff hex ?

Les patches binaires concentrent généralement leurs changements dans quelques petites régions plutôt que de les répartir uniformément. Avec « Différences uniquement » activé, regardez l'espacement des offsets divergents : un patch logiciel (correctif de sécurité, bug fix) touche typiquement une à trois plages courtes de 4–64 octets dans les sections .text ou .rdata (PE Windows) ou les segments .text et .rodata (ELF), correspondant à des patches d'instruction ou des mises à jour de constantes. Une mise à jour de firmware couvre des plages plus larges, souvent avec un checksum ou une signature en fin. Un bump de version en chaîne apparaît comme un changement ASCII contigu (par ex. « 1.0.4 » → « 1.0.5 » à un offset stable). Si le diff est uniforme — chaque ligne change — les deux fichiers ne sont pas liés ou l'un a été chiffré avec une autre clé. Si le diff est identique au début puis devient uniforme à partir d'un certain offset, vous avez attrapé une frontière de corruption de téléchargement ou une troncature.

Quelle est la différence entre big-endian et little-endian dans un hex dump ?

L'endianness est l'ordre dans lequel les valeurs multi-octets (entiers 16, 32, 64 bits) sont stockées. Little-endian (Intel x86, AMD64, ARM en mode par défaut) stocke l'octet de poids faible en premier : la valeur 32 bits 0x12345678 apparaît dans le dump comme 78 56 34 12. Big-endian (ordre réseau selon RFC 1700, PowerPC classique, SPARC, m68k, la plupart des en-têtes de formats comme PNG et JPEG, et les en-têtes IP/TCP sur le fil) stocke l'octet de poids fort en premier : la même valeur apparaît comme 12 34 56 78. Lorsque vous comparez deux binaires compilés pour des architectures différentes, ce qui ressemble à un diff gigantesque peut n'être qu'un retournement d'endianness. Vérification rapide : la plupart des en-têtes (PNG, ZIP, ELF, PDF) incrustent leur taille ou leur signature dans une endianness connue, donc si votre hex commence par des magic numbers dans le bon ordre, votre interprétation est correcte.

Pourquoi mes fichiers sont-ils déclarés identiques alors qu'ils devraient différer (ou l'inverse) ?

Trois pièges classiques. Premier, BOM ou fins de ligne — les fichiers enregistrés en CRLF (Windows) versus LF (Unix) diffèrent à chaque octet de nouvelle ligne ; l'outil signalera fidèlement de nombreux petits diffs là où le contenu logique est identique. Deuxième, horodatages embarqués — beaucoup de formats (ZIP, DOCX, PDF, exécutables avec info de débogage, PNG avec chunk de création) embarquent des dates de création ou modification dans le binaire, donc deux fichiers compilés du même code source à quelques minutes d'écart diffèrent à ces offsets. Troisième, non-déterminisme de compression — gzip, ZIP et PDF peuvent produire des octets différents pour la même entrée selon le niveau de compression, l'état du dictionnaire ou la version de bibliothèque ; pour comparer le contenu logique, décompressez les deux d'abord. Pour éliminer les diffs triviaux, utilisez `dos2unix fichier`, `strip-nondeterminism --type=zip` pour les horodatages, et décompressez avant de comparer.

Mes fichiers sont-ils envoyés sur un serveur ou sauvegardés quelque part ?

Non. Le diff tourne entièrement dans votre navigateur. Chaque fichier est lu via FileReader.readAsArrayBuffer dans un Uint8Array, parcouru octet par octet pour construire les lignes hex et rendu en DOM pur ; les checksums SHA-256 et CRC32 sont calculés localement avec l'API native crypto.subtle.digest et un CRC à table de correspondance en JavaScript pur. Aucun contenu, nom de fichier, offset, checksum ou statistique de diff n'est envoyé à notre serveur, journalisé dans l'analytique ou conservé en localStorage. Ouvrez l'onglet Réseau des DevTools avant de cliquer sur Comparer — vous verrez zéro nouvelle requête pendant la comparaison et zéro requête contenant le fichier pendant le rendu. Fermer l'onglet purge tous les tampons.

J'ai deux téléchargements du même fichier et l'un est corrompu — comment confirmer quelle copie est authentique ?

Utilisez le checksum, pas le diff d'octets. Le diff hex indique *que* et *où* deux copies diffèrent, mais pas laquelle est authentique — pour cela il faut comparer à la valeur réellement publiée par l'auteur. La plupart des projets sérieux publient un SHA-256 à côté de leur firmware, ISO, installateur ou tarball de release (souvent dans un fichier SHASUMS, .sha256 ou de signature). Déposez les deux téléchargements dans cet outil : il calcule un SHA-256 du fichier entier (le standard de fait pour l'intégrité) et un CRC32 (courant pour le firmware et l'intégrité des ZIP) pour chacun. Collez le SHA-256 de l'auteur dans le champ « Somme de contrôle attendue » et l'outil affiche un badge vert « Correspond » sur le fichier authentique et un badge rouge « Ne correspond pas » sur la mauvaise copie. Si aucun ne correspond, les deux téléchargements sont corrompus ou altérés — retéléchargez via une connexion de confiance. Le SHA-256 résiste aux collisions : une correspondance est une forte preuve cryptographique que le fichier est bit pour bit celui livré par l'auteur ; le CRC32 ne détecte que la corruption accidentelle (il n'est pas sûr contre l'altération délibérée), donc privilégiez toujours le verdict SHA-256 pour l'authenticité.