O que uma extração Full File System contém de facto, e porque a maior parte nunca é examinada

Pergunte-se a alguém de fora do domínio o que está num telefone apreendido e dirá mensagens, fotografias e contactos. Pergunte-se a um examinador e ele hesita, porque a resposta honesta é que ninguém sabe inteiramente, e descobrir é o trabalho.

Uma extração Full File System é uma cópia do sistema de ficheiros do dispositivo tal como o sistema operativo o vê. Não uma exportação selecionada, não o subconjunto que uma aplicação aceita entregar através de uma interface de cópia de segurança. A árvore inteira.

Vale a pena percorrer o que está de facto lá, porque a forma dos dados explica quase tudo sobre para onde vai o tempo de exame.

Quatro camadas, por ordem decrescente de atenção

A camada em que toda a gente pensa. Mensagens, registos de chamadas, contactos, o rolo da câmara. É genuinamente importante, é aquilo em que o caso em geral assenta, e é uma pequena fração da extração em volume. É também a parte que todas as ferramentas descodificam bem, porque é a parte para a qual todas as ferramentas foram construídas primeiro.

Armazenamento de aplicações. Cada aplicação instalada guarda o seu próprio estado: bases de dados de mensagens e dos seus metadados, caches de fotografias de perfil, rascunhos, histórico de notificações, histórico de pesquisa, rasto de localizações, estado de sincronização. Um telefone com sessenta aplicações tem sessenta destes, em sessenta disposições, em vários formatos, alguns com versão e outros sem.

Esta camada é onde a prova interessante está cada vez mais, e é onde a cobertura é mais desigual. A ferramenta de um examinador descodifica o armazenamento das aplicações que o fornecedor implementou, e o resto é uma listagem de diretório.

Traços de sistema. O sistema operativo regista uma quantidade notável sobre si próprio no curso ordinário do trabalho: que aplicações correram e quando, a que redes o dispositivo se juntou, quando foi ligado, que contas estão configuradas, o que foi aberto recentemente. Nada disto foi concebido como prova. Muito disto é muito boa prova, porque é difícil de selecionar e corrobora ou contradiz o relato humano.

Sedimento. Caches de miniaturas, ficheiros temporários, diários de escrita antecipada que ainda guardam linhas apagadas da base de dados principal, espaço não atribuído com os restos de registos que foram removidos. Esta é a camada onde o conteúdo apagado é recuperado, e é também onde o examinador tem de ter mais cuidado, porque uma linha recuperada e uma linha viva têm peso probatório diferente e nunca devem ser apresentadas como se fossem a mesma.

O problema de volume não é realmente um problema de volume

Um telefone de topo moderno produz uma extração nas dezenas ou nas poucas centenas de gigabytes. Mas o armazenamento é barato e a leitura é rápida, por isso o tamanho em bruto não é a restrição.

A restrição é que o conteúdo útil está espalhado por um grande número de formatos, a maior parte sem documentação, vários dos quais mudam entre publicações da aplicação que os escreveu, e nenhum dos quais foi concebido para ser lido por alguém que não a própria aplicação.

É por isso que a pergunta que tem sentido não é o tamanho de uma extração. É que proporção dela alguma ferramenta tem uma opinião. Tudo o resto está presente, legível em princípio e inutilizável na prática.

Para onde vão as horas

Observe-se um examinador experiente a percorrer uma extração e a distribuição do tempo não é o que alguém de fora espera.

Muito pouco dele é ler mensagens. Uma grande parte é perceber que partes da extração vale a pena ler, e depois pôr essas partes num estado em que as ler é possível. Abrir uma base de dados desconhecida, perceber o que as suas tabelas significam, descobrir que as datas e horas estão guardadas numa época invulgar, perceber que o corpo da mensagem está numa tabela e o participante noutra, sem junção óbvia. Esse é o trabalho.

É também trabalho qualificado que não produz nada duradouro. A compreensão que um examinador constrói sobre a disposição de armazenamento de uma aplicação numa terça-feira vive na cabeça dele, ou no melhor dos casos num ficheiro de notas pessoal, e tem de ser reconstruída pela pessoa seguinte que encontra a mesma aplicação noutro serviço seis meses depois.

A parte que nunca é examinada

Todos os laboratórios têm uma regra informal sobre até onde ir. Raramente está escrita e em geral é sensata: examinar o que a ferramenta descodificou, examinar tudo o que o investigador pediu em concreto e anotar o resto como não analisado.

O resultado é uma redução de âmbito consistente e invisível. Não uma falha de diligência, e não algo que uma revisão do caso assinalaria, porque o relatório descreve com exatidão o que foi examinado. Mas o efeito ao longo de um volume de casos é que uma grande fração dos dados apreendidos nunca é olhada por ninguém, e a fração é maior exatamente nas aplicações que um fornecedor achou comercialmente desinteressantes.

O que mudaria o quadro

Três coisas moveriam isto, por ordem de quanta diferença fazem.

A primeira é cobertura que não depende do calendário de publicações de outra pessoa. Se uma aplicação desconhecida pode ser estruturada no dia em que o caso precisa, a regra informal de âmbito deixa de retirar as mesmas categorias de prova de cada vez.

A segunda é pesquisa que funciona pelo sentido e não só por cadeias. A maior parte de uma extração é ilegível porque ninguém tem uma razão para a abrir. Uma pergunta feita ao lacre inteiro de uma vez encontra a razão.

A terceira é verificação suficientemente barata para ser de facto feita. Um examinador que tem de passar uma tarde a confirmar de onde veio uma constatação confirma menos constatações. Um que o pode fazer num clique confirma-as todas, que é o que o tribunal tem o direito de esperar.

Esta última importa mais do que parece. Tornar a revisão da prova mais rápida só é útil se não a tornar também mais superficial, e a única defesa contra isso é tornar a verificação tão barata que saltá-la não poupa nada.