Qué contiene realmente una extracción Full File System y por qué la mayor parte nunca se examina
La pregunta interesante no es lo grande que es una extracción. Es qué proporción de ella interpreta alguna herramienta.
Pregunte a alguien ajeno al sector qué hay en un teléfono incautado y dirá mensajes, fotos y contactos. Pregúntele a un analista y se detendrá, porque la respuesta honesta es que nadie lo sabe del todo, y averiguarlo es precisamente el trabajo.
Una extracción Full File System es una copia del sistema de archivos del dispositivo tal como lo ve el sistema operativo. No es una exportación seleccionada, ni el subconjunto que una aplicación acepta entregar a través de una interfaz de copia de seguridad. Es el árbol completo.
Merece la pena recorrer lo que hay realmente dentro, porque la forma de los datos explica casi todo sobre adónde va el tiempo de examen.
Cuatro capas, en orden decreciente de atención
La capa en la que todos piensan. Mensajes, registros de llamadas, contactos, el carrete de fotos. Es realmente importante, es aquello de lo que suele depender el caso, y representa una pequeña fracción de la extracción en volumen. Es también la parte que todas las herramientas decodifican bien, porque es la parte para la que todas se construyeron primero.
Almacenamiento de aplicaciones. Cada aplicación instalada guarda su propio estado: bases de datos de mensajes y de sus metadatos, cachés de fotos de perfil, borradores, historial de notificaciones, historial de búsquedas, rastros de ubicación, estado de sincronización. Un teléfono con sesenta aplicaciones tiene sesenta de estos, con sesenta estructuras distintas, en varios formatos, algunos con versiones de formato y otros sin ellas.
Es la capa donde cada vez se encuentran las pruebas más interesantes, y donde la cobertura es más desigual. La herramienta del analista decodificará el almacenamiento de las aplicaciones que el proveedor implementó, y lo demás es un listado de directorio.
Rastros del sistema. El sistema operativo registra una cantidad notable de información sobre sí mismo en su funcionamiento normal: qué aplicaciones se ejecutaron y cuándo, a qué redes se conectó el dispositivo, cuándo se encendió, qué cuentas están configuradas, qué se abrió recientemente. Nada de eso se diseñó como prueba. Buena parte es muy buena prueba, porque es difícil de depurar y corrobora o contradice el relato humano.
Sedimento. Cachés de miniaturas, archivos temporales, registros de escritura anticipada que todavía conservan filas borradas de la base de datos principal, espacio no asignado con los restos de los registros eliminados. Es la capa donde se recupera el contenido borrado, y también donde el analista tiene que ser más cuidadoso, porque una fila recuperada y una fila activa tienen distinto peso probatorio y nunca deben presentarse como si fueran lo mismo.
El problema del volumen no es realmente un problema de volumen
Un teléfono insignia moderno produce una extracción de decenas o pocos cientos de gigabytes. Pero el almacenamiento es barato y la lectura es rápida, así que el tamaño bruto no es la restricción.
La restricción es que el contenido útil está repartido entre un gran número de formatos, la mayoría sin documentar, varios de los cuales cambian entre versiones de la aplicación que los escribió, y ninguno de los cuales se diseñó para que nadie más que la propia aplicación lo leyera.
Por eso la pregunta relevante no es lo grande que es una extracción. Es qué proporción de ella interpreta alguna herramienta. Todo lo demás está presente, es legible en principio e inutilizable en la práctica.
Adónde van las horas
Observe a un analista experimentado trabajar sobre una extracción y verá que la distribución del tiempo no es la que espera un ajeno.
Muy poco se va en leer mensajes. Gran parte consiste en averiguar qué partes de la extracción merecen de verdad ser leídas, y después dejarlas en un estado en el que sea posible leerlas. Abrir una base de datos desconocida, deducir qué significan sus tablas, descubrir que las marcas de tiempo están almacenadas en una época poco habitual, darse cuenta de que el cuerpo del mensaje está en una tabla y el participante en otra, sin una unión evidente. Ese es el trabajo.
Es también un trabajo cualificado que no deja nada duradero. La comprensión que un analista construye el martes sobre la estructura de almacenamiento de una aplicación vive en su cabeza o, en el mejor de los casos, en un archivo de notas personal, y tiene que volver a construirla la siguiente persona que se encuentre con la misma aplicación en otro servicio seis meses después.
La parte que nunca se examina
Todo laboratorio tiene una regla informal sobre hasta dónde llegar. Rara vez está por escrito y, por lo general, es sensata: examinar lo que la herramienta decodificó, examinar cualquier cosa que el investigador haya pedido expresamente, y anotar el resto como no analizado.
El resultado es una reducción constante e invisible del alcance. No es un fallo de diligencia, ni algo que una revisión del caso señalaría, porque el informe describe con exactitud lo que se examinó. Pero el efecto, sumado a toda la carga de casos, es que una gran fracción de los datos incautados nunca la mira nadie, y la fracción es mayor precisamente en las aplicaciones que un proveedor consideró comercialmente poco interesantes.
Qué cambiaría el panorama
Tres cosas podrían cambiar esto, ordenadas según la diferencia que marcan.
La primera es una cobertura que no dependa del calendario de publicaciones de otro. Si una aplicación desconocida puede estructurarse el día que el caso la necesita, la regla informal de alcance deja de eliminar cada vez las mismas categorías de pruebas.
La segunda es una búsqueda que funcione por significado y no solo por cadenas de caracteres. La mayor parte de una extracción resulta ilegible porque nadie tiene motivo para abrirla. Una pregunta formulada a la vez sobre todo el precinto encuentra ese motivo.
La tercera es una verificación lo bastante barata como para hacerse de verdad. Un analista que tiene que dedicar una tarde a confirmar de dónde procede un hallazgo confirmará menos hallazgos. Uno que puede hacerlo con un clic los confirmará todos, que es lo que el tribunal tiene derecho a esperar.
Esta última importa más de lo que parece. Hacer más rápida la revisión de pruebas solo es útil si no la hace también más superficial, y la única defensa contra eso es que la comprobación sea tan barata que saltársela no ahorre nada.
VERA
VERA es un software de análisis forense para dispositivos incautados. Estructura una extracción; después, el analista pregunta al precinto en lenguaje sencillo, incluido lo que muestra una imagen. Cada afirmación del asistente abre la fila de origen. Funciona sin conexión, en su propia infraestructura.
Solicitar accesoLecturas relacionadas
Verificar los resultados de la IA en el análisis forense digital: lo que un tribunal necesita ver
Un asistente de IA en una herramienta forense solo es utilizable si su resultado puede contrastarse con el registro original. Ese requisito no es un detalle de cumplimiento normativo: es la restricción de diseño de la que se deriva todo lo demás.
Por qué importa la infraestructura propia para los datos de dispositivos incautados
Para un laboratorio forense, ejecutar el software de análisis en su propia infraestructura no es una preferencia sobre la arquitectura informática. Suele ser la diferencia entre poder comprar un producto o no poder hacerlo.