Uma mensagem encontrada em um celular apreendido pode parecer uma prova direta de que determinada pessoa escreveu e enviou aquele conteúdo. Tecnicamente, porém, essa conclusão exige separar o que foi observado no dispositivo daquilo que se pretende afirmar sobre sua origem, autoria, contexto e integridade.
Uma extração pode produzir registros de aplicativos, bases de dados, anexos, logs e metadados associados ao conjunto adquirido. Isso pode ser relevante para reconstruir eventos e formular hipóteses. Mas a existência de um resultado no output da ferramenta não equivale, por si só, à demonstração de autoria remota, intenção, origem ou integridade histórica do conteúdo.
A distinção central é esta: uma extração pode documentar um resultado atribuído ao processo de aquisição e análise; ela não necessariamente estabelece quem originou a mensagem, se o registro veio diretamente do dispositivo ou de uma fonte sincronizada ou derivada, nem se o conteúdo permaneceu inalterado antes da aquisição.
Para advogados de contencioso e profissionais de investigação, essa diferença separa uma afirmação tecnicamente defensável de uma conclusão que depende de premissas não demonstradas.
A cadeia entre o celular e a conclusão investigativa
A análise deve separar pelo menos cinco níveis diferentes:
- o dispositivo apreendido;
- o método de aquisição ou extração utilizado;
- o output e os artefatos recuperados;
- a interpretação técnica desses artefatos; e
- a conclusão investigativa formulada a partir deles.
Cada nível responde a uma pergunta diferente.
O dispositivo é o ponto de partida. Seu estado — ligado ou desligado, bloqueado ou desbloqueado, com cartões ou acessórios relevantes, com sinais de alteração do sistema e com possíveis sincronizações recentes — deve ser documentado quando aplicável. A posse física do aparelho, contudo, não demonstra necessariamente controle exclusivo da conta ou da infraestrutura remota associada a ele.
O método de aquisição define o conjunto de dados que pode ser apresentado e influencia a interpretação posterior. O resultado depende do tipo de extração, do estado do dispositivo, da configuração de segurança, da versão do sistema e da ferramenta empregada. Não se deve tratar uma capacidade anunciada por fornecedor como resultado universal ou como prova independente de que determinado dado sempre será recuperado.
Procedimentos distintos podem ter efeitos distintos. Quando forem empregados métodos mais intrusivos ou dependentes de implementação específica, o relatório deve identificar o procedimento efetivamente realizado, suas condições, os controles aplicados e qualquer efeito observado ou tecnicamente esperado no caso concreto. Termos como bootloader, JTAG ou chip-off não devem ser tratados como uma categoria homogênea nem como demonstração automática de alteração ou dano.
O artefato é o elemento apresentado pela ferramenta ou identificado durante a análise: por exemplo, uma linha de base de dados, um arquivo de mídia, um registro de log ou um anexo. Antes de atribuir esse elemento ao conteúdo original do dispositivo, é necessário esclarecer sua fonte, seu caminho de aquisição e se ele pode ser sincronizado, restaurado, derivado ou reconstruído por software.
A interpretação técnica explica o significado possível desse elemento. Já a conclusão investigativa sintetiza o que se pretende afirmar sobre autoria, fluxo da comunicação, contexto ou intenção. Confundir esses níveis é uma fonte recorrente de excesso interpretativo. Uma linha em uma base de dados é um dado apresentado no resultado da análise; a afirmação de que uma autoridade específica escreveu a mensagem é uma conclusão que depende de premissas adicionais.
O que uma extração pode demonstrar — com as qualificações necessárias
Quando o processo é devidamente documentado, a análise pode indicar que determinado objeto ou registro foi produzido pelo procedimento de aquisição e apresentado como associado ao dispositivo examinado. Essa conclusão depende da documentação completa do processo, da identificação da fonte do artefato, do comportamento conhecido ou validado da ferramenta e da exclusão — ou adequada consideração — de fontes sincronizadas, restauradas ou derivadas.
Entre os elementos que podem aparecer em uma aquisição, conforme o aplicativo, o sistema, a configuração e o método utilizado, estão:
- bases de dados de aplicativos;
- registros de mensagens e conversas;
- identificadores de remetente, destinatário, conta ou chat;
- timestamps registrados pelo aplicativo ou pelo sistema;
- identificadores de mensagens;
- recibos de entrega ou leitura, quando armazenados e recuperados;
- imagens, áudios, vídeos e outros anexos;
- caches, notificações e logs;
- backups locais, manifestos ou outros arquivos auxiliares.
Essa lista descreve categorias possíveis, não um conjunto garantido de resultados. A presença, o significado e a completude de cada item dependem da versão do aplicativo, do sistema operacional, do modelo do aparelho, do estado criptográfico, da configuração, do método de aquisição e da ferramenta utilizada. A documentação fornecida pelo fornecedor pode descrever uma capacidade declarada, mas não substitui a validação independente no cenário concreto.
A afirmação sobre a presença de um registro deve ser formulada com precisão. Em vez de afirmar simplesmente que o registro existia no dispositivo, o relatório deve esclarecer: qual foi o output produzido; qual foi a fonte identificada; como o vínculo com o dispositivo foi estabelecido; quais etapas de transformação ocorreram; e quais limitações permanecem sobre a interpretação do conteúdo.
Hashing, integridade e proveniência não são a mesma coisa
Hashes calculados durante a aquisição ou em etapas posteriores podem permitir a detecção de alteração do objeto digital hashado depois do cálculo. Essa é uma função de integridade pós-aquisição: comparar o hash ajuda a verificar se o objeto, a imagem ou o conjunto de dados permaneceu correspondente ao estado registrado naquela etapa.
Esse resultado não estabelece, sozinho, a autenticidade histórica do conteúdo, sua completude, sua correção semântica, sua origem remota ou a ausência de alteração antes do cálculo. Também não resolve automaticamente se o objeto hashado é uma representação direta do dispositivo, um arquivo sincronizado, uma restauração, uma exportação ou um resultado derivado pela ferramenta.
Por isso, o relatório deve distinguir expressamente:
- a integridade do objeto ou da imagem após o cálculo do hash;
- a proveniência atribuída ao dispositivo e ao processo de aquisição;
- a autenticidade e a integridade histórica do conteúdo representado; e
- a completude do conjunto de dados recuperado.
A cadeia de custódia, os registros de aquisição, a identificação da ferramenta e de sua versão, os horários relevantes, os parâmetros aplicáveis e a documentação da fonte do artefato são necessários para que o hash seja interpretado no contexto correto. O hash é uma evidência de correspondência entre objetos em determinadas etapas; não é, isoladamente, uma prova de que o conteúdo original era autêntico ou completo.
O que um registro local não demonstra sozinho
A presença de uma mensagem no resultado da análise não prova automaticamente que o titular da conta remota escreveu ou enviou aquela mensagem. O dispositivo pode ter sido acessado por outra pessoa, a conta pode ter sido utilizada em mais de um equipamento ou o conteúdo local pode não refletir integralmente o estado do serviço remoto.
Também não se deve tratar um timestamp local como confirmação automática do horário real de envio ou recebimento no servidor. O campo pode representar o momento registrado pelo aplicativo, pelo dispositivo ou por uma etapa específica do fluxo de sincronização. Sua interpretação depende da arquitetura aplicável, da documentação do campo, dos elementos recuperados e do contexto do caso.
A exibição de uma mensagem tampouco prova, por si só, a integridade histórica do conteúdo. Uma hipótese de alteração, reconstrução ou inconsistência deve ser tratada como hipótese até que existam elementos específicos que a sustentem. A possibilidade genérica de manipulação não demonstra que houve manipulação naquele caso, e não deve ser apresentada como característica comprovada de uma aplicação ou versão sem teste dirigido.
A formulação tecnicamente defensável tende a ser mais restrita: o resultado é compatível com determinada conta, identificador ou evento local; foi produzido ou apresentado pelo processo de aquisição; e foi preservado conforme o procedimento documentado. Isso é diferente de afirmar, sem qualificações, que uma pessoa específica enviou a mensagem em determinado momento.
Aplicativos e sistemas produzem limites diferentes
Aplicativos de mensagens e sistemas operacionais não devem ser tratados como equivalentes. O conteúdo recuperável, os campos exibidos, a forma de sincronização, as proteções criptográficas e a interpretação dos metadados variam conforme a aplicação, a versão, o dispositivo, a configuração e o método de aquisição.
Assim, uma base local pode conter registros, identificadores, anexos ou timestamps sem que esses elementos tenham o mesmo significado em todas as versões ou plataformas. Uma conversa sincronizada, um backup, uma notificação, um cache e um registro produzido pela ferramenta podem representar fontes diferentes e não devem ser misturados sem explicação.
Em aplicações com criptografia, chaves protegidas ou mecanismos de backup específicos, a disponibilidade do conteúdo depende das chaves, da configuração, do estado do dispositivo e do método empregado. A ausência de um resultado não demonstra necessariamente a ausência do conteúdo na origem; da mesma forma, a recuperação de um resultado não demonstra automaticamente sua completude.
As fontes técnicas e de fornecedor listadas ao final podem ajudar a contextualizar procedimentos, segurança ou formatos específicos. Elas não autorizam generalizações para todas as versões, aparelhos, configurações ou ferramentas. Cada afirmação material deve ser relacionada à fonte efetivamente aplicável e, quando necessário, a teste técnico específico.
Proveniência e transparência do método
A força técnica do resultado depende da transparência do procedimento.
Um laudo ou relatório deve registrar, quando aplicável, o modelo e a versão do dispositivo, a versão do sistema operacional, a ferramenta e sua versão, o tipo de aquisição, os hashes calculados, os horários relevantes, a cadeia de custódia, o estado de bloqueio e sinais de alteração do sistema ou de sincronização relevante.
Quando a aquisição depender de recurso proprietário, exploit ou processamento interno da ferramenta, o relatório deve indicar essa dependência sem presumir que a documentação pública descreva integralmente a implementação, os efeitos colaterais ou a validade do resultado em todos os cenários. A capacidade anunciada pelo fornecedor deve ser distinguida de uma capacidade validada independentemente no caso concreto.
A preservação da integridade pós-aquisição é essencial, mas não resolve todas as perguntas sobre proveniência, completude ou integridade anterior. A análise pode considerar bases de dados, arquivos auxiliares, registros do sistema e outros artefatos correlatos, desde que sua origem, relevância e limitações sejam explicitadas. Caches e notificações podem contribuir para a correlação, mas seu significado deve ser avaliado no contexto e não presumido.
Fontes potenciais de corroboração
Antes de converter um resultado local em uma afirmação de autoria, origem ou integridade histórica, podem ser avaliadas fontes independentes de corroboração, quando existirem e forem tecnicamente acessíveis. Nenhuma categoria abaixo é necessariamente disponível, completa ou confirmatória em todos os casos.
Registros de provedor ou servidor podem, dependendo do serviço, da retenção, do escopo e da autenticidade, contribuir para testar hipóteses sobre eventos, identificadores ou horários. Backups independentes podem oferecer comparação com o estado local, mas também precisam ser identificados quanto à origem, ao momento, à sincronização e ao processo de preservação.
Registros de operadora, evidências de sessão, tokens, cookies ou logs de login podem ser relevantes para uma hipótese sobre atividade ou acesso, mas não têm significado uniforme. A presença de um identificador pode ser compatível com uma sessão ou dispositivo sem demonstrar, isoladamente, quem operou a conta ou quem originou determinado conteúdo.
Anexos encontrados em locais distintos podem ser comparados por meio de hashes ou outras características técnicas. Essa comparação pode testar correspondência entre objetos, mas não estabelece, sozinha, autoria, origem remota ou integridade histórica.
Elementos contextuais — como cronologia de posse do aparelho, evidências de acesso físico, logs de sistemas correlacionados e registros independentes de tempo — podem ajudar a avaliar hipóteses concorrentes. Seu valor depende da autenticidade, do escopo, da relação temporal e da interpretação técnica. A disponibilidade, obtenção e avaliação jurídica desses dados dependem do caso e da jurisdição e não são tratadas por este artigo.
Não há uma base pública consistente que permita presumir o formato, a retenção, a disponibilidade ou o significado dos registros para todos os provedores e situações no Brasil.
Como redigir uma conclusão tecnicamente defensável
Uma estrutura útil é separar expressamente quatro blocos:
1. Dados observados
Descrever o output, o artefato, sua localização ou fonte indicada, os campos recuperados, os identificadores, os timestamps e os anexos relacionados. Se houver transformação, sincronização, restauração ou derivação, isso deve ser indicado.
2. Processo empregado
Informar como o dispositivo foi preservado, qual método de aquisição foi usado, qual ferramenta e versão foram empregadas, quais hashes e registros de aquisição foram produzidos e quais limitações do método foram identificadas.
3. Inferência técnica
Explicar por que determinado campo é compatível com uma conta, um contato, uma conversa ou um evento local. A base técnica da inferência e suas limitações devem permanecer visíveis. Compatibilidade não deve ser convertida automaticamente em identificação ou autoria.
4. Conclusão e limitações
Indicar o que pode ser afirmado sobre o resultado e o processo, o que não pode ser afirmado com os elementos disponíveis e quais fontes adicionais poderiam testar as hipóteses remanescentes. Essa descrição é técnica; a suficiência ou admissibilidade jurídica depende do caso e da jurisdição.
Uma formulação possível seria: “Foi identificado, no output da aquisição, um registro apresentado como associado ao dispositivo apreendido e preservado na imagem correspondente. A conclusão sobre sua origem direta no dispositivo depende da documentação da fonte e do método empregado. Com os elementos disponíveis, não foi possível confirmar que a mensagem foi originada pelo titular da conta. Outras fontes independentes, se disponíveis e tecnicamente comparáveis, podem contribuir para testar essa hipótese.”
Essa linguagem não enfraquece o resultado. Ao contrário, torna explícita a fronteira entre observação, inferência e conclusão.
Implicações para advogados e investigadores
A extração de um celular pode contribuir para reconstruir uma cronologia, identificar contas e contatos associados, localizar anexos ou comparar registros entre dispositivos. Sua utilidade depende da pergunta formulada antes da análise e da correspondência entre essa pergunta e o método empregado.
Se a pergunta é “este resultado estava associado ao dispositivo no processo de aquisição?”, a imagem, a documentação da fonte, os registros do método e os hashes ocupam posição central. Se a pergunta é “quem enviou originalmente esta mensagem?”, será necessário avaliar, entre outros aspectos técnicos, o controle da conta, os dispositivos associados, possíveis fontes sincronizadas e registros independentes que possam testar a hipótese. Se a pergunta é “o conteúdo foi preservado sem alteração desde a origem?”, a aquisição documentada é apenas uma parte da resposta.
O risco aumenta quando um artefato é apresentado publicamente como uma conclusão fechada, especialmente em matéria envolvendo autoridades. Sem corroboração técnica suficiente, a redação deve permanecer qualificadora: “compatível com”, “indica a presença de”, “foi apresentado como associado a”, “não contradiz” ou “não permite afirmar com certeza”.
Perspectiva IVIDENTIA
O valor de uma extração forense não está apenas na quantidade de dados recuperados. Está na capacidade de demonstrar, com transparência, o que cada resultado sustenta, qual é sua fonte, quais hipóteses permanecem abertas e quais elementos adicionais poderiam testá-las.
Para mensagens atribuídas a autoridades, a análise deve preservar essa disciplina: separar o dispositivo da conta, o output da ferramenta da origem do artefato, o registro local da origem remota, o hash da integridade histórica e a interpretação pericial da conclusão investigativa.
Quando a pergunta exige atribuição, integridade ou contexto, o próximo passo não é preencher as lacunas com certeza. É identificar precisamente quais elementos técnicos ainda faltam e quais deles podem ser avaliados no caso concreto.
Fontes
As fontes abaixo permanecem como base factual e contextual do conteúdo. A existência de uma fonte não significa que ela valide universalmente cada afirmação técnica, versão, ferramenta ou cenário descrito. Afirmações específicas sobre aplicativos, capacidades de fornecedores ou métodos de aquisição exigem correspondência localizada e, quando aplicável, validação técnica adicional.
- SP 800-101 Rev. 1, Guidelines on Mobile Device Forensics — NIST.
- SWGDE Best Practices for Mobile Device Evidence Collection & Preservation, Handling, and Acquisition — SWGDE.
- ISO/IEC 27037:2012 — Guidelines for identification, collection, acquisition and preservation of digital evidence — ISO.
- Cellebrite UFED / Physical Analyzer: UFED 4PC overview & release notes — Cellebrite. Documento de fornecedor; descreve capacidades no escopo informado e não constitui validação independente ou universal.
- WhatsApp forensic analyses / msgstore.db studies — pesquisa acadêmica e técnica. Material contextual, sem base suficiente para generalizar resultados atuais a todas as versões e configurações.
- Signal troubleshooting & backup documentation — Signal Support. Documentação do fornecedor, dependente do recurso e da configuração aplicáveis.
- DC3 Technical Advisory — Signal chat app decryption — US DoD / DC3. Material técnico contextual, não uma validação universal de recuperabilidade.
- Apple Platform Security / iOS Backup & Keybag details — Apple. Documentação de segurança e plataforma, dependente do dispositivo, versão e configuração.
- Telegram technical FAQ / MTProto explanation — Telegram. Documentação técnica do serviço, sem estabelecer por si só o resultado de uma aquisição forense concreta.
