Hash na prova digital: o que ainda precisa ser auditado?

Arquivos disponibilizados no processo, valores hash conferidos e um relatório formal podem transmitir a impressão de que a prova digital está tecnicamente encerrada. Não está necessariamente. O hash na prova digital confirma uma correspondência objetiva entre determinados bytes, um algoritmo e um momento de cálculo; ele não demonstra, sozinho, de onde veio o arquivo, se o conjunto é completo, quem o produziu ou qual interpretação deve ser extraída dele.

A auditoria pós-hash começa justamente nesse ponto. É preciso identificar o objeto submetido ao cálculo, reconstruir sua aquisição, compreender a extração, verificar seleções e limitações, preservar o contexto e avaliar se outro profissional consegue examinar ou reproduzir as etapas relevantes. Essa distinção é especialmente importante para a defesa: uma limitação técnica pode sustentar questionamentos e pedidos de esclarecimento, mas não equivale automaticamente a adulteração ou nulidade.

O que o hash na prova digital comprova?

Um valor hash é calculado a partir de um conjunto específico de bytes. Quando o valor calculado sobre um objeto corresponde ao valor de referência, a conclusão imediata é que os objetos comparados apresentavam a mesma sequência de bytes segundo o algoritmo indicado no momento da verificação. Essa é uma constatação relevante para a integridade relativa daquele objeto.

O alcance, porém, é delimitado por quatro elementos: o objeto, o algoritmo, o momento e o procedimento de cálculo. Um SHA-256 de um arquivo exportado demonstra a correspondência daquela exportação. Não demonstra, por si só, que a exportação contém tudo o que existia na fonte original ou que o conteúdo foi corretamente atribuído a uma pessoa.

O glossário do NIST sobre hash trata o valor hash como elemento utilizado para verificar a integridade de evidências digitais. A orientação do SWGDE sobre integridade de dados em computação forense também ajuda a separar a verificação de alterações posteriores das etapas anteriores de coleta, aquisição e preservação.

Em termos práticos, o hash responde melhor à pergunta “este objeto corresponde ao valor registrado?” do que às perguntas “este é o objeto correto?”, “ele representa todo o material?”, “quem o produziu?” e “a interpretação apresentada é válida?”.

O objeto do hash define o alcance da validação

Antes de validar o resultado, é necessário saber exatamente o que foi hasheado. A expressão “o arquivo foi hasheado” pode ocultar situações tecnicamente muito diferentes:

• um arquivo individual extraído do dispositivo;
• uma exportação produzida por um aplicativo ou provedor;
• um contêiner com diversos arquivos;
• uma imagem forense ou cópia de armazenamento;
• um relatório gerado por uma ferramenta;
• um conjunto selecionado para disponibilização no processo.

Cada objeto representa uma camada diferente do percurso probatório. Uma imagem forense pode conter estruturas, áreas e artefatos que não aparecem em uma exportação. Um relatório pode ser apenas uma interpretação derivada de dados processados. Uma exportação de conversa pode preservar o texto visível, mas não necessariamente todos os metadados, anexos, mensagens excluídas ou registros de sincronização.

Por isso, a primeira pergunta de auditoria deve ser: qual era o objeto exato no momento do cálculo? Também importa saber seu formato, tamanho, origem, localização, identificação, algoritmo utilizado, data, horário, ambiente e responsável pelo cálculo. Se o valor foi calculado sobre um pacote posteriormente extraído ou convertido, a análise precisa distinguir o objeto originário do resultado derivado.

Quando a discussão envolve celular, é útil separar as diferenças entre UFDR, imagem forense e dados brutos. Esses formatos não são equivalentes e não oferecem necessariamente as mesmas condições para reprocessamento, conferência de completude ou recuperação de artefatos.

Integridade não é origem, autenticidade, autoria ou completude

A integridade de um arquivo significa, nesse contexto, que o objeto comparado permaneceu correspondente ao valor registrado. Ela não se confunde com a origem do arquivo, sua autenticidade em sentido amplo, sua autoria, sua completude ou a correção da interpretação.

A seguinte matriz ajuda a evitar conclusões maiores do que os dados permitem:

Essa distinção não reduz a importância do hash. Ela impede que uma propriedade específica seja transformada em um selo geral de confiabilidade. Mesmo quando se discute MD5 ou SHA-1, é necessário considerar a finalidade concreta. Não é tecnicamente adequado afirmar que esses algoritmos são sempre inválidos ou que sua presença confirma, por si só, a confiabilidade global da prova. A posição do SWGDE sobre MD5 e SHA-1 trata justamente da necessidade de relacionar o algoritmo ao uso pretendido e ao contexto forense.

Como auditar a coleta e a aquisição do vestígio

A análise pós-hash precisa voltar no tempo. O arquivo disponibilizado foi produzido a partir de qual dispositivo, conta, servidor ou mídia? Como a fonte foi identificada? Quem realizou a coleta? Em que data e condições? Houve preservação do material original? O método foi uma imagem integral, uma aquisição lógica, uma coleta seletiva ou uma exportação feita pelo próprio aplicativo?

Na prática, a diferença entre esses métodos pode alterar o universo de dados examinados. Uma aquisição lógica pode não conter áreas ou categorias acessíveis apenas por outros procedimentos. Uma exportação pode depender das opções selecionadas pelo operador ou pelo serviço. Uma imagem pode preservar mais estruturas do armazenamento, mas ainda exige documentação sobre sua criação, verificação e processamento.

A auditoria deve procurar, quando aplicável:

• identificação do dispositivo ou da fonte;
• registros de apreensão, recebimento e transferência;
• método de aquisição e preservação;
• uso de bloqueio de escrita, quando pertinente;
• operador, equipamento e datas;
• valores hash calculados durante as etapas;
• relatórios de erro ou interrupção;
• identificação dos materiais originais e derivados.

A auditoria da cadeia de custódia da prova digital complementa essa reconstrução. O ponto não é presumir que uma lacuna documental invalide tudo, mas verificar qual etapa deixou de ser explicada e se isso limita a confiabilidade ou a possibilidade de conferência do resultado.

Ferramenta, versão, parâmetros, relatórios e logs

O resultado de uma extração não existe isoladamente. Ele depende da ferramenta, da versão utilizada, dos parâmetros, dos filtros, dos módulos de decodificação e das decisões tomadas durante o processamento. Uma mesma categoria de dado pode ser tratada de maneira diferente por versões distintas ou por configurações diferentes.

Por isso, um laudo ou uma pasta de arquivos deve ser acompanhado, sempre que possível, das informações que permitem entender como o resultado foi produzido. Entre elas estão o nome e a versão do software, os parâmetros empregados, os filtros aplicados, os relatórios gerados, os logs de execução, os registros de erro e a indicação dos artefatos não processados ou não interpretados.

Isso não significa que uma ferramenta forense seja necessariamente insegura. A questão é mais precisa: quais capacidades foram efetivamente utilizadas no procedimento concreto e quais limitações podem afetar aquele resultado? O Computer Forensics Tool Testing Program, do NIST, oferece metodologia e resultados de testes para avaliar comportamentos e capacidades de ferramentas, mas um teste não transforma automaticamente qualquer uso posterior em resultado universalmente garantido.

Na auditoria, também pode ser pertinente comparar saídas de ferramentas diferentes ou reproduzir uma etapa em ambiente controlado. Essa verificação não substitui a análise do caso, mas pode revelar diferenças de parsing, conversão, ordenação temporal ou tratamento de artefatos.

Os arquivos disponibilizados representam todo o conjunto?

A existência de arquivos no processo não demonstra que eles correspondem à extração integral. Eles podem ser apenas uma seleção, uma exportação, um relatório ou os resultados considerados relevantes por quem realizou o exame. A pergunta sobre completude é própria e não é respondida pela simples conferência do hash.

