Peritia
Forense Web3 / Blockchain · W3·03

Peritaje forense de contratos inteligentes y exploits

Cuando un protocolo pierde fondos, la discusión rara vez es sobre si ocurrió: es sobre por qué ocurrió y de quién es la responsabilidad. Un contrato inteligente es código publicado que se ejecuta de forma determinista, y esa propiedad permite algo poco habitual en el peritaje informático: reproducir el incidente exactamente como sucedió, sobre una copia del estado real de la red en el bloque anterior al ataque.

Cuándo se necesita

  • Un protocolo ha sufrido un exploit y necesita determinar con precisión técnica qué fallo se aprovechó y en qué componente estaba.
  • Disputa entre el promotor del proyecto y la empresa desarrolladora sobre si hubo negligencia en el diseño o en la implementación del contrato.
  • Reclamación frente a una auditoría de seguridad previa que no detectó la vulnerabilidad explotada, en el marco de una responsabilidad contractual.
  • Discusión sobre si un tercero explotó un defecto o simplemente utilizó el contrato conforme a la lógica que su propio código permitía.
  • Sospecha de rug pull: funciones privilegiadas, contratos actualizables mediante proxy o claves de administración que permitían retirar los fondos de los usuarios.

Qué incluye el informe

  • Identificación de las transacciones del incidente con hash, número de bloque, índice dentro del bloque y traza completa de ejecución (call trace) con todas las llamadas internas y sus parámetros.
  • Verificación del bytecode efectivamente desplegado en la red frente al código fuente publicado, para acreditar si lo que se ejecutaba era realmente lo que se decía que se ejecutaba.
  • Determinación de la vulnerabilidad concreta, localizada en la función y la línea afectadas, con explicación del mecanismo en términos comprensibles para un lector no técnico.
  • Reproducción del ataque en un fork de la red al bloque inmediatamente anterior, entregando el script de reproducción para que cualquier tercero pueda ejecutarlo y obtener el mismo resultado.
  • Análisis de funciones privilegiadas, patrones de proxy actualizable, temporizadores de gobernanza y control efectivo de las claves de administración en el momento del incidente.
  • Cuantificación del daño: activos extraídos por tipo y cantidad, contravalor en euros a la fecha y hora del bloque, con indicación de la fuente de cotización y del método de valoración.
  • Anexo de reproducibilidad con versiones de compilador, optimizador, herramientas de análisis y entorno de simulación, más la huella SHA-256 de todos los artefactos entregados.
Cómo se hace

Método

01
Reconstrucción del estado
Se levanta una copia local de la red bifurcada en el bloque anterior al incidente. Esa copia reproduce el estado real de todos los contratos y saldos implicados en ese instante, lo que permite trabajar sobre el escenario exacto del ataque sin tocar la red pública ni afectar a nadie.
02
Análisis estático y de bytecode
Se revisa el código fuente y, cuando no está verificado o difiere del desplegado, se descompila el bytecode. Se estudian los flujos de control, la gestión de permisos, las llamadas externas y los invariantes económicos que el contrato debía preservar y que el ataque rompió.
03
Reproducción controlada
Se ejecuta el ataque sobre el fork replicando la secuencia original de transacciones. Si el resultado coincide con el observado en la red real, queda acreditado que la hipótesis explicativa es correcta y no una mera conjetura. El script se entrega con el dictamen.
04
Cuantificación y dictamen
Se determina el perjuicio en unidades de cada activo y en euros, y se emite el informe conforme a UNE 197001:2019 y UNE 197010:2015, con la declaración de objetividad del art. 335.2 LEC y separación estricta entre hechos verificados, resultados de simulación y valoraciones del perito.
Transparencia

Qué no hacemos

Decirlo por adelantado evita expectativas equivocadas y es parte del deber de objetividad del perito (art. 335.2 LEC).

Preguntas frecuentes

Forense de smart contracts

Si el código permitía la operación, ¿realmente hubo un ataque?

Es la discusión de fondo en casi todos estos casos, y no se resuelve con el eslogan de que el código es la ley. Técnicamente puede acreditarse mucho: si la secuencia de transacciones era económicamente coherente o solo tenía sentido para extraer valor, si se emplearon préstamos relámpago para forzar un estado imposible en condiciones normales, si se rompió un invariante que la documentación del protocolo declaraba expresamente, y si el atacante realizó despliegues y pruebas previas que evidencian conocimiento del defecto. El dictamen expone esos elementos objetivos con precisión; la calificación jurídica corresponde al tribunal.

¿Qué es un fork de la red y por qué es importante reproducir el ataque?

Un fork es una copia local de la cadena tomada en un bloque concreto: replica el estado exacto de todos los contratos y saldos en ese momento y permite ejecutar transacciones sobre él sin ningún efecto en la red pública. Su valor probatorio es considerable, porque convierte una hipótesis en algo comprobable. Si al reproducir la secuencia sobre el fork se obtiene el mismo resultado que se observó en la red real, la explicación del incidente queda demostrada y no depende de la autoridad del perito. Además, cualquier otro técnico puede ejecutar el mismo script y verificarlo.

¿Puede determinarse si la auditoría previa fue deficiente?

Puede analizarse con criterios técnicos. Se contrasta el alcance declarado en el informe de auditoría con el código realmente desplegado, se comprueba si la función vulnerable estaba dentro de ese alcance, si la clase de vulnerabilidad era conocida y documentada en el estado del arte en la fecha de la auditoría, y si las herramientas y comprobaciones habituales en ese momento la habrían detectado. También se verifica si la auditoría advirtió del riesgo y la advertencia no se atendió. El dictamen aporta esos elementos; la existencia de responsabilidad contractual la determina el tribunal.

¿Cómo se cuantifica el daño de un exploit?

Se parte de lo objetivo: los activos que salieron del contrato, identificados por tipo y cantidad exacta a partir de los registros de eventos y las trazas de ejecución. Después se convierten a euros aplicando la cotización correspondiente a la marca temporal del bloque, dejando constancia de la fuente empleada. Es un punto delicado, porque los ataques suelen provocar caídas bruscas de precio del propio activo del protocolo y la cotización del momento puede no reflejar el valor previo. El dictamen expone el método, sus supuestos y, cuando procede, escenarios alternativos de valoración con su justificación.

Servicios relacionados
Contacto

¿Encaja con su caso?

Consulta inicial confidencial y sin compromiso. Le diremos con franqueza si hay prueba que obtener y cómo.