Comparador Hex de Arquivos

Sobre o Comparador Hex de Arquivos

O Comparador Hex de Arquivos é um diff em nível de byte para arquivos binários. Ele lê até 64 KB do início de cada arquivo e os renderiza lado a lado no formato hex-dump canônico inaugurado pelo `od -x` do Unix e popularizado pelo HxD: coluna de offset à esquerda em hexadecimal, 16 bytes por linha como pares hex de dois caracteres, e à direita uma coluna ASCII onde bytes imprimíveis (0x20–0x7E) aparecem como caractere e o resto como pontos. Linhas em que os dois arquivos diferem são realçadas; com 'Mostrar apenas diferenças' ativo, linhas idênticas somem — uma varredura de 64 KB se reduz aos poucos bytes que importam. Usos profissionais comuns: verificar se um patch binário foi aplicado limpo (comparar antes/depois, contar diferenças, conferir offsets contra o manifesto), engenharia reversa de firmware (diff entre versões para achar mudanças no bootloader ou na tabela de strings), forense de arquivos (comparar cópia suspeita com uma boa conhecida para achar a fronteira da corrupção), e validar integridade de downloads com checksum divergente quando se quer ver *onde* os bytes divergem, não só saber que divergem. A comparação roda inteiramente no navegador via API FileReader e um walker DataView sobre typed arrays — seus arquivos não saem do dispositivo, nem para analytics.

Quanto é comparado e por que o teto são 64 KB?

Até 64 KB (65 536 bytes) do início de cada arquivo. O teto é decisão de UX, não limite técnico: renderizar mais de ~4 000 linhas hex numa tabela DOM começa a travar no mobile, e a maior parte da forense binária acontece nos primeiros KB — headers, magic numbers, assinaturas, blobs de certificado, metadados ELF/PE/Mach-O e pontos de entrada de patches vivem perto do começo. Para diffs profundos no final do arquivo (logs rolling, payloads criptografados anexados), use ferramenta desktop como HxD, 010 Editor, GHex (Linux), ou `cmp -l file_a file_b` no Unix, que stream o arquivo inteiro e reporta cada byte divergente em octal.

Como compara com `diff`, `cmp`, `git diff` e `vbindiff`?

`diff` é orientado a linha e assume UTF-8 ou ASCII de texto; em binários dá saída inútil. `cmp -l a b` é byte a byte mas produz lista plana (offset, byte_a, byte_b em octal) sem contexto — preciso mas difícil de ler. `git diff --binary` só codifica deltas, não mostra legível. `vbindiff` (Visual Binary Diff) é o análogo mais próximo e foi nossa inspiração: visão hex em dois painéis com rolagem sincronizada, coluna ASCII e diferenças realçadas. A diferença é que vbindiff roda no terminal; esta ferramenta roda no navegador, aceita arrastar e soltar e dispensa instalação. Para arquivos enormes ou checks de CI por script, prefira `cmp -l` em pipe para `wc -l` para contagem rápida de divergências ou `radiff2 -x` (diff hex do radare2) para saída estruturada.

Por que alguns bytes na coluna ASCII aparecem como pontos mesmo parecendo letras?

A coluna ASCII segue a faixa imprimível estrita 0x20–0x7E (espaço até til), convenção do `od -c` POSIX original e do `hexdump` do BSD. Qualquer byte fora dessa faixa é substituído por um único ponto para manter cada linha exatamente com 16 caracteres e alinhar colunas. Isso significa: tab (0x09), newline (0x0A), nulo (0x00), todos os bytes 0x80–0xFF (ASCII estendido e bytes de continuação UTF-8) e DEL (0x7F) aparecem como pontos. Se precisar ver texto UTF-8 dentro do binário (nomes em ZIP, strings em Mach-O, JSON dentro de blob embrulhado), copie o offset e abra o arquivo em um visualizador ciente de UTF-8 como o 010 Editor ou use `strings arquivo | grep` para dump rápido.

Quais são os magic numbers (assinaturas) mais comuns para procurar?

Os primeiros bytes de quase todo formato declaram o que ele é — saber esses números transforma o hex-diff em atividade ciente de formato. Magic numbers-chave (bytes do 0x00): PNG 89 50 4E 47 0D 0A 1A 0A, JPEG FF D8 FF (depois 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 (executáveis Linux) 7F 45 4C 46 ("\x7FELF"), Windows PE/EXE 4D 5A ("MZ") com ponteiro do header PE em 0x3C, Mach-O (macOS) FE ED FA CE/CF ou CE/CF FA ED FE, WAV 52 49 46 46 ("RIFF") depois "WAVE", MP4 começa com bytes de tamanho e 66 74 79 70 ("ftyp") em 0x04, SQLite 53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00. Se o seu hex começa com algo diferente, o arquivo está criptografado, comprimido ou corrompido.

Como identifico um patch binário (atualização DLL/EXE, delta de firmware) no diff hex?

Patches binários costumam concentrar mudanças em poucas regiões pequenas em vez de espalhar. Com 'Só diferenças' ativo, olhe o espaçamento dos offsets divergentes: um patch de software (fix de segurança, bug fix) tipicamente toca um a três trechos curtos de 4–64 bytes nas seções .text ou .rdata (PE Windows) ou segmentos .text e .rodata (ELF), correspondendo a patches de instrução ou atualização de constantes. Uma atualização de firmware cobre faixas maiores, frequentemente incluindo um checksum ou assinatura no final. Bump de versão em string aparece como mudança ASCII contígua (ex.: '1.0.4' para '1.0.5' num offset estável). Se o diff é uniforme — toda linha muda — os dois arquivos não estão relacionados ou um foi criptografado com chave diferente. Se o diff é idêntico no início e vira uniforme a partir de um offset, você pegou uma fronteira de corrupção de download ou truncamento.

Qual a diferença entre big-endian e little-endian no hex dump?

Endianness é a ordem em que valores multi-byte (inteiros de 16, 32, 64 bits) são armazenados. Little-endian (Intel x86, AMD64, ARM em modo padrão) guarda o byte menos significativo primeiro: o valor 32 bits 0x12345678 aparece no dump como 78 56 34 12. Big-endian (ordem de rede pela RFC 1700, PowerPC clássico, SPARC, m68k, a maioria dos headers de formato como PNG e JPEG, e headers IP/TCP no fio) guarda o mais significativo primeiro: o mesmo valor aparece como 12 34 56 78. Ao comparar dois binários compilados para arquiteturas diferentes, o que parece diff gigante pode ser só inversão de endianness. Check rápido: a maioria dos headers (PNG, ZIP, ELF, PDF) embute tamanho ou assinatura em endianness conhecida, então se seu hex começa com magic numbers na ordem certa, sua interpretação está correta.

Por que meus arquivos saem idênticos quando deveriam diferir (ou o contrário)?

Três pegadinhas comuns. Primeira, BOM ou quebras de linha — arquivos salvos como CRLF (Windows) versus LF (Unix) diferem em todo byte de quebra de linha; a ferramenta vai reportar fielmente muitos diffs pequenos onde o conteúdo lógico é idêntico. Segunda, timestamps embutidos — muitos formatos (ZIP, DOCX, PDF, executáveis com debug info, PNG com chunk de criação) embutem datas no binário, então dois arquivos compilados do mesmo fonte com minutos de diferença diferem nesses offsets. Terceira, compressão não-determinística — gzip, ZIP e PDF podem produzir bytes diferentes para a mesma entrada dependendo do nível de compressão, estado do dicionário ou versão da biblioteca; para comparar conteúdo lógico, descompacte os dois antes. Para descartar diffs triviais, use `dos2unix arquivo`, `strip-nondeterminism --type=zip` para timestamps, e descompacte antes de comparar.

Meus arquivos são enviados para servidor ou salvos em algum lugar?

Não. O diff roda inteiramente no navegador. Cada arquivo é lido via FileReader.readAsArrayBuffer num Uint8Array, percorrido byte a byte num loop apertado na main thread (cedendo via microtask a cada 4 KB para a UI continuar responsiva), e as linhas hex resultantes são renderizadas como DOM puro. Nenhum conteúdo, nome, offset ou estatística do diff é enviado ao nosso servidor, registrado em analytics ou persistido no localStorage. Abra a aba Rede do DevTools antes de clicar em Comparar — você verá zero requisições novas durante a comparação e zero requisições carregando conteúdo do arquivo durante o render. Fechar a aba expurga todos os buffers.