Adquisición y análisis de dispositivos

Una vez que los dispositivos llegan al laboratorio, las preguntas pasan de «¿qué podría haber aquí?» a «¿qué hay aquí y podemos demostrarlo?». Una dirección de una billetera encontrada en una computadora portátil solo es útil ante un tribunal si el examinador puede demostrar que la imagen era una copia fiel, que la herramienta encontró el artefacto donde afirma haberlo encontrado y que la dirección se verificó en la cadena de bloques, en lugar de darla por cierta. Esta lección aborda la adquisición y la integridad, las fuentes móviles y en la nube, las pruebas del navegador, lo que hacen las herramientas forenses cuando extraen claves y direcciones, y cómo documentar los hallazgos.

Imágenes forenses e integridad

La base del examen de dispositivos es la imagen forense: una copia bit a bit de un medio de almacenamiento, creada para que el original no se modifique y verificada para demostrar que la copia coincide con él.

• Bloqueo de escritura. Los medios de almacenamiento se conectan mediante un bloqueador de escritura de hardware o software para que la computadora de examen no pueda alterarlos. El bloqueador en sí debe probarse, y se deben registrar su modelo y firmware.
• Hashing. Durante la adquisición, el examinador calcula un hash criptográfico de la fuente y otro de la imagen resultante, y confirma que coinciden. SHA-256 es la opción habitual en la actualidad; MD5 y SHA-1 siguen apareciendo en herramientas antiguas y pueden registrarse también, pero no deberían ser los únicos hashes.
• Formatos. Las imágenes pueden ser sin procesar (un archivo simple, byte por byte) o guardarse en formatos de contenedor forense, como EWF (E01) o el formato abierto AFF4, que almacenan metadatos y sumas de verificación internas junto con los datos.
• Copias de trabajo. El análisis se realiza en copias verificadas; la imagen original se almacena y se vuelve a calcular su hash cuando se revisa.

Las herramientas se validan antes de usarlas. El programa NIST Computer Forensics Tool Testing (CFTT) publica métodos de prueba y resultados para herramientas de creación de imágenes y bloqueadores de escritura, y los registros de validación propios de un laboratorio demuestran que su configuración funciona según lo previsto (véase la lección Gestión de calidad en la unidad forense).

Un registro de adquisición recoge los datos esenciales:

Elemento:         CASE-0417-I-003 (SSD interno de computadora portátil, 1 TB)
Bloqueador de     hardware; modelo y firmware registrados en el
 escritura:       registro del kit
Formato de imagen: E01, tamaño de segmento 4 GB
SHA-256 de       e41b…07af
 la fuente:
SHA-256 de       e41b…07af   (coinciden)
 la imagen:
Inicio / fin:    2026-03-15 09:02Z / 2026-03-15 11:47Z
Examinador:      Examinador 2
Notas:           se detectó cifrado de volumen completo; se tomó
                 en vivo una imagen lógica del volumen desbloqueado
                 en el lugar (véase el registro de acciones en vivo)

El registro identifica el elemento y el medio, la protección utilizada, el formato, los hashes coincidentes, las horas y el examinador. La nota explica que el volumen estaba cifrado y vincula esta imagen con la adquisición en vivo registrada en el lugar, por lo que es importante el registro de acciones en vivo descrito en la lección Registro y confiscación de criptoactivos en el lugar. Las unidades de estado sólido tienen una salvedad: su mantenimiento interno puede borrar por sí solo los datos eliminados, por lo que quizá no sea posible recuperar archivos de billetera eliminados, independientemente del método.

Adquisición móvil en general

Los teléfonos contienen muchas billeteras y son los dispositivos más difíciles de crear en imágenes forenses. La norma NIST SP 800-101 Revision 1, Guidelines on Mobile Device Forensics (2014), clasifica las herramientas en cinco niveles: extracción manual (fotografiar la pantalla), extracción lógica, volcado hexadecimal o JTAG, extracción del chip y microl ectura, cada uno más invasivo y técnico que el anterior. El documento de buenas prácticas de SWGDE de 2025 agrupa las adquisiciones en lógicas (datos solicitados a través del sistema operativo), de sistema de archivos (completas o parciales, en estado AFU o BFU) y físicas (acceso directo al almacenamiento).

Los teléfonos modernos cifran los datos del usuario, por lo que lo que se puede adquirir depende del dispositivo, su estado de bloqueo y la herramienta; una extracción completa del sistema de archivos de un dispositivo desbloqueado o en estado AFU suele acceder a datos de aplicaciones que una copia de seguridad lógica no alcanza. Las herramientas móviles suelen extraer datos y luego analizarlos con decodificadores específicos para cada aplicación. La compatibilidad con las aplicaciones de billetera varía y suele quedar rezagada respecto de las actualizaciones de las aplicaciones, por lo que los examinadores suelen analizar directamente las bases de datos y los archivos de preferencias de una aplicación de billetera y deben indicarlo en el informe. Que un analizador «no haya encontrado nada» no demuestra que la aplicación no contuviera nada.

Datos en la nube y sincronizados

Un dispositivo incautado suele ser una puerta de acceso a datos almacenados en otros lugares: bibliotecas de fotos en la nube con imágenes de frases semilla, notas sincronizadas, bóvedas de administradores de contraseñas, copias de seguridad móviles que incluyen datos de aplicaciones de billetera y cuentas de correo electrónico llenas de notificaciones de exchange. Acceder a datos remotos a través de un dispositivo incautado plantea sus propias cuestiones de autorización. El artículo 19(2) del Convenio de Budapest contempla ampliar una búsqueda a otro sistema informático ubicado en el mismo territorio; para acceder a datos almacenados en el extranjero, normalmente se requieren las vías de cooperación descritas en la lección Autorización legal y cooperación internacional. Cuando sea posible, se debe preservar la cuenta con el proveedor y obtener los datos mediante una solicitud de entrega, lo que ofrece una procedencia más sólida que iniciar una sesión en vivo (véase la lección Cuentas de exchange y en la nube como pruebas).

Historial del navegador y sesiones de exchange

Los navegadores son fuentes de información valiosas en los casos relacionados con criptoactivos. Las bases de datos del historial muestran visitas a exchanges, páginas de descarga de billeteras y exploradores de bloques; las URL de los exploradores suelen contener la dirección o el txid que buscó el usuario, lo que vincula el dispositivo con objetos específicos en la cadena de bloques en un momento determinado. Las descargas muestran instaladores de billeteras; las cookies y las sesiones almacenadas muestran en qué cuentas de exchange se había iniciado sesión; y el autocompletado y las credenciales guardadas pueden revelar correos electrónicos de cuentas.

Los navegadores basados en Chromium guardan el historial en una base de datos SQLite llamada History. Una consulta breve a una copia exportada enumera las visitas a exploradores de bloques:

-- Base de datos History de Chromium (SQLite); ejecutar en una copia de trabajo 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;

Chromium almacena las horas de visita como microsegundos desde el 1 de enero de 1601 UTC. La consulta divide entre un millón para obtener segundos y resta 11.644.473.600 segundos, la diferencia entre 1601 y la época Unix de 1970; luego, convierte el valor con la función datetime de SQLite. Otros motores utilizan funciones de fecha distintas. Las uniones vinculan cada visita con su URL, y los filtros conservan las páginas de direcciones y transacciones de los exploradores de bloques. Firefox almacena datos comparables en places.sqlite, con un esquema diferente y microsegundos desde 1970.

Extracción de claves y direcciones mediante herramientas forenses

Las suites forenses y las herramientas de código abierto buscan artefactos de criptoactivos en imágenes y capturas de memoria de maneras muy similares:

Las sumas de verificación eliminan la mayoría de los falsos positivos aleatorios, pero no todos: una cadena hexadecimal de 40 caracteres en minúsculas puede ser un hash, no una dirección. El siguiente paso siempre es una verificación en la cadena de bloques, preferiblemente con el propio nodo de la unidad, y registrando la altura del bloque y la fuente: ¿existe la dirección?, ¿cuándo estuvo activa por primera y última vez?, ¿está conectada con direcciones del caso? El material público puede verificarse libremente; cualquier resultado que contenga material de claves se aísla de inmediato y se gestiona según lo descrito en la lección Recuperación de billeteras bajo autorización legal. La lección de IDFE-BA Tipos de scripts y formatos de direcciones ofrece información de contexto sobre los formatos de direcciones.

Dos fuentes merecen una revisión aparte. Una captura de memoria tomada en el lugar puede contener material de claves o una semilla retenida por una billetera en ejecución, direcciones del portapapeles y fragmentos de páginas de exchanges; las herramientas la buscan con los mismos patrones, pero los resultados no tienen una ruta de archivo ni una marca de tiempo, por lo que el informe debe indicar que provienen de la memoria y especificar la hora de captura. La aplicación complementaria de una billetera de hardware en una computadora o un teléfono suele almacenar las claves públicas extendidas del dispositivo, los nombres de las cuentas y un historial en caché, lo que puede permitir reconstruir la actividad del dispositivo en la cadena de bloques sin tocar el dispositivo en sí.

Documentación de los hallazgos

Otro examinador debería poder volver a encontrar cada hallazgo basándose únicamente en el registro: elemento y hash de la imagen, ruta del archivo, hash propio del archivo, tipo de artefacto, herramienta y versión, valor extraído (truncado en los informes cuando se trate de material de claves), validación realizada y verificación en la cadena de bloques con su fuente y altura del bloque. Mantenga separados los distintos niveles de afirmación. «El archivo wallets/default_wallet existe en la imagen I-003 y contiene la dirección bc1q…7k3f» es un hecho. «El usuario de la computadora portátil controlaba bc1q…7k3f» es una inferencia que requiere más pruebas: material de claves, rastros de uso, cronología e información sobre quién utilizó el dispositivo. La lección Redacción del informe forense explica cómo expresar esa diferencia.

Enfoque del examen: bloqueo de escritura, coincidencia de los hashes de la fuente y la imagen, formatos de imagen y copias de trabajo; validación de herramientas (NIST CFTT y registros del laboratorio); niveles de extracción de NIST SP 800-101 Rev. 1 y grupos de adquisición lógica, de sistema de archivos y física de SWGDE; por qué debe comprobarse la compatibilidad de los analizadores con las aplicaciones de billetera; autorización para acceder a datos en la nube y sincronizados desde un dispositivo; historial del navegador como prueba que vincula un dispositivo con direcciones y txid, incluida la conversión de hora de Chromium; validación mediante sumas de verificación y verificaciones en la cadena de bloques de las direcciones y claves extraídas; y distinción entre hechos e inferencias en los hallazgos.