Aquisição e análise de dispositivos

Quando os dispositivos chegam ao laboratório, as perguntas mudam de “o que pode haver aqui?” para “o que há aqui, e podemos provar isso?”. Um endereço de carteira encontrado em um laptop só é útil em juízo se o examinador puder demonstrar que a imagem é uma cópia fiel, que a ferramenta encontrou o artefato no local indicado e que o endereço foi verificado na blockchain, em vez de apenas presumido. Esta aula aborda aquisição e integridade, fontes móveis e na nuvem, evidências de navegador, o que as ferramentas forenses fazem ao extrair chaves e endereços e como documentar as constatações.

Imagem forense e integridade

A base do exame de dispositivos é a imagem forense: uma cópia bit a bit de um meio de armazenamento, feita para que o original não seja alterado e verificada para que se possa demonstrar que a cópia corresponde ao original.

• Bloqueio de gravação. Os meios de armazenamento são conectados por meio de um bloqueador de gravação de hardware ou software, para que o computador de exame não possa alterá-los. O próprio bloqueador deve ser testado, e seu modelo e firmware devem ser registrados.
• Hashing. Durante a aquisição, o examinador calcula um hash criptográfico da fonte e um hash da imagem resultante e confirma que são iguais. Atualmente, SHA-256 é a escolha habitual; MD5 e SHA-1 ainda aparecem em ferramentas mais antigas e podem ser registrados também, mas não devem ser o único hash.
• Formatos. As imagens podem ser brutas (um arquivo simples, byte a byte) ou armazenadas em formatos de contêiner forense, como EWF (E01) ou o formato aberto AFF4, que armazenam metadados e somas de verificação internas junto com os dados.
• Cópias de trabalho. A análise é feita em cópias verificadas; a imagem original é armazenada e seu hash é calculado novamente quando ela é verificada.

As ferramentas são validadas antes do uso. O programa NIST Computer Forensics Tool Testing (CFTT) publica métodos de teste e resultados para ferramentas de imagem e bloqueadores de gravação, e os próprios registros de validação do laboratório mostram que sua configuração funciona como esperado (consulte a aula Gestão da qualidade na unidade forense).

Um registro de aquisição documenta os elementos essenciais:

Item:               CASE-0417-I-003 (SSD interno do laptop, 1 TB)
Bloqueador de gravação: hardware, modelo e firmware registrados no log do kit
Formato da imagem:  E01, tamanho do segmento 4 GB
SHA-256 da fonte:   e41b…07af
SHA-256 da imagem:  e41b…07af   (correspondência)
Início / término:   2026-03-15 09:02Z / 2026-03-15 11:47Z
Examinador:         Examinador 2
Observações:        criptografia de volume completo detectada; uma imagem
                    lógica do volume desbloqueado foi feita ao vivo no
                    local (consulte o log de ações ao vivo)

O registro identifica o item e o meio, a proteção usada, o formato, os hashes correspondentes, os horários e o examinador. A observação explica que o volume estava criptografado e vincula essa imagem à aquisição ao vivo registrada no local, razão pela qual o log de ações ao vivo descrito na aula Busca e apreensão de criptoativos no local é importante. Unidades de estado sólido acrescentam uma ressalva: sua manutenção interna pode apagar dados excluídos por conta própria, de modo que arquivos de carteira excluídos podem ser irrecuperáveis, independentemente do método.

Aquisição móvel em geral

Os telefones armazenam muitas carteiras e são os dispositivos mais difíceis de imagear. A NIST SP 800-101 Revision 1, Guidelines on Mobile Device Forensics (2014), classifica as ferramentas em cinco níveis: extração manual (fotografar a tela), extração lógica, despejo hexadecimal ou JTAG, remoção do chip e microleitura, cada um mais invasivo e tecnicamente mais complexo que o anterior. O documento de boas práticas de 2025 da SWGDE agrupa as aquisições em lógica (dados solicitados pelo sistema operacional), sistema de arquivos (completa ou parcial, nos estados AFU ou BFU) e física (acesso direto ao armazenamento).

Os telefones modernos criptografam os dados do usuário, portanto, o que pode ser adquirido depende do dispositivo, do estado de bloqueio e da ferramenta; uma extração completa do sistema de arquivos de um dispositivo desbloqueado ou em estado AFU geralmente alcança dados de aplicativos que um backup lógico não alcança. As ferramentas móveis normalmente extraem dados e depois os analisam com decodificadores específicos para cada aplicativo. O suporte a aplicativos de carteira varia e fica defasado em relação às atualizações dos aplicativos, por isso os examinadores costumam examinar diretamente os bancos de dados e arquivos de preferências de um aplicativo de carteira e devem declarar isso no relatório. O fato de um analisador “não encontrar nada” não prova que o aplicativo não continha nada.

Dados na nuvem e sincronizados

Um dispositivo apreendido costuma ser uma porta de acesso a dados armazenados em outros lugares: bibliotecas de fotos na nuvem com imagens de frases-semente, notas sincronizadas, cofres de gerenciadores de senhas, backups móveis que incluem dados de aplicativos de carteira e contas de e-mail repletas de notificações de exchange. O acesso a dados remotos por meio de um dispositivo apreendido levanta questões próprias de autorização. O Artigo 19(2) da Convenção de Budapeste prevê estender uma busca a outro sistema de computador no mesmo território; dados armazenados no exterior normalmente exigem as vias de cooperação descritas na aula Autoridade legal e cooperação internacional. Sempre que possível, preserve a conta junto ao provedor e obtenha os dados por meio de uma solicitação formal de fornecimento, o que oferece melhor proveniência do que um login ao vivo (consulte a aula Contas de exchange e na nuvem como evidências).

Histórico do navegador e sessões de exchange

Os navegadores são fontes ricas de evidências em casos de criptoativos. Bancos de dados de histórico mostram visitas a exchanges, páginas de download de carteiras e exploradores de blocos; os URLs de exploradores costumam conter o endereço ou o txid consultado pelo usuário, vinculando o dispositivo a objetos específicos na blockchain em um momento específico. Os downloads mostram instaladores de carteiras; cookies e sessões armazenadas mostram em quais contas de exchange houve login; o preenchimento automático e os logins salvos podem revelar e-mails de contas.

Os navegadores baseados no Chromium armazenam o histórico em um banco de dados SQLite chamado History. Uma consulta curta em uma cópia exportada lista visitas a exploradores:

-- Banco de dados History do Chromium (SQLite); execute em uma cópia de trabalho verificada
SELECT u.url,
       u.title,
       datetime(v.visit_time / 1000000 - 11644473600, 'unixepoch') AS visit_utc
FROM visits v
JOIN urls u ON u.id = v.url
WHERE u.url LIKE '%/address/%'
   OR u.url LIKE '%/tx/%'
ORDER BY v.visit_time;

O Chromium armazena os horários das visitas como microssegundos desde 1º de janeiro de 1601 UTC. A consulta divide por um milhão para obter segundos e subtrai 11.644.473.600 segundos, a diferença entre 1601 e a época Unix de 1970, e depois converte o resultado com a função datetime do SQLite; outros mecanismos usam funções de data diferentes. As junções associam cada visita ao seu URL, e os filtros mantêm as páginas de endereços e transações dos exploradores. O Firefox armazena dados comparáveis em places.sqlite, com um esquema diferente e microssegundos desde 1970.

Extração de chaves e endereços por ferramentas forenses

Suítes forenses e ferramentas de código aberto pesquisam imagens e capturas de memória em busca de artefatos de criptoativos de maneiras amplamente semelhantes:

As somas de verificação eliminam a maioria dos falsos positivos aleatórios, mas não todos: uma sequência hexadecimal de 40 caracteres em minúsculas pode ser um hash, não um endereço. A etapa seguinte é sempre uma verificação on-chain, de preferência no próprio nó da unidade, registrando a altura do bloco e a fonte: o endereço existe, quando esteve ativo pela primeira e pela última vez e há conexão com endereços do caso? Materiais públicos podem ser verificados livremente; qualquer resultado relacionado a material de chave é imediatamente isolado e tratado conforme descrito na aula Recuperação de carteira sob autoridade legal. Informações básicas sobre formatos de endereço estão na aula IDFE-BA Tipos de script e formatos de endereço.

Duas fontes merecem uma análise separada. Uma captura de memória feita no local pode conter material de chave ou uma semente mantida por uma carteira em execução, endereços da área de transferência e fragmentos de páginas de exchange; as ferramentas pesquisam os mesmos padrões, mas os resultados não têm caminho de arquivo nem carimbo de data e hora, portanto, o relatório deve indicar que vieram da memória e informar o horário da captura. O aplicativo complementar de uma carteira de hardware em um computador ou telefone costuma armazenar as chaves públicas estendidas do dispositivo, nomes de contas e um histórico em cache, o que pode reconstruir a atividade on-chain do dispositivo sem tocar nele.

Documentação das constatações

Cada constatação deve poder ser localizada novamente por outro examinador apenas com base no registro: item e hash da imagem, caminho do arquivo, hash do próprio arquivo, tipo de artefato, ferramenta e versão, valor extraído (truncado nos relatórios quando se tratar de material de chave), validação realizada e verificação on-chain com sua fonte e altura do bloco. Mantenha separados os níveis das afirmações. “O arquivo wallets/default_wallet existe na imagem I-003 e contém o endereço bc1q…7k3f” é um fato. “O usuário do laptop controlava bc1q…7k3f” é uma inferência que exige mais elementos: material de chave, vestígios de uso, temporalidade e quem usava o dispositivo. A aula Redação do relatório forense aborda como expressar essa diferença.

Foco no exame: bloqueio de gravação, correspondência entre os hashes da fonte e da imagem, formatos de imagem e cópias de trabalho; validação de ferramentas (NIST CFTT e registros do laboratório); os níveis de extração da NIST SP 800-101 Rev. 1 e os grupos lógico, de sistema de arquivos e físico da SWGDE; por que a cobertura de analisadores para aplicativos de carteira deve ser verificada; autorização para dados na nuvem e sincronizados acessados por meio de um dispositivo; histórico do navegador como evidência que vincula um dispositivo a endereços e txids, incluindo a conversão de horário do Chromium; validação por soma de verificação e verificações on-chain de endereços e chaves extraídos; distinção entre fatos e inferências nas constatações.