Herramientas, reproducibilidad y validación

Casi todos los rastreos de criptomonedas se producen con software, y gran parte de ese software es propietario, cambia rápidamente y está sujeto a opiniones. El tribunal no necesita confiar en la herramienta, pero sí necesita confiar en el hallazgo, y esa confianza se obtiene mostrando que los hechos pueden volver a derivarse de datos sin procesar de la cadena, que la herramienta se probó para el trabajo y que se registraron todos los ajustes y las fuentes de las etiquetas. Esta lección explica cómo mantener las herramientas en su lugar.

El panorama de las herramientas

Las herramientas se dividen en unas pocas categorías generales. Los nombres de los productos no importan aquí; lo que importa es qué aporta cada categoría a las pruebas.

La mayoría de las unidades usa varias herramientas a la vez: una plataforma para explorar y generar pistas, un nodo y sus propias consultas para establecer los hechos, y un informe elaborado con ambos.

Datos del nodo frente a resultados de las herramientas

Cada resultado de una herramienta combina tres capas. Los hechos son datos sin procesar de la cadena: txids, outputs, cantidades y bloques. Las transformaciones deterministas convierten los datos sin procesar en un formato legible: conversión de unidades, decodificación de eventos y trazas. Las interpretaciones añaden criterio: agrupaciones, etiquetas, determinación del cambio y resultados de asignación.

Una herramienta puede fallar en cada capa. Puede analizar los datos incorrectamente (los decimales de un token, una transferencia interna omitida, una reorganización gestionada incorrectamente), puede no tener cobertura (un token no indexado, una cadena no compatible, datos que van por detrás de la punta de la cadena) y puede aplicar valores predeterminados que el examinador nunca eligió (una heurística de cambio activada, un método de asignación preestablecido). La regla de trabajo es que todo hecho incluido en un informe forense debe poder rastrearse hasta datos sin procesar que un tercero pueda verificar en su propio nodo, y toda interpretación debe indicar su método y sus ajustes. Una captura de pantalla de una vista de grafo sirve de ilustración; no es una prueba. Conserva las exportaciones subyacentes.

Repetir un rastreo a partir de datos sin procesar

Antes de incluir un rastreo en un informe, vuelve a derivarlo fuera de la herramienta que lo produjo:

1. exporta la ruta de la herramienta como una tabla de saltos: txid, referencia de output o registro, altura del bloque y cantidad en unidades base;
2. vuelve a derivar los mismos campos desde tu propio nodo o desde un almacén de datos reconciliado con uno;
3. compáralos campo por campo;
4. vuelve a calcular las asignaciones con tu propio script según el método declarado;
5. registra las diferencias y cómo se resolvió cada una.

-- Compara los saltos exportados por la herramienta con los valores que volvimos a derivar de nuestro propio nodo
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;

La unión izquierda conserva todos los saltos que informó la herramienta, de modo que un salto ausente en los datos del nodo aparece como «NO ENCONTRADO EN EL NODO» en lugar de desaparecer. Las cantidades se comparan como enteros en unidades base, por lo que un error de decimales aparece como una discrepancia por una potencia de diez. La consulta solo comprueba hechos; que haya coincidencia en este punto no dice nada sobre si las etiquetas o las determinaciones de cambio de la herramienta son correctas.

Validación de herramientas

Las normas de laboratorio exigen que se demuestre que los métodos y las herramientas que los implementan son aptos para el propósito previsto. La norma ISO/IEC 17025 exige que los laboratorios validen los métodos no normalizados, los métodos desarrollados por el laboratorio y los métodos normalizados utilizados fuera de su alcance previsto o modificados de otro modo (cláusula 7.2.2). La norma ISO/IEC 27041 ofrece orientación para garantizar que los métodos de investigación sean adecuados y suficientes. El sistema de calidad correspondiente se aborda en la lección Gestión de la calidad en la unidad forense; aquí el enfoque está en las herramientas.

El documento de SWGDE Requisitos mínimos para probar herramientas utilizadas en informática forense digital y multimedia (documento 18-Q-001, versión 2.1, marzo de 2024) describe tres estrategias de prueba, todas aplicables a las herramientas de cadenas de bloques:

• Pruebas con conjuntos de datos conocidos: proporcionar una entrada cuya respuesta se conoce y comprobar el resultado.
• Pruebas comparativas: ejecutar al menos dos herramientas y comprobar que los resultados sean coherentes.
• Pruebas empíricas: comprobar el resultado frente a otros datos.

También pide que los registros de prueba indiquen el propósito y el alcance, quién hizo la prueba, la fecha, el procedimiento, los conjuntos de datos y los resultados esperados, los resultados obtenidos con las anomalías y las limitaciones detectadas. Recomienda volver a probar las herramientas internas en el primer uso y después de cada revisión, y las herramientas de búsqueda después de actualizaciones importantes. El programa Computer Forensics Tool Testing (CFTT) del NIST ofrece un modelo para estructurar las pruebas: se basa en las funciones y, antes de probar, redacta una especificación de requisitos, afirmaciones y casos de prueba para cada función de la herramienta.

Para una herramienta de cadenas de bloques, un plan de pruebas práctico enumera sus funciones y asigna a cada una una respuesta conocida:

Las transacciones de prueba controladas son especialmente valiosas porque la unidad conoce la verdad sobre la titularidad y el cambio. Todo hallazgo se incorpora a un registro de limitaciones conocidas que los examinadores consultan antes de confiar en la herramienta y que está disponible para su divulgación.

Registro de versiones y fuentes de etiquetas

Cada ejecución analítica debe tener un registro que se conserve con el expediente del 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": "Depósito de Exchange K", "source": "platform cluster 4471",
     "basis": "barrido conjunto con depósitos conocidos", "retrieved_utc": "2026-03-05T08:52:40Z"}
  ],
  "exports": [{"file": "R07_hops.csv",
               "sha256": "3b1f…9e02"}],
  "examiner": "EX-07"
}

El registro fija la versión de la herramienta y la altura del bloque hasta la cual llegaron sus datos, que puede ser anterior a la punta de la cadena del nodo. Enumera todos los ajustes que modifican los resultados. Cada etiqueta se registra con su fuente, el fundamento declarado y la hora en que se obtuvo, porque las etiquetas cambian; la misma dirección puede tener una etiqueta distinta el mes siguiente. Cada exportación se firma con un hash para que las copias posteriores puedan compararse con ella. En el registro real se indica el nombre concreto de la herramienta; este curso lo deja genérico. La conservación de estos archivos se aborda en las lecciones Preservación de pruebas en la cadena y Hashing, registro y cadena de custodia.

Cuando las herramientas no coinciden

Las discrepancias entre herramientas son normales y útiles: señalan dónde comienza la interpretación. Tomemos el rastro de la lección Rastreo según un estándar probatorio. La herramienta A informa que 0,90909091 BTC del rescate llegaron a bc1q…dx7e y etiqueta esa dirección como un depósito de Exchange K. La herramienta B informa 1,20000000 BTC y no asigna una etiqueta a la dirección.

Parte del primer punto en que divergen y vuelve a los datos sin procesar:

Entre las causas más comunes están las diferencias en la agrupación (una herramienta fusionó dos agrupaciones), en la determinación del cambio, en las fuentes o fechas de las etiquetas, en los valores predeterminados de asignación, la omisión de transferencias internas o tokens y las distintas alturas de corte de los datos. Registra la discrepancia, la causa y la resolución en el expediente del caso, y nunca la resuelvas eligiendo la herramienta que dé la respuesta más conveniente. Los peritos de la defensa suelen examinar la falta de transparencia de las herramientas y la procedencia de las etiquetas; consulta la lección Divulgación y escrutinio de la defensa.

Enfoque del examen: las categorías de herramientas y lo que cada una aporta a las pruebas; los hechos, las transformaciones deterministas y las interpretaciones, y cómo pueden fallar las herramientas en cada capa; por qué los hechos informados deben poder volver a derivarse de datos sin procesar y por qué las capturas de pantalla son ilustrativas; repetir un rastreo y comparar las exportaciones de las herramientas con los datos del nodo; la validación de métodos según ISO/IEC 17025 e ISO/IEC 27041; las tres estrategias de prueba de SWGDE, los registros de prueba y las nuevas pruebas; el modelo basado en funciones del CFTT del NIST; las pruebas con respuestas conocidas, incluidas las transacciones controladas; el registro de limitaciones conocidas; los campos de un registro de ejecución (versión, altura de los datos, ajustes, fuente y hora de obtención de las etiquetas, hashes de las exportaciones); el diagnóstico y la documentación de las discrepancias entre herramientas.