Capítulo 3 — Programação I
Mapa da aula
Aula 03 publicada. Mapa, exemplo, EX007.
flowchart TD
N0["3.1 Extensões versus conteúdo"]
N1["3.2 Por que isso importa"]
N2["Laboratório — bytes mágicos"]
N3["3.3 Lendo o resultado"]
N4["3.5 Estrutura do código"]
N5["3.6 Leitura segura"]
N6["3.7 Ampliando o script"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX007"]
Desenho lógico
flowchart LR
N0["3.1 Extensões versus conteúdo"]
N1["3.2 Por que isso importa"]
N2["Laboratório — bytes mágicos"]
N3["3.3 Lendo o resultado"]
N4["3.5 Estrutura do código"]
N5["3.6 Leitura segura"]
N6["3.7 Ampliando o script"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX007"]
[3.1 Extensões versus conteúdo]
|
v
[3.2 Por que isso importa]
|
v
[Laboratório — bytes mágicos]
|
v
[3.3 Lendo o resultado]
|
v
[3.5 Estrutura do código]
|
v
[3.6 Leitura segura]
|
v
[3.7 Ampliando o script]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX007]
Objetivos de aprendizagem
Você vai (1) escrever Python simples com dicionários e laços; (2) identificar tipos de arquivo pelos bytes de cabeçalho; (3) detectar divergências de extensão; (4) entender por que as extensões não são confiáveis.
3.1 Extensões versus conteúdo
A extensão de um arquivo faz parte do nome e pode ser qualquer coisa. O conteúdo muitas vezes começa com uma assinatura (os "bytes mágicos") que identifica o formato: arquivos PDF começam com %PDF, arquivos PNG com \x89PNG, formatos baseados em ZIP, como o DOCX, com PK\x03\x04, e executáveis do Windows com MZ. Renomear invoice.exe para invoice.pdf não muda nada dentro do arquivo; os dois primeiros bytes continuam sendo MZ. Muitos sistemas operacionais escolhem o ícone pela extensão, então o arquivo parece um documento para o usuário, embora seja um programa. Ler os primeiros bytes é, portanto, a primeira verificação que um perito aplica a qualquer arquivo suspeito.
3.2 Por que isso importa
Atacantes às vezes disfarçam executáveis de documentos. Os peritos comparam a extensão declarada com o cabeçalho real para sinalizar divergências e examiná-las de perto. Uma divergência não prova má-fé: um usuário pode ter renomeado um arquivo por engano, ou um aplicativo pode guardar dados com uma extensão incomum. É um motivo para olhar com mais atenção, registrado como achado e com os bytes do cabeçalho exibidos. Na ws-114, um arquivo divergente na pasta Downloads da vítima seria coerente com a hipótese de phishing e teria seu hash calculado e seria analisado num ambiente isolado.
Laboratório — bytes mágicos
"""Compare file extensions with leading magic bytes (synthetic files)."""
MAGIC = {b"%PDF": "pdf", b"\x89PNG": "png", b"PK\x03\x04": "zip-container", b"MZ": "windows-executable"}
files = {"report.pdf": b"%PDF-1.7 ...", "photo.png": b"\x89PNG\r\n...", "invoice.pdf": b"MZ\x90\x00...",
"notes.docx": b"PK\x03\x04..."}
for name, head in files.items():
kind = next((v for k, v in MAGIC.items() if head.startswith(k)), "unknown")
ext = name.rsplit(".", 1)[1]
ok = kind.startswith(ext) or (ext == "docx" and kind == "zip-container")
print(f"{name:12} header={kind:18} {'ok' if ok else 'MISMATCH'}")
Execute com python3 lab_magic.py. Saída verificada:
report.pdf header=pdf ok
photo.png header=png ok
invoice.pdf header=windows-executable MISMATCH
notes.docx header=zip-container ok
3.3 Lendo o resultado
report.pdf, photo.png e notes.docx têm cabeçalhos coerentes com suas extensões (o DOCX é um contêiner ZIP). invoice.pdf começa com MZ, a assinatura de um executável do Windows: MISMATCH (divergência). Esse é um forte motivo para examiná-lo mais a fundo — sem abri-lo nem executá-lo numa máquina de exame. Observe que o laboratório compara nomes com cabeçalhos mantidos na memória como sequências de bytes; ele não abre os arquivos com nenhum aplicativo. Só invoice.pdf é sinalizado, e o passo seguinte é calcular seu hash e registrá-lo nas anotações do caso antes de qualquer outra análise, para que cópias posteriores possam ser comparadas com o original.
3.4 Limites das assinaturas
As assinaturas identificam o formato, não a intenção. Alguns formatos não têm assinatura fixa; outros compartilham a mesma (muitos formatos de escritório são ZIPs). Ferramentas validadas usam conjuntos maiores de assinaturas e uma análise mais profunda da estrutura. Como os arquivos DOCX, XLSX e JAR começam todos com PK, um cabeçalho PK diz apenas que o arquivo é um contêiner ZIP; o perito precisa olhar o conteúdo listado lá dentro para distingui-los. Um arquivo com cabeçalho correto ainda pode conter macros ou scripts maliciosos. Alguns formatos, como o texto puro, não têm assinatura nenhuma. Por isso, o laudo de Leah diz o que a verificação de cabeçalho mostra e o que ela não consegue mostrar.
3.5 Estrutura do código
O laboratório usa um dicionário que associa assinaturas a tipos e um laço sobre os arquivos. Leah acrescenta um comentário explicando a fonte de cada assinatura, para que outros possam conferi-la. O dicionário mantém os dados separados da lógica: acrescentar um formato novo significa acrescentar uma entrada, não alterar o laço. O laço pega a primeira assinatura que coincide, então a ordem importa quando uma assinatura é prefixo de outra. O caso especial do docx mostra uma limitação: um projeto melhor associaria cada tipo de contêiner à lista de extensões que ele pode legitimamente ter. Leah anota isso como melhoria para a próxima versão.
3.6 Leitura segura
O script lê apenas os primeiros bytes, como dados; nunca executa nada. No laboratório, os bytes de cabeçalho estão escritos no próprio script, então nenhum arquivo real é tocado. Uma versão que leia arquivos reais deve abri-los em modo binário, ler um número fixo de bytes e fechá-los, sem nunca entregá-los a um programa que interprete seu conteúdo. Fazer essas verificações numa cópia, e não na evidência original, também preserva o hash do original e o mantém válido como evidência.
3.7 Ampliando o script
Leah acrescenta um teste com um arquivo mais curto que qualquer assinatura, confirmando que o script informa unknown (desconhecido) em vez de travar. Casos-limite como esse são onde os scripts falham no trabalho real: um arquivo vazio, um arquivo que não pode ser lido por falta de permissão, ou um nome de arquivo sem extensão. No laboratório, rsplit sobre um nome sem ponto devolve uma lista de um único item, e então tomar [1] lança um IndexError, o que merece um segundo teste. Cada teste é guardado junto com o script, para que uma alteração posterior não reintroduza o defeito.
Exemplo resolvido
No caso da ws-114, a equipe de Grace encontra um anexo de e-mail chamado "invoice.pdf". O script de Leah sinaliza seu cabeçalho MZ. O achado é registrado assim: "O arquivo chamado invoice.pdf tem cabeçalho de executável do Windows; ele não foi aberto." A análise é repassada ao laboratório isolado de malware.
Caso sintético. O anexo é inventado.
Erros e limites
Um cabeçalho coerente não prova que um arquivo é inofensivo; um PDF pode, ele próprio, conter conteúdo malicioso.
Exercícios
- EX007 — Divergência. Qual arquivo do laboratório divergiu, e o que isso sugere? Rubrica: 3 = invoice.pdf, cabeçalho MZ, executável disfarçado; 2 = só o arquivo; 1 = errado; 0 = nada.
- EX008 — Cabeçalho do DOCX. Por que notes.docx começa com PK? Rubrica: 3 = o DOCX é um contêiner ZIP; 2 = parcial; 1 = corrupção; 0 = nada.
- EX009 — Limites do cabeçalho. O que um cabeçalho correto não prova? Rubrica: 3 = que o arquivo é inofensivo; 2 = parcial; 1 = prova que é seguro; 0 = nada.
Síntese
Confie no conteúdo, não nos nomes; use as verificações de cabeçalho para triagem, nunca para inocentar arquivos.
Continue estudando — capítulo 03 de 40
← Capítulo 02 (rascunho) · Índice de capítulos do curso · Capítulo 04 (rascunho) →