Comparador Hex de Archivos

Acerca del Comparador Hex de Archivos

El Comparador Hex de Archivos es un diff a nivel de byte para archivos binarios. Lee hasta 64 KB del inicio de cada archivo y los muestra en paralelo con el formato hex-dump canónico que inauguró `od -x` de Unix y popularizó HxD: columna izquierda de offset en hexadecimal, 16 bytes por fila como pares de dos caracteres hex, y a la derecha una columna ASCII donde los bytes imprimibles (0x20–0x7E) aparecen como su carácter y el resto como puntos. Las filas que difieren se resaltan; con "Mostrar solo diferencias" activado, las filas idénticas se colapsan y un escaneo de 64 KB se reduce al puñado de bytes que importa. Usos profesionales habituales: verificar que un parche binario se aplicó limpiamente (comparar antes/después, contar diferencias, comprobar offsets contra el manifiesto), ingeniería inversa de un firmware (diff entre dos versiones para detectar cambios en el bootloader o la tabla de cadenas), análisis forense de archivos corruptos (comparar copia sospechosa con una buena conocida para hallar el límite de la corrupción), y validar integridad de descargas con checksum mal cuando quieres ver *dónde* divergen los bytes y no solo saber que lo hacen. La comparación corre íntegramente en tu navegador con la API FileReader y un walker sobre DataView de typed arrays — tus archivos no salen del dispositivo ni para analítica.

¿Cuánto se compara y por qué el tope son 64 KB?

Hasta 64 KB (65 536 bytes) desde el inicio de cada archivo. El tope es una decisión de UX más que un límite técnico: renderizar más de ~4 000 filas hex en una tabla del DOM se vuelve lento en móvil, y la mayor parte del análisis forense ocurre al inicio del archivo — headers, magic numbers, firmas, blobs de certificado, metadatos ELF/PE/Mach-O y puntos de entrada de parches viven cerca del comienzo. Para diffs profundos al final del archivo (logs rolling, payloads cifrados anexados), usa una herramienta de escritorio como HxD, 010 Editor, GHex (Linux), o `cmp -l file_a file_b` en Unix, que stream el archivo entero y reporta cada byte distinto con valores en octal.

¿Cómo compara con `diff`, `cmp`, `git diff` y `vbindiff`?

`diff` es orientado a líneas y asume UTF-8 o ASCII de texto; en binarios da salida inútil. `cmp -l a b` es byte a byte pero produce una lista plana (offset, byte_a, byte_b en octal) sin contexto — preciso pero difícil de leer. `git diff --binary` solo codifica deltas, no los muestra legibles. `vbindiff` (Visual Binary Diff) es el equivalente más cercano y nuestra inspiración: vista hex de dos paneles con scroll sincronizado, columna ASCII y diferencias resaltadas. La diferencia es que vbindiff corre en terminal; esta herramienta corre en navegador, acepta arrastrar y soltar y no requiere instalación. Para archivos enormes o checks de CI con script, prefiere `cmp -l` redirigido a `wc -l` para un conteo rápido o `radiff2 -x` (diff hex de radare2) para salida estructurada.

¿Por qué algunos bytes aparecen como puntos en la columna ASCII aunque parecen letras?

La columna ASCII sigue el rango imprimible estricto 0x20–0x7E (espacio a tilde), convención de `od -c` original de POSIX y `hexdump` de BSD. Cualquier byte fuera de ese rango se reemplaza por un punto para mantener cada fila exactamente de 16 caracteres y alineadas las columnas. Eso significa: tab (0x09), salto de línea (0x0A), nulo (0x00), todos los bytes 0x80–0xFF (ASCII extendido y bytes de continuación de UTF-8) y DEL (0x7F) se muestran como puntos. Si necesitas ver texto UTF-8 dentro del binario (nombres de archivo en ZIP, cadenas en un binario Mach-O, JSON dentro de un blob codificado), copia el offset y abre el archivo en un visor consciente de UTF-8 como 010 Editor o usa `strings archivo | grep` para un volcado rápido.

¿Qué firmas binarias (magic numbers) más comunes debo buscar?

Los primeros bytes de casi todo formato declaran qué es — saberlos convierte el hex-diff en una actividad consciente del formato. Magic numbers clave (bytes desde 0x00): PNG 89 50 4E 47 0D 0A 1A 0A, JPEG FF D8 FF (luego E0/E1/E2/E3/DB para 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 (ejecutables Linux) 7F 45 4C 46 ("\x7FELF"), Windows PE/EXE 4D 5A ("MZ") con puntero al header PE en offset 0x3C, Mach-O (macOS) FE ED FA CE/CF o CE/CF FA ED FE, WAV 52 49 46 46 ("RIFF") luego "WAVE", MP4 empieza con bytes de tamaño y 66 74 79 70 ("ftyp") en offset 4, SQLite 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00. Si tu hex empieza con otra cosa, el archivo está cifrado, comprimido o corrupto.

¿Cómo detecto un parche binario (actualización DLL/EXE, delta de firmware) en el diff hex?

Los parches binarios suelen concentrar cambios en pocas regiones cortas en vez de repartirlos. Con "Solo diferencias" activo, mira el espaciado de los offsets diferentes: un parche de software (fix de seguridad, bug fix) suele tocar uno a tres rangos cortos de 4–64 bytes en las secciones .text o .rdata (PE de Windows) o .text y .rodata (ELF), correspondientes a parches de instrucción o actualizaciones de constantes. Una actualización de firmware cubre rangos más amplios, a menudo incluyendo un checksum o firma al final. Un bump de versión textual aparece como cambio ASCII contiguo (p.ej. '1.0.4' a '1.0.5' en un offset estable). Si el diff es uniforme — toda fila cambia — los dos archivos son distintos o uno fue cifrado con clave diferente. Si el diff es idéntico al inicio y se vuelve uniforme desde cierto offset, has cazado un límite de corrupción de descarga o un truncamiento.

¿Cuál es la diferencia entre big-endian y little-endian en el hex dump?

Endianness es el orden en que los valores multibyte (enteros de 16, 32, 64 bits) se almacenan. Little-endian (Intel x86, AMD64, ARM por defecto) almacena el byte menos significativo primero: el valor 32-bit 0x12345678 aparece en el dump como 78 56 34 12. Big-endian (orden de red según RFC 1700, PowerPC clásico, SPARC, m68k, la mayoría de headers de formatos como PNG y JPEG, y headers IP/TCP en el cable) almacena el más significativo primero: el mismo valor aparece como 12 34 56 78. Al comparar dos binarios compilados para arquitecturas distintas, lo que parece un diff gigantesco puede ser solo un cambio de endianness. Comprobación rápida: la mayoría de headers (PNG, ZIP, ELF, PDF) incrustan tamaño o firma en una endianness conocida, así que si tu hex empieza con magic numbers en el orden correcto, tienes la interpretación correcta.

¿Por qué mis archivos salen idénticos cuando deberían diferir (o al revés)?

Tres trampas comunes. Primera, BOM o saltos de línea — archivos guardados como CRLF (Windows) frente a LF (Unix) difieren en cada salto; la herramienta reportará fielmente muchos diffs pequeños donde el contenido lógico es idéntico. Segunda, timestamps incrustados — muchos formatos (ZIP, DOCX, PDF, ejecutables con debug, PNG con creación) incrustan fechas dentro del binario, así que dos archivos compilados desde el mismo fuente con minutos de diferencia difieren en esos offsets. Tercera, no determinismo de compresión — gzip, ZIP y PDF pueden producir bytes distintos para la misma entrada según nivel de compresión, estado del diccionario o versión de la librería; para comparar contenido lógico, descomprime ambos primero. Para descartar diffs triviales, usa `dos2unix archivo`, `strip-nondeterminism --type=zip` para timestamps, y descomprime antes de comparar.

¿Mis archivos se suben a un servidor o se guardan?

No. El diff corre íntegramente en tu navegador. Cada archivo se lee con FileReader.readAsArrayBuffer en un Uint8Array, se recorre byte a byte en un bucle ajustado en el hilo principal (cediendo el control mediante microtask cada 4 KB para no bloquear la UI), y las filas hex resultantes se renderizan como DOM plano. Ningún contenido, nombre, offset o estadística sale a nuestro servidor, ni se registra en analítica, ni se guarda en localStorage. Abre la pestaña Red de DevTools antes de pulsar Comparar — verás cero peticiones nuevas durante la comparación y cero peticiones con contenido del archivo durante el render. Cerrar la pestaña purga todos los buffers.