Fundamentos do rastreamento · Aula 5 de 5
Ferramentas, reprodutibilidade e validação
9 min de leitura
Quase todo rastreamento de criptoativos é produzido com software, e grande parte desse software é proprietário, muda rapidamente e segue suas próprias premissas. O tribunal não precisa confiar na ferramenta, mas precisa confiar na conclusão, e essa confiança vem da demonstração de que os fatos podem ser derivados novamente a partir dos dados brutos da blockchain, de que a ferramenta foi testada para a finalidade em questão e de que todas as configurações e fontes de rótulos foram registradas. Esta aula aborda como manter as ferramentas em seu devido lugar.
O panorama das ferramentas
As ferramentas se enquadram em algumas categorias amplas. Os nomes dos produtos não importam aqui; o que importa é o que cada categoria acrescenta às evidências.
| Categoria | Exemplos | O que acrescenta | Status probatório |
|---|---|---|---|
| Software de nó | Bitcoin Core, Geth, Erigon (código aberto) | Dados brutos validados da blockchain | Fonte de referência para os fatos |
| Exploradores de blocos | Exploradores públicos na web | Visualizações convenientes, muitas vezes com rótulos | Recurso de trabalho; não é um registro, a menos que seja capturado com sua procedência |
| ETL e data warehouses | Frameworks ETL de código aberto, conjuntos de dados públicos de blockchain | Tabelas para SQL em grande escala | Fatos, se reconciliados com um nó |
| Plataformas de investigação | Plataformas comerciais; projetos de código aberto como o GraphSense | Agrupamentos, rótulos, visualizações de grafos, mecanismos de alocação | Interpretação; exige validação e divulgação das configurações |
| Scripts e notebooks próprios | SQL, Python | Exatamente a lógica que você escolher | Método interno; também precisa ser testado |
A maioria das unidades usa várias ferramentas ao mesmo tempo: uma plataforma para explorar e gerar pistas, um nó e consultas próprias para estabelecer fatos, e um relatório construído com base em ambos.
Dados do nó versus resultados da ferramenta
Todo resultado de ferramenta combina três camadas. Fatos são dados brutos da blockchain: txids, saídas, valores, blocos. Transformações determinísticas convertem dados brutos em um formato legível: conversão de unidades, decodificação de eventos, rastreamentos. Interpretações acrescentam julgamento: agrupamentos, rótulos, identificação de troco, resultados de alocação.
Uma ferramenta pode falhar em cada camada. Ela pode interpretar incorretamente os dados (as casas decimais de um token, uma transferência interna omitida, uma reorganização tratada de forma inadequada), pode não ter cobertura suficiente (um token não indexado, uma blockchain sem suporte, dados atrasados em relação ao bloco mais recente) e pode aplicar configurações padrão que o examinador nunca escolheu (uma heurística de troco ativada, um método de alocação predefinido). A regra de trabalho é que todo fato em um relatório forense deve ser rastreável a dados brutos que terceiros possam verificar em seu próprio nó, e toda interpretação deve indicar seu método e suas configurações. Uma captura de tela de uma visualização de grafo ilustra; não prova. Guarde as exportações subjacentes.
Refazer um rastreamento a partir dos dados brutos
Antes de relatar um rastreamento, derive-o novamente fora da ferramenta que o produziu:
- exporte o percurso da ferramenta como uma tabela de saltos: txid, referência da saída ou do registro, altura do bloco, valor em unidades-base;
- derive novamente os mesmos campos a partir do seu próprio nó ou de um data warehouse reconciliado com um nó;
- compare os campos um a um;
- recalcule as alocações com seu próprio script, usando o método declarado;
- registre as diferenças e como cada uma foi resolvida.
-- Compare os saltos exportados pela ferramenta com os valores derivados novamente do nosso próprio nó
SELECT t.hop_id, t.txid, t.out_ref,
t.amount_base AS tool_amount, n.amount_base AS node_amount,
t.block_height AS tool_height, n.block_height AS node_height,
CASE
WHEN n.txid IS NULL THEN 'NOT FOUND ON NODE'
WHEN t.amount_base <> n.amount_base
OR t.block_height <> n.block_height THEN 'MISMATCH'
ELSE 'OK'
END AS check_result
FROM tool_hops t
LEFT JOIN node_hops n ON n.txid = t.txid AND n.out_ref = t.out_ref
ORDER BY t.hop_id;
A junção à esquerda mantém todos os saltos relatados pela ferramenta, de modo que um salto ausente nos dados do nó aparece como "NOT FOUND ON NODE", em vez de desaparecer. Os valores são comparados como números inteiros em unidades-base, então um erro nas casas decimais aparece como uma discrepância por uma potência de dez. A consulta verifica apenas fatos; a concordância aqui não diz nada sobre a correção dos rótulos ou das identificações de troco da ferramenta.
Validar ferramentas
As normas laboratoriais exigem que os métodos e as ferramentas que os implementam sejam demonstrados como adequados à finalidade. A ISO/IEC 17025 exige que os laboratórios validem métodos não padronizados, métodos desenvolvidos pelo laboratório e métodos padronizados usados fora do escopo previsto ou modificados de outra forma (cláusula 7.2.2). A ISO/IEC 27041 fornece orientações para assegurar que os métodos de investigação sejam adequados e suficientes. O sistema de qualidade relacionado a isso é abordado na aula Gestão da qualidade na unidade forense; aqui, o foco são as ferramentas.
O documento Minimum Requirements for Testing Tools Used in Digital and Multimedia Forensics da SWGDE (documento 18-Q-001, versão 2.1, março de 2024) descreve três estratégias de teste, todas aplicáveis às ferramentas de blockchain:
- Teste com conjunto de dados conhecido: forneça uma entrada cuja resposta seja conhecida e confira o resultado.
- Teste comparativo: execute pelo menos duas ferramentas e verifique se os resultados são consistentes.
- Teste empírico: confira os resultados usando outros dados.
O documento também solicita registros de teste que indiquem a finalidade e o escopo, o responsável pelo teste, a data, o procedimento, os conjuntos de dados e os resultados esperados, os resultados com anomalias e as limitações encontradas. Recomenda testar novamente as ferramentas internas no primeiro uso e após cada revisão, e as ferramentas de busca após atualizações importantes. O programa Computer Forensics Tool Testing (CFTT) do NIST oferece um modelo para estruturar testes: ele é orientado à funcionalidade e elabora uma especificação de requisitos, afirmações e casos de teste para cada função da ferramenta antes dos testes.
Para uma ferramenta de blockchain, um plano de teste prático lista suas funções e fornece uma resposta conhecida para cada uma:
| Função | Teste com resposta conhecida |
|---|---|
| Interpretação de valores e taxas | Transações com muitas saídas, valores irrisórios e tipos de script incomuns, conferidas com um nó |
| Transferências internas | Chamadas de contrato que pagam ETH, comparadas com um rastreamento feito por um nó de rastreamento |
| Tratamento de tokens | Tokens com 6 e 18 casas decimais, um token com taxa sobre transferência, um token falsificado com um símbolo copiado |
| Agrupamento | Transações criadas pela própria unidade a partir de carteiras sob seu controle, além de dados de referência verdadeiros públicos, como endereços publicados por autoridades; medir precisão e revocação (consulte a aula IDFE-BA Avaliação da qualidade de agrupamentos) |
| Mecanismo de alocação | O livro-razão trabalhado na aula Métodos de rastreamento e suas consequências: o FIFO deve retornar 30.000, 20.000 e 0 USDT |
As transações de teste controladas são especialmente valiosas porque a unidade conhece a verdade sobre a titularidade e o troco. Tudo o que for identificado é incluído em um registro de limitações conhecidas, que os examinadores consultam antes de confiar na ferramenta e que fica disponível para divulgação.
Registrar versões e fontes de rótulos
Cada execução analítica deve ser registrada e mantida com o arquivo do caso:
{
"run_id": "CF-2026-0142-R07",
"started_utc": "2026-03-05T08:40:12Z",
"tool": {"category": "investigation platform", "version": "8.4.1", "data_through_block": 939910},
"node": {"client": "Bitcoin Core", "version": "29.0", "tip_height": 939962},
"settings": {"allocation": "haircut", "hop_limit": 6, "change_heuristic": "on",
"stop_at": "labeled custodial services"},
"labels_used": [
{"address": "bc1q…dx7e", "label": "Exchange K deposit", "source": "platform cluster 4471",
"basis": "co-swept with known deposits", "retrieved_utc": "2026-03-05T08:52:40Z"}
],
"exports": [{"file": "R07_hops.csv",
"sha256": "3b1f…9e02"}],
"examiner": "EX-07"
}
O registro fixa a versão da ferramenta e a altura do bloco até a qual seus dados chegaram, que pode ser inferior ao bloco mais recente do nó. Ele lista todas as configurações que alteram os resultados. Cada rótulo é registrado com sua fonte, a justificativa declarada e o horário em que foi obtido, pois os rótulos mudam; o mesmo endereço pode receber um rótulo diferente no mês seguinte. Cada exportação recebe um hash para que cópias posteriores possam ser conferidas. No registro real, insere-se o nome efetivo da ferramenta; este curso o mantém genérico. A preservação desses arquivos é abordada nas aulas Preservação de evidências on-chain e Hashing, registro e cadeia de custódia.
Quando as ferramentas discordam
A discordância entre ferramentas é normal e útil: ela indica onde começa a interpretação. Considere o percurso da aula Rastreamento segundo um padrão probatório. A Ferramenta A informa que 0,90909091 BTC do resgate chegou a bc1q…dx7e e rotula o endereço como um depósito na Exchange K. A Ferramenta B informa 1,20000000 BTC e não atribui rótulo ao endereço.
Comece pelo primeiro ponto de divergência e volte aos dados brutos:
| Divergência | Causa raiz encontrada | Resolução |
|---|---|---|
| Valor | A Ferramenta A usa haircut por padrão; a Ferramenta B aplica FIFO pela ordem de entradas e saídas dentro de cada transação, atribuindo a saída inteira de 1,2 BTC ao resgate | Ambos os cálculos estão corretos segundo suas regras; informe o método declarado e o intervalo |
| Rótulo | O rótulo da Ferramenta A se baseia em uma varredura conjunta com depósitos conhecidos da Exchange K; a Ferramenta B não tem fonte de rótulo para esse agrupamento | Verifique a transação de varredura em um nó; informe como heurística de grau C até que a Exchange K confirme |
Entre as causas comuns estão agrupamentos diferentes (uma ferramenta uniu dois agrupamentos), identificações de troco diferentes, fontes ou datas diferentes para os rótulos, configurações padrão de alocação diferentes, transferências internas ou tokens ausentes e alturas de corte diferentes. Registre a discordância, a causa e a resolução no arquivo do caso, e nunca a resolva escolhendo a resposta mais conveniente. Especialistas da defesa costumam questionar a opacidade das ferramentas e a procedência dos rótulos; consulte a aula Divulgação e análise crítica pela defesa.
Foco no exame: as categorias de ferramentas e o que cada uma acrescenta às evidências; fatos, transformações determinísticas e interpretações, e como as ferramentas falham em cada camada; por que os fatos relatados devem poder ser derivados novamente a partir dos dados brutos e por que as capturas de tela são ilustrações; refazer um rastreamento e comparar as exportações da ferramenta com os dados do nó; a validação de métodos segundo a ISO/IEC 17025 e a ISO/IEC 27041; as três estratégias de teste da SWGDE, os registros de teste e os novos testes; o modelo orientado à funcionalidade do NIST CFTT; testes com resposta conhecida, incluindo transações controladas; o registro de limitações conhecidas; os campos de um registro de execução (versão, altura dos dados, configurações, fonte do rótulo e horário de obtenção, hashes das exportações); diagnóstico e documentação de discordâncias entre ferramentas.