A cobertura não devia depender de um ciclo de publicação do fornecedor

Há um momento num exame de perícia digital que ninguém escreve no manual de procedimento. Um examinador abre uma extração, encontra uma aplicação que não reconhece e verifica se a sua ferramenta a suporta. Não suporta. Os dados estão ali, inteiramente presentes, numa base de dados de que se vê o nome do ficheiro. E a resposta a se podem ser lidos é: não neste trimestre.

Esse momento é em geral tratado como uma questão de suporte. Alguém abre um pedido. Talvez o fornecedor o acrescente a uma lista de espera, talvez uma versão chegue em seis meses, talvez a aplicação seja suficientemente popular na região para merecer o tempo de um engenheiro e talvez não seja. Entretanto, o caso tem um prazo de custódia a correr.

Isto não é uma questão de suporte. É uma propriedade estrutural da forma como o setor decidiu trabalhar, e, quando se vê assim, muita da frustração diária de um laboratório acaba por ter uma só causa.

A decisão é tomada noutro lado

Todas as ferramentas correntes de análise forense funcionam da mesma maneira. Alguém no fornecedor faz a engenharia inversa do formato de armazenamento de uma aplicação, escreve um parser para ele, testa-o e envia-o numa publicação. O examinador recebe o resultado desse trabalho como uma capacidade.

É engenharia genuinamente difícil, e as pessoas que a fazem são boas nisso. O problema não é a competência. O problema é que põe a decisão mais consequente de um exame, que dados podem sequer ser lidos, nas mãos de alguém que não sabe que o caso existe.

Essa pessoa faz um juízo comercial razoável. Olha para quantos clientes vão encontrar esta aplicação, para a estabilidade do formato, para quanto trabalho de engenharia vai exigir. Uma aplicação de mensagens com duzentos milhões de utilizadores vale obviamente o trabalho. Uma plataforma social regional com quatrocentos mil utilizadores, concentrada exatamente na região onde o seu grupo de criminalidade organizada opera, é um caso de negócio muito mais difícil. Da posição do fornecedor, recusar implementá-la é correto. Da sua posição, com a extração na mão, é o caso inteiro.

As versões são a metade maior do problema

A história da aplicação não suportada é a que se conta, mas fica aquém da questão. A falha mais comum é mais subtil: uma aplicação suportada cuja disposição de armazenamento mudou.

Uma aplicação atualiza-se. Reorganiza uma tabela, move um ficheiro, muda a forma como codifica uma data e hora. O parser foi escrito para a versão anterior e agora não devolve nada ou, pior, devolve algo plausível e errado. A ferramenta indica a aplicação como suportada, porque o é, e o examinador tem de reparar que o resultado é escasso.

Os ciclos de publicação das aplicações medem-se em semanas. Os ciclos de publicação das ferramentas forenses medem-se em meses. Essa diferença nunca se fecha, e não é culpa de ninguém. É aritmética.

O que custa, nos termos que importam

O custo não aparece em geral como um exame falhado. Aparece como redução de âmbito, em silêncio.

Um examinador com três semanas e quarenta lacres não passa dois dias a ler à mão uma base de dados SQLite desconhecida, com um editor hexadecimal aberto ao lado, mesmo podendo fazê-lo. Examina o que a ferramenta descodificou, escreve o relatório sobre isso e anota o resto como não analisado. É uma decisão profissional defensável. É também a forma como prova que existe, num dispositivo que o serviço já tem, num caso que já está aberto, acaba por nunca ser olhada.

Multiplique-se por um volume de casos e obtém-se o número com que os diretores de laboratório se preocupam de facto: a proporção de dados apreendidos que nunca é examinada. Não é uma falha de triagem. É uma falha de cobertura que foi reclassificada como triagem.

A alternativa é desconfortável, mas simples

Se o estrangulamento é que os parsers são escritos por um fornecedor, de antemão, para as aplicações que ele escolheu, então a correção é deixar de exigir que um humano num fornecedor os escreva de antemão.

Isto é agora tecnicamente viável de uma forma que não era há cinco anos. Reconhecer para que serve uma base de dados desconhecida, o que as suas tabelas contêm e como se mapeiam nos conceitos com que um investigador trabalha, conversas, contactos, localizações, é uma tarefa de raciocínio sobre caminhos de ficheiro, esquema e conteúdo em conjunto. É exatamente o tipo de tarefa em que os modelos generativos são invulgarmente bons e os classificadores não.

A objeção óbvia é a correta. Não se pode deixar um modelo decidir como a prova é interpretada e simplesmente confiar no resultado. Por isso, não se deixa. Gera-se o mapeamento, valida-se estruturalmente, executa-se contra uma amostra dos dados reais e mostra-se ao examinador uma pré-visualização de registos reais antes de qualquer coisa ser aplicada. Se o mapeamento compreendeu mal a fonte, isso vê-se de imediato, porque a pré-visualização está cheia de disparates. O examinador aceita-o, corrige-o num editor visual ou deita-o fora.

O que muda não é o padrão de prova. O examinador continua a verificar, e nada entra num relatório sem verificação. O que muda é quem tem de fazer o trabalho de compreender primeiro, e quando isso pode acontecer. Pode acontecer no dia em que o caso precisa, e não no trimestre que um fornecedor calendarizou.

Porque vale a pena dizê-lo em voz alta

Todos os laboratórios com quem falámos têm uma versão da mesma história, e cada um conta-a como se fosse uma irritação local. Não é local. É a mesma restrição em cada serviço, em cada país, e existe por causa de uma escolha de arquitetura que o setor inteiro fez cedo e nunca voltou a examinar.

Nomeá-la muda o que se pede. Um serviço que pensa ter um problema de suporte pede ao fornecedor publicações mais rápidas, um pedido que ninguém pode conceder. Um serviço que reconhece um problema estrutural faz uma pergunta diferente: o que seria preciso para a cobertura deixar de ser algo por que se espera.

É a pergunta para a qual o VERA foi construído, e é a razão por que preferimos discutir a tese a descrever o produto.