Detector de magic bytes MIME | A extensão mente, os primeiros bytes não

Um arquivo chamado config.exe que na verdade é um ZIP. Um .png que esconde um polyglot. Um anexo report.pdf cujos quatro primeiros bytes são 3C 3F 78 6D (<?xml). O nome do arquivo e o cabeçalho Content-Type mentem; os primeiros bytes de um arquivo (seu número mágico, ou file signature) não mentem. Esta ferramenta lê apenas os 64 primeiros bytes de um arquivo arrastado, tudo dentro do seu navegador, e os compara com mais de 40 assinaturas — PNG, JPEG, PDF, contêineres ZIP, MP4, ELF, PE, Mach-O, SQLite, WOFF — para reportar o MIME real.

💡 Sobre esta ferramenta

Quem já escreveu um endpoint de upload conhece a armadilha. A versão ingênua recusa payload.exe e aceita image.png. A versão menos ingênua confia no Content-Type do multipart — mas é o cliente que escolhe esse cabeçalho, e o atacante escolhe alegremente image/png. A versão séria lê os primeiros bytes no servidor e compara contra uma tabela de números mágicos, que é exatamente o que file(1) no Linux e python-magic em Python fazem por baixo do capô.

Esta ferramenta executa a mesma checagem, mas dentro do seu navegador. O arquivo arrastado é lido com FileReader.readAsArrayBuffer limitado a 64 bytes; nada é enviado, nada é hasheado, sem telemetria. Os bytes que casam ficam destacados em verde sobre o preview hex, e a regra de assinatura exata é mostrada — dá para copiar 89 50 4E 47 0D 0A 1A 0A direto para um fixture de teste ou uma regra Snort.

Contêineres ZIP recebem um cartão de alerta extra. PK\x03\x04 pode ser um .zip puro, mas também .docx, .xlsx, .pptx, .odt, .epub, .jar, .apk ou .kmz — todos compartilham o local-file header do ZIP. Se você não tem o arquivo em mãos e só tem os primeiros bytes copiados de um dump forense, existe o modo "colar hex": cola FF D8 FF E0 e recebe JPEG.

🧐 Perguntas frequentes

Q. Por que só 64 bytes? Quase todas as assinaturas modernas cabem nos primeiros 16 bytes. ISO 9660 é o outlier famoso — sua assinatura mora no offset 0x8001 — mas se você precisa inspecionar imagens ISO num navegador, existem ferramentas melhores. Limitar a 64 bytes também significa que uma imagem de disco de 1 GB é analisada em microsegundos, porque o resto nunca é carregado.

Q. O resultado diz "ZIP container" — como saber qual contêiner exatamente? Você não consegue, só com os primeiros bytes. .docx, .xlsx, .pptx, .odt, .epub, .jar, .apk, .kmz e o próprio .zip compartilham 50 4B 03 04. Eles se diferenciam pelas entradas internas do arquivo, não pelo cabeçalho. Para distinguir, descompacta e olha o primeiro listing: [Content_Types].xml é Office Open XML, META-INF/MANIFEST.MF é JAR, META-INF/CERT.SF é APK, e mimetype como primeira entrada é ODT/EPUB.

Q. Detecta arquivos polyglot? Não como uma verificação dedicada. O matcher percorre a tabela de assinaturas e retorna a primeira correspondência, então um arquivo simultaneamente válido como PDF e JAR será reportado como aquele que aparecer primeiro na tabela. O único caso explicitamente sinalizado é a ambiguidade de contêiner ZIP (docx vs xlsx vs jar vs apk vs epub vs odt), via cartão de aviso. Para análise polyglot séria, use binwalk ou file -k (keep going, não parar na primeira correspondência).

Q. Como funciona o aviso de extensão não combinando? A ferramenta extrai o sufixo do nome com a regex /\.([a-z0-9]{1,8})$/ e compara com a lista de extensões do formato detectado. Se invoice.pdf gera 50 4B 03 04 (ZIP), aparece um aviso vermelho .pdf vs .zip/.docx/.xlsx/.... Útil naquele momento em que um dev frontend te entrega "o PDF" e o curl responde application/zip.

Q. Detecta um arquivo de texto puro? Texto puro não tem assinatura fixa, então cai em "nenhuma assinatura conhecida bateu". XML/SVG (<?xml), RTF ({\rtf) e Postscript (%!) são detectados porque começam com literais ASCII concretos. Os BOMs UTF-8/UTF-16 não estão na tabela de assinaturas atual.

Q. O arquivo sai da minha máquina? Não. Os 64 primeiros bytes são lidos para um Uint8Array local, nunca são enviados pela rede, e o handle do arquivo é descartado assim que o resultado renderiza. Dá para confirmar no DevTools: nenhum fetch nem XHR é disparado durante a detecção. Seguro para analisar anexos suspeitos que você não pode subir para lugar nenhum.

📚 Curiosidades

A referência mais rica sobre assinaturas de arquivo continua sendo a tabela do Gary Kessler, que cataloga mais de 700 formatos e é a fonte que a maioria dos autores de regras YARA cita. A lista da Wikipedia "List of file signatures" se mantém atualizada com os contêineres mais novos — o frame magic 28 B5 2F FD do ZSTD, o ftyp avif (66 74 79 70 61 76 69 66) no offset 4 do AVIF, e os novos perfis EBML para MKV/WebM. A curiosidade mais citada continua sendo o Microsoft Compound Document D0 CF 11 E0 A1 B1 1A E1 — meio kilobyte de estrutura sob esse cabeçalho aparece toda vez que alguém abre um .doc ou .xls anterior a 2007.

Na comunidade brasileira de segurança, as trilhas de DFIR das edições da H2HC (Hackers to Hackers Conference) e os CTFs da Mente Binária sempre incluem desafios envolvendo arquivos com extensão maquiada e polyglots — e o primeiro passo de todo writeup costuma ser "rodei file -k e descobri que era ZIP, não PDF". O órgão regulador brasileiro CERT.br publica recomendações sobre validação de uploads que mencionam explicitamente o uso de magic bytes em vez de confiar em Content-Type, e ferramentas open-source desenvolvidas por brasileiros como o pev (PE viewer, de Fernando Mercês) trabalham exatamente na mesma camada de inspeção de cabeçalho para binários Windows. A lição que todos esses ambientes repetem é simples: a primeira linha de defesa contra um arquivo malformado é o que dizem seus primeiros bytes — não o que diz quem o enviou.