Para investigá-la, é necessário procurar inventários, listas de arquivos, relatórios de extração, filtros, categorias processadas, registros de itens inacessíveis, mensagens de erro e informações sobre dados descartados ou não decodificados. Também importa saber se o material disponibilizado contém os dados originários ou somente resultados derivados.

Em uma conversa, por exemplo, a seleção de poucas mensagens pode eliminar respostas anteriores, anexos, edições, identificação de participantes ou informações de grupo. O trecho exibido pode ser íntegro como arquivo, mas ainda assim insuficiente para compreender o evento completo.

Uma pergunta útil para a defesa é: quais dados existiam na fonte e quais dados foram efetivamente entregues, processados, selecionados e apresentados? A resposta exige documentação comparável entre essas camadas, não apenas um valor hash no final.

Metadados, timestamps e contexto dos dados

Datas e horários também precisam ser tratados como dados técnicos, não como fatos autoexplicativos. Um timestamp pode vir do sistema de arquivos, do aplicativo, do dispositivo, do servidor ou de uma conversão feita pela ferramenta. Cada fonte pode utilizar fuso, formato e referência temporal próprios.

Diferenças entre horários não provam imediatamente adulteração. Elas podem decorrer de fuso horário, sincronização incompleta, relógio incorreto, clock drift, política do aplicativo ou conversão durante a exportação. A análise adequada identifica a origem de cada registro, normaliza os horários e correlaciona fontes independentes.

O contexto deve ser preservado com o mesmo cuidado. Mensagens, conversas e anexos precisam ser examinados considerando respostas, edições, exclusões, participantes, grupos, arquivos associados e eventuais sincronizações. Um conteúdo íntegro e corretamente extraído pode ser interpretado de forma inadequada se apresentado fora da sequência ou sem os elementos que o complementam.

Em ambientes de nuvem, a análise pode envolver logs de autenticação, IPs, tokens, sessões, registros de API, metadados e horários de servidor. O relatório do NIST sobre desafios forenses na computação em nuvem evidencia que a localização distribuída dos dados, a multiplicidade de usuários e a dependência de provedores tornam a aquisição e a atribuição mais complexas. Ainda assim, a existência de um IP ou de um registro de acesso não prova automaticamente quem operou a conta.

Atribuição: o arquivo pertence a qual dispositivo, conta ou usuário?

Encontrar um arquivo em um dispositivo ou em uma conta é uma constatação diferente de demonstrar quem o criou, enviou, editou ou controlou aquele ambiente. O hash pode confirmar que o arquivo analisado corresponde ao valor registrado, mas não estabelece, sozinho, a autoria humana.

A atribuição exige correlação com outros elementos: identificadores do dispositivo, credenciais, registros de autenticação, sessões, logs do provedor, localização, artefatos locais, padrões de uso e contexto temporal. Mesmo esses elementos precisam ser interpretados em conjunto, porque contas podem ser compartilhadas, dispositivos podem ser acessados por mais de uma pessoa e sessões podem permanecer autenticadas.

Essa distinção é central em mensagens. O que uma extração forense de celular demonstra sobre uma mensagem depende não apenas da presença do conteúdo, mas também da estrutura do aplicativo, dos registros associados e de elementos corroborantes sobre origem, envio, recebimento e contexto.

É possível reproduzir ou verificar a conclusão?

A reprodutibilidade do laudo digital não decorre da existência de um relatório final. Outro profissional precisa ter acesso suficiente aos insumos e às condições que permitam repetir ou testar as etapas relevantes. Dependendo do caso, isso inclui imagem ou dados originários, arquivos derivados, valores hash, versões de ferramentas, parâmetros, filtros, logs, relatórios e ambiente de teste.

Reprodução e verificação independente não significam necessariamente executar todo o procedimento de forma idêntica. Às vezes, é possível testar uma conclusão específica, confirmar a leitura de um artefato, comparar resultados ou verificar se determinado dado aparece na fonte indicada. O importante é que a conclusão não dependa de uma caixa-preta documentalmente inacessível.

A ISO/IEC 27042:2015, sobre análise e interpretação de evidências digitais, é uma referência para discutir continuidade, validade, reprodutibilidade, repetibilidade e documentação suficiente para escrutínio independente. A ISO/IEC 27037:2012, sobre identificação, coleta, aquisição e preservação, orienta a análise do percurso inicial do vestígio.

Quando faltam dados brutos, logs, parâmetros ou registros de aquisição, a conclusão correta é reconhecer a limitação e avaliar seu possível impacto. Não se deve saltar diretamente dessa ausência para uma afirmação de fraude ou nulidade.

Como transformar a auditoria pós-hash em contraditório técnico

A auditoria se torna útil quando converte dúvidas genéricas em perguntas verificáveis. Em vez de afirmar que “a prova é inválida”, o profissional pode formular quesitos como:

• Qual foi o objeto exato submetido ao hash e qual algoritmo foi utilizado?
• Em que data, horário, ambiente e condições o valor foi calculado?
• O objeto hasheado é uma imagem, um contêiner, uma exportação ou um arquivo derivado?
• Qual método de aquisição foi empregado e que categorias de dados ele alcança?
• Qual ferramenta e versão foram utilizadas, com quais parâmetros e filtros?
• Existem logs, relatórios de erro e registros de itens não processados?
• Como foi verificada a completude do conjunto disponibilizado?
• Quais são as fontes dos timestamps e como foram normalizadas?
• Há dados originários suficientes para testar a atribuição e o contexto?
• Outro profissional consegue reproduzir ou verificar as conclusões relevantes?

A atuação do assistente técnico em computação forense pode organizar essas questões, examinar os materiais disponíveis e apontar quais documentos ou testes são necessários. Quando as dúvidas precisam ser dirigidas formalmente ao exame pericial, a elaboração de quesitos técnicos para a perícia digital oferece uma continuidade prática para a auditoria.

A sequência correta é: constatação técnica, limitação identificada, possível impacto sobre a confiabilidade ou interpretação e, somente depois, avaliação jurídica. A assistência técnica contribui para qualificar o contraditório; ela não antecipa automaticamente a consequência processual.

Perguntas frequentes

O que exatamente o hash comprova em um arquivo digital?

Ele comprova a correspondência entre os bytes comparados e o valor de referência, considerando o algoritmo e o momento da verificação. Não comprova sozinho a origem, a autoria, a completude ou o contexto do arquivo.

Um hash validado prova que o arquivo veio do dispositivo ou da conta investigada?

Não. Essa conclusão depende da documentação da fonte, do método de aquisição e de elementos corroborantes, como registros do dispositivo, da conta ou do provedor.

Como saber se os arquivos disponibilizados correspondem à extração completa?

É necessário comparar o material entregue com inventários, relatórios de extração, filtros, categorias processadas, itens inacessíveis, registros de erro e dados originários. O hash do conjunto disponibilizado não resolve essa questão por si só.

Diferenças de timestamp significam adulteração?

Não necessariamente. Fusos, sincronização, relógios imprecisos, fontes temporais diferentes e conversões podem explicar divergências. A conclusão exige normalização e correlação entre registros.

Quais documentos permitem reproduzir uma extração forense?

A resposta varia, mas normalmente são relevantes os dados originários ou a imagem, hashes, ferramenta e versão, parâmetros, filtros, logs, relatórios e documentação do método de aquisição e processamento.

A validação do hash é, portanto, um ponto de controle importante, não o encerramento da análise. Ela pode demonstrar que determinado objeto permaneceu correspondente ao valor registrado, mas a confiabilidade da prova depende também de sua origem, aquisição, completude, contexto, atribuição e possibilidade de verificação independente. O arquivo íntegro é apenas uma camada; a conclusão tecnicamente defensável precisa explicar todo o percurso que levou até ele.