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. Para esse caso de integridade, a ferramenta agora também calcula no seu navegador um checksum SHA-256 e CRC32 de cada arquivo inteiro, e deixa você colar um SHA-256 publicado para obter um veredito passa/falha por arquivo na hora — assim você confirma *que* diferem e *qual* cópia é a autêntica. A comparação roda inteiramente no navegador: o início de cada arquivo é lido com a API FileReader num Uint8Array e percorrido byte a byte, o hash usa a API nativa crypto.subtle.digest, e 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 para montar as linhas hex e renderizado como DOM puro; os checksums SHA-256 e CRC32 são calculados localmente com a API nativa crypto.subtle.digest e um CRC de tabela de busca em JavaScript puro. Nenhum conteúdo, nome, offset, checksum 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.

Tenho dois downloads do mesmo arquivo e um está corrompido — como confirmo qual cópia é a autêntica?

Use o checksum, não o diff de bytes. O diff hex diz *que* e *onde* duas cópias diferem, mas não diz qual é genuína — para isso você precisa comparar com o valor que o autor realmente publicou. A maioria dos projetos sérios publica um SHA-256 ao lado do firmware, ISO, instalador ou tarball de release (muitas vezes num arquivo SHASUMS, .sha256 ou de assinatura). Solte os dois downloads nesta ferramenta: ela calcula um SHA-256 do arquivo inteiro (o padrão de fato de integridade) e um CRC32 (comum para firmware e integridade de ZIP) para cada um. Cole o SHA-256 do autor no campo 'Soma de verificação esperada' e a ferramenta mostra um selo verde 'Corresponde' no arquivo autêntico e um vermelho 'Não corresponde' na cópia ruim. Se nenhum corresponder, ambos os downloads estão corrompidos ou adulterados — baixe novamente por uma conexão confiável. O SHA-256 é resistente a colisões, então uma correspondência é forte evidência criptográfica de que o arquivo é bit a bit o que o autor enviou; o CRC32 só detecta corrupção acidental (não é seguro contra adulteração deliberada), então priorize sempre o veredito do SHA-256 para autenticidade.