Capítulo 8 — Programação II
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX022.
flowchart TD
N0["8.1 Analisando registros"]
N1["8.2 Funções"]
N2["8.3 Saídas"]
N3["8.4 Casos-limite"]
N4["8.5 Não modifique as entradas"]
N5["8.6 Legibilidade"]
N6["8.7 Controle de versão"]
N7["8.8 Compartilhamento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX022"]
Desenho lógico
flowchart LR
N0["8.1 Analisando registros"]
N1["8.2 Funções"]
N2["8.3 Saídas"]
N3["8.4 Casos-limite"]
N4["8.5 Não modifique as entradas"]
N5["8.6 Legibilidade"]
N6["8.7 Controle de versão"]
N7["8.8 Compartilhamento"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX022"]
[8.1 Analisando registros]
|
v
[8.2 Funções]
|
v
[8.3 Saídas]
|
v
[8.4 Casos-limite]
|
v
[8.5 Não modifique as entradas]
|
v
[8.6 Legibilidade]
|
v
[8.7 Controle de versão]
|
v
[8.8 Compartilhamento]
|
v
[Exemplo resolvido] --> [Exercício EX022]
Objetivos de aprendizagem
Você vai (1) analisar registros de texto estruturados; (2) usar funções e tratamento de erros; (3) escrever saídas que outros possam verificar; (4) testar analisadores com casos-limite.
8.1 Analisando registros
Os registros são linhas com campos: horário, host, destino, método, caminho. O split() do Python dá conta de registros simples separados por espaço; o módulo csv trata corretamente os campos entre aspas. Um split simples quebra assim que um campo contém um espaço, como a string de user agent, então o analisador precisa seguir o formato real do registro. Leah consulta a documentação do proxy sobre a ordem dos campos e as regras de aspas antes de escrever o código. Depois testa o analisador com algumas linhas de aparência realista cujos campos corretos ela escreveu à mão.
8.2 Funções
Leah escreve parse_line(line), que devolve um dicionário, e load(path), que a aplica a cada linha. As linhas malformadas são contadas e relatadas, não descartadas em silêncio. Dividir o trabalho em duas funções permite testar parse_line com linhas isoladas, enquanto load cuida dos arquivos. Contar as linhas malformadas importa porque descartá-las em silêncio poderia esconder justamente os eventos causados por um atacante, como uma requisição com um caminho incomum. O exemplo resolvido mostra o resultado: três linhas malformadas em 2.418, cada uma listada pelo número.
8.3 Saídas
Os resultados são gravados em CSV com uma linha de cabeçalho, mais um pequeno arquivo de resumo que registra o nome do arquivo de entrada, seu SHA-256, a contagem de linhas, a contagem de malformadas e a versão do script. Qualquer pessoa pode rodar o script de novo e comparar. O hash da entrada prova qual registro foi processado. Se alguém depois receber outra cópia do registro do proxy, comparar os hashes mostra na hora se é o mesmo arquivo. Registrar a versão do script liga a saída ao código que a produziu, de modo que um defeito descoberto depois possa ser rastreado até os laudos que afetou.
8.4 Casos-limite
Linhas vazias, espaços extras, campos ausentes, caracteres não ASCII nos caminhos e horários que atravessam a meia-noite. Cada um ganha um teste. Horários que atravessam a meia-noite são uma armadilha comum: um registro que guarda só os horários, com a data no nome do arquivo, vai ordenar 00:01 antes de 23:59, a menos que o analisador acrescente a data. Caracteres não ASCII podem quebrar a decodificação se o arquivo for lido com a codificação errada. Leah escreve um teste para cada caso, com uma linha curta inventada, para que cada falha aponte para uma única causa.
8.5 Não modifique as entradas
O script abre os registros somente para leitura e grava as saídas em outro lugar. Mesmo um script que só lê pode alterar, em alguns sistemas, o horário do último acesso de um arquivo, por isso Leah trabalha com cópias cujos hashes coincidem com os dos originais. A saída vai para uma pasta separada, nomeada pela execução. Se um script algum dia gravasse na própria entrada, o hash registrado na coleta deixaria de coincidir, e a integridade da evidência ficaria em dúvida. O script de Leah se recusa a rodar se a pasta de saída for a mesma da entrada, uma verificação simples que evita um erro caro.
8.6 Legibilidade
Nomes como dest_host são melhores que d; uma docstring curta diz o que cada função devolve. Código legível ajuda os revisores, que precisam entender o que um script fez antes de confiar em seus resultados. Uma variável chamada dest_host pode ser conferida com a documentação do registro, enquanto d não diz nada ao leitor. As docstrings de Leah informam a entrada, a saída e o que acontece com as linhas malformadas, o que corresponde ao arquivo de resumo que o script grava e facilita comparar os dois. Nomes claros também ajudam a própria Leah quando ela volta ao script, meses depois, para o projeto final.
8.7 Controle de versão
O script fica num repositório; o laudo cita o commit usado. Citar o commit significa que um revisor pode obter exatamente o código que produziu os achados, mesmo que o script tenha mudado desde então. Quando Leah corrigiu a falha do caminho ausente, a correção virou um novo commit, e o laudo registra qual foi usado. As saídas anteriores continuam rastreáveis até a versão mais antiga, para que ninguém confunda os resultados das duas. Se a correção tivesse alterado alguma contagem, o laudo diria quais números foram recalculados e com qual commit.
8.8 Compartilhamento
Os scripts usados nos achados são guardados com o caso, para que os revisores possam inspecioná-los. Um revisor que não pode inspecionar o script precisa confiar cegamente em sua saída, o que anula o propósito da revisão. Manter juntos, na pasta do caso, o script, seus testes, os hashes das entradas e os arquivos de resumo permite que outro perito rode a análise de novo e obtenha os mesmos números. Em Harrowgate, a pasta do caso fica num compartilhamento restrito, com os acessos registrados pelo escritório de Grace Lin e guardados junto com o caso.
Codificações de caracteres
Os registros podem conter caminhos em UTF-8, e um analisador que pressupõe ASCII pode travar ou corrompê-los. Leah abre os arquivos com uma codificação explícita e uma política de erros que registra os caracteres substituídos, para que nomes incomuns continuem visíveis em vez de desaparecer. Seus testes incluem um caminho sintético com caracteres acentuados.
Exemplo resolvido
O analisador de Leah trava numa linha do registro do proxy sem o campo de caminho. Ela altera parse_line para devolver None nas linhas malformadas, conta-as, e o resumo informa "2.418 linhas analisadas, 3 malformadas (linhas 77, 1.204 e 2.001)". O Dr Ferreira observa que listar os números das linhas permite que um revisor inspecione exatamente o que foi pulado.
Caso sintético. O registro é inventado.
Erros e limites
Um analisador embute pressupostos sobre o formato; se o formato mudar, os resultados podem ficar errados em silêncio — teste com amostras de cada fonte.
Exercícios
- EX022 — Linhas malformadas. Como as linhas malformadas devem ser tratadas? Rubrica: 3 = contadas, números das linhas relatados, não descartadas em silêncio; 2 = parcial; 1 = travar/ignorar; 0 = nada.
- EX023 — Arquivo de resumo. O que o arquivo de resumo registra? Rubrica: 3 = nome da entrada, hash, contagem de linhas, contagem de malformadas, versão do script; 2 = três; 1 = um; 0 = nada.
- EX024 — Caso da meia-noite. Por que testar registros que atravessam a meia-noite? Rubrica: 3 = campos só de horário podem ser ordenados errado sem as datas; 2 = parcial; 1 = motivo vago; 0 = nada.
Síntese
Analisadores que relatam o que pularam e registram o que leram tornam a análise de registros revisável.
Continue estudando — capítulo 08 de 40
← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →