OpenCyber Academy
Engenharia · Capítulo 41 · Português
Código do curso: OCA-132Capítulo 41: OCA-132-C041

Capítulo 41 — Perícia digital e análise de *malware*: otimização do sistema

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 41 publicada. Mapa, exemplo, EX121.

flowchart TD
  N0["41.1 Primeiro, o perfil"]
  N1["41.2 A correção"]
  N2["41.3 Verificação da integridade"]
  N3["41.4 O que não otimizar"]
  N4["41.5 Paralelismo"]
  N5["41.6 Memória"]
  N6["41.7 Medindo os ganhos"]
  N7["41.8 Experiência do usuário"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX121"]

Desenho lógico

flowchart LR
  N0["41.1 Primeiro, o perfil"]
  N1["41.2 A correção"]
  N2["41.3 Verificação da integridade"]
  N3["41.4 O que não otimizar"]
  N4["41.5 Paralelismo"]
  N5["41.6 Memória"]
  N6["41.7 Medindo os ganhos"]
  N7["41.8 Experiência do usuário"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]

[41.1 Primeiro, o perfil]
    |
    v
[41.2 A correção]
    |
    v
[41.3 Verificação da integridade]
    |
    v
[41.4 O que não otimizar]
    |
    v
[41.5 Paralelismo]
    |
    v
[41.6 Memória]
    |
    v
[41.7 Medindo os ganhos]
    |
    v
[41.8 Experiência do usuário]
    |
    v
[Exemplo resolvido] --> [Exercício EX121]

Objetivos de aprendizagem

Você vai (1) otimizar o EvidenceDesk sem enfraquecer a integridade; (2) medir o perfil de execução antes de otimizar; (3) medir os ganhos; (4) registrar as concessões.

41.1 Primeiro, o perfil

Os usuários reclamam que a exportação é lenta em casos grandes. Priya mede o perfil de execução: 80% do tempo de exportação vai para recalcular a cadeia inteira a cada página do PDF. Um palpite teria apontado para a renderização do PDF. Um profiler registra quanto tempo cada função consome durante uma execução real. Sem ele, o instinto de Priya era que a renderização do PDF estava lenta, e ela poderia ter passado uma semana trocando o renderizador por pouco ganho. O perfil de uma exportação com 5.000 eventos mostra a função da cadeia chamada uma vez por página, percorrendo a cada vez todo o histórico desde o início.

41.2 A correção

Calcular a cadeia uma vez por exportação e reutilizá-la. O tempo de exportação de um caso sintético com 5.000 eventos cai de 90 segundos para 6. A mudança é pequena: calcular a cadeia no início da exportação, guardar os resultados numa lista e passá-los a cada página. Ganhos de quinze vezes com uma única mudança são comuns quando a causa é trabalho repetido, e não código lento. Priya guarda a saída do profiler de antes e de depois no registro da mudança como evidência da afirmação. A saída das páginas não muda.

41.3 Verificação da integridade

A otimização não pode mudar as saídas. Priya compara as exportações de antes e de depois para vinte casos sintéticos: bytes idênticos, exceto o carimbo de data e hora da geração. A comparação byte a byte é um teste rigoroso: qualquer mudança de ordenação, formatação de números ou valor de hash apareceria. O carimbo de geração é a única diferença esperada, então a comparação mascara apenas esse campo. Vinte casos cobrem históricos pequenos, grandes, corrigidos e vazios. Se algum byte diferisse, a otimização seria revertida até que a diferença fosse explicada. O script de comparação entra no conjunto de testes.

41.4 O que não otimizar

Pular as leituras de verificação, ou guardar em cache resultados de hash entre sessões sem reler os dados, seria mais rápido, mas eliminaria a garantia de que as imagens armazenadas estão íntegras. Essas ideias são rejeitadas e documentadas. Guardar um hash em cache é tentador porque as imagens raramente mudam, mas "raramente" é exatamente o caso que a verificação existe para apanhar: corrupção silenciosa, degradação da mídia ou adulteração. Um valor em cache continuaria relatando o hash antigo e correto depois que os dados tivessem mudado. Documentar as ideias rejeitadas impede que um desenvolvedor futuro as acrescente de boa-fé.

41.5 Paralelismo

Verificar várias imagens ao mesmo tempo usa vários discos em paralelo, com o limite dado pela vazão do armazenamento medida antes. Duas imagens em discos separados podem ser verificadas ao mesmo tempo com quase o dobro da vazão, mas duas no mesmo disco disputam a cabeça de leitura e podem ser mais lentas juntas do que uma depois da outra. Por isso o EvidenceDesk agenda as tarefas por dispositivo de armazenamento. O limite vem das medições de gargalo, e Priya o confere de novo sempre que o hardware de armazenamento muda. As tarefas no mesmo disco esperam numa fila única.

41.6 Memória

As leituras em fluxo mantêm o uso de memória constante, qualquer que seja o tamanho da imagem. Ler em fluxo significa ler um bloco de tamanho fixo, atualizar o hash e descartar o bloco antes de ler o seguinte. Um buffer de 64 KiB usa a mesma memória para uma imagem de 1 GB e para uma de 8 TB. Carregar uma imagem inteira na memória falharia de cara em discos grandes. Um teste calcula o hash de um arquivo maior que a RAM da máquina de testes para confirmar que o projeto se sustenta. A verificação de uma imagem grande nunca trava a interface por pressão de memória.

41.7 Medindo os ganhos

Relate o antes e o depois com as mesmas entradas e o mesmo hardware, e o número de execuções. Trocar de hardware entre as execuções poderia fazer uma versão mais lenta parecer mais rápida. Repetir as execuções revela a variação: se cinco execuções da versão antiga vão de 85 a 95 segundos, uma única execução de 88 segundos de uma versão nova não mostra nada. Priya relata a mediana e a amplitude de cada uma, para que os leitores possam julgar se um ganho é real. Ela também declara o tamanho do caso usado, porque um ganho com 5.000 eventos pode não se manter com 50 ou com 500.000.

41.8 Experiência do usuário

Indicadores de progresso nas verificações longas reduzem a tentação de cancelar e pular. Uma verificação de doze horas sem nenhum retorno parece travada, e a equipe sob pressão pode cancelá-la e marcar o item como conferido de memória. Uma barra de progresso mostrando os bytes processados e o tempo restante estimado, mais uma linha de log a cada poucos minutos, deixa claro que a tarefa está andando. Uma tarefa cancelada é registrada como cancelada, nunca como aprovada. Os peritos informados sobre o tempo restante também planejam outros trabalhos em torno da tarefa, em vez de esperar diante da tela.

Conjunto de benchmarks

Priya mantém um pequeno conjunto de benchmarks — exportações de três tamanhos de caso sintético e a verificação de uma imagem fixa — que roda antes de cada versão na estação de trabalho de referência. Uma lentidão de mais de 20% bloqueia a liberação até ser explicada, o que apanha cedo as regressões acidentais e mantém honestas as afirmações de desempenho.

Exemplo resolvido

Uma proposta de guardar o último resultado de verificação de cada imagem e pular a reverificação se a data de modificação do arquivo não mudou é rejeitada: as datas de modificação podem ser alteradas, e a finalidade da verificação é ler os dados. Priya registra a proposta, o motivo e a decisão.

Caso sintético. Os números do perfil de execução são inventados.

Erros e limites

As otimizações acrescentam complexidade; mantenha só aquelas cujo benefício foi medido e cujo risco é compreendido.

Exercícios

Síntese

Meça o perfil, otimize o que importa, prove que as saídas não mudaram e nunca abra mão da garantia de integridade.

Continue estudando — capítulo 41 de 50

← Capítulo 40 (rascunho) · Índice de capítulos do curso · Capítulo 42 (rascunho) →

Respostas comentadas

EX121. Cerca de 80% do tempo de exportação ia para recalcular toda a cadeia de custódia a cada página do PDF.

EX122. Vinte exportações de casos sintéticos, de antes e de depois, foram comparadas byte a byte; só o carimbo de data e hora da geração diferiu.

EX123. As datas de modificação podem ser alteradas, e a verificação existe justamente para ler e conferir os próprios dados.