Cómo ocultar datos en un disco duro de (casi) cualquier pericial informático forense, sin usar cifrado ni esteganografía
Read in English…
Todo eso ya lo conocemos, por lo que ¿qué nos trae hasta este recurrente tema esta vez?
Primero, vamos a poner a todo lector interesado en antecedentes. Vamos a empezar hablando (brevemente) sobre los análisis informático forenses o periciales forenses; continuaremos hablando sobre algunos aspectos del funcionamiento interno de un disco duro tradicional; pasaremos a hablar de las clonadoras de discos y el mito generalizado que existe sobre su funcionamiento; posteriormente hablaremos de la potencial forma de ocultar datos en discos duros de la que queremos dar cuenta, y terminaremos con una pequeña prueba de concepto en la que vamos a ocultar y recuperar datos de un disco duro usando la técnica propuesta.
Sobre los análisis informático forenses
Todo buen investigador sabe que la alteración de una prueba es de las cosas más graves en las que puede incurrir como investigador que es. Esto no es diferente cuando se trata de una investigación que concierne al contenido del disco duro de un ordenador: del mismo modo que un médico forense utiliza guantes para recoger y estudiar evidencias, y otros mecanismos para evitar contaminación en las pruebas, un investigador informático forense debe asegurarse muy bien de que al acceder al disco duro, no cambia absolutamente nada de su contenido.
Sin embargo, como ya sabemos, hay un problema. Acceder a un disco duro puede parecerse demasiado a la mecánica cuántica: El mero hecho de observar el sujeto, lo modifica. Esto ocurre en situaciones normales porque, al montar la unidad para poder navegar por su contenido, se modifican constantemente fechas de último acceso a ficheros, además de que se escribe (si lo hay) en el fichero o espacio de paginación, y suceden otros cambios que escapan completamente a nuestro control. Por todo ello, las investigaciones forenses rara vez se hacen sobre el disco duro original; en cambio, se hacen sobre una copia (que puede darse en varios formatos) y se deja el original precintado y a buen recaudo, conservando la cadena de custodia. Cuando no hay tiempo para obtener la copia, o por algún motivo no se puede, se puede trabajar usando un bloqueador de escritura, que garantice que cualquier intento de escritura será frustrado o desviado del disco duro.
Es importante recalcar el hecho de utilizar la copia, o métodos convencionales de acceso al disco duro si se trata del original, para el caso que nos trae.
Sobre el funcionamiento interno de un disco duro convencional
Muchos de nosotros nos hacemos una idea general, bastante acertada, de cómo funciona un disco duro. Sin embargo, los inners de los mismos suelen escapar incluso a la gente del mundo de las TI, que (en muchos casos) damos muchas cosas por sentadas.
Así pues, ¿Qué es posible que no sepamos de un disco duro? Un disco duro es una máquina mucho más inteligente de lo que casi todo el mundo piensa. Es un ordenador en pequeño, con casi todas las funcionalidades que un ordenador tradicional. A parte de los datos del usuario y la estructura física del mismo (placa electrónica, platos magnéticos, cabezas de lectura y escritura montadas sobre unos brazos mecánicos, etc.), un disco duro tiene su propio sistema operativo, su propio y pequeño sistema de ficheros, su propia memoria RAM, su propia memoria ROM, su secuencia de arranque, e, incluso, un terminal UART (serie) con el que nos podemos comunicar para realizar muchas tareas, principalmente de comprobación y de mantenimiento.
Nos enfocaremos en dos piezas clave en el funcionamiento de un disco duro de especial relevancia para este artículo: la memoria ROM del disco duro, y el Área de Servicio.
- La memoria ROM. Contiene el firmware, código principal de funcionamiento o microcode del disco duro. En algunos modelos de la mayoría de los fabricantes, además, puede almacenar cierta información que en su conjunto se conoce como parámetros adaptativos, que son ciertos parámetros de funcionamiento únicos para cada disco en el mundo. Está almacenada, como su propio nombre indica, en una memoria de tipo ROM o Flash, que puede ser un chip aislado del disco duro (generalmente de 8 pines), o, en modelos más modernos, puede estar embebido en el mismo encapsulado del microcontrolador principal.
- El Área de Servicio o SA. Contiene información imprescindible para el funcionamiento del disco duro. Parte de esta información consiste en parámetros adaptativos, como algunos de los que se almacenan en la ROM, y otra parte consiste principalmente en tablas de sectores defectuosos de fábrica (normalmente conocida como P-List o Primary List), tablas de sectores defectuosos post-formateo de fábrica (dependiendo del fabricante, pueden aparecer como G-List o A-List —Growing List y Adaptative o Reassigned List, respectivamente—, entre otros nombres), y la tabla de traducción o Translator (que traduce los LBA’s que se presentan al mundo exterior en el formato de direccionamiento CHS —Cylinder, Head, Sector—, teniendo en cuenta los sectores marcados en las tablas P-List y G-List, y los sectores que se toman prestados de las zonas de reserva).
Está contenida en los propios platos magnéticos en lo que se conoce como los cilindros negativos, normalmente en la superficie 0, y, dependiendo del fabricante, replicada en el resto de superficies.
Teniendo presentes estas dos piezas de la estructura funcional de un disco duro, podremos comprender mucho mejor todo lo que viene a continuación.
Las clonadoras de discos duros
Estos aparatos de uso extendido en las investigaciones forenses sirven para realizar una copia de un disco duro a una velocidad decente, en modo “protección contra escritura”, y dificultando la opción de “equivocarse” copiando el disco duro nuevo sobre el que se pretende investigar.
Más allá de las tremendas velocidades que prometen (de hasta 12 GB por minuto), que no he llegado a ver en ningún caso de discos duros convencionales (aunque las copias entre SSD’s tengo noticias de que llegan hasta los 19 GBpm, con B de byte), muchas prometen realizar copias absolutas (“clones”), realizados bit a bit asegurando una total y absoluta protección contra escritura. Bueno, pues permitidme decir que esto no es así realmente.
En primer lugar, porque las copias son sector a sector, o más correctamente, LBA a LBA. No es posible indicar al disco que lea un único bit; por el contrario, se le debe indicar que lea un LBA o un grupo de LBA’s a la vez. A parte de la eficiencia que supone, hay que tener en cuenta que los códigos de comprobación de errores (CRC, ECC) son a nivel de sector, por lo que es necesario leer un sector al completo para poder comprobar si lo que se ha leído es válido o no.
En segundo lugar, las copias no son absolutas. Solo se copia la zona de usuario y se hace a nivel de LBA. ¿Qué significa esto? Profundicemos un poco: Hemos mencionado el Translator ya. Recordemos que un disco duro consta a nivel geométrico de cilindros, pistas y sectores. Cada pista tiene un determinado número de sectores de reserva, que pasan a ser utilizados en caso de que algún sector no pase los “tests de calidad”. ¿Qué ocurre, ya el disco en modo “usuario”, cuando el sector K es marcado como defectuoso, y pasa a ser utilizado uno que está geométricamente ubicado en un lugar diferente? Si las cosas no estuvieran concienzudamente estudiadas, el sector K habría desaparecido dejando un agujero que bien podría provocar la pérdida absoluta de consistencia de un sistema de ficheros que se situase sobre toda la estructura, de modo que después del sector K-1 iría el sector K+1. El disco duro soluciona este problema rellenando el hueco con un sector de reserva de los que hay que cada pista, de forma casi transparente al exterior. “Casi”, porque el rendimiento del disco cae a medida que se reubican sectores, al tener que ir a zonas geográficamente distintas para extraer los datos. ElTranslator se encarga de hacer transparente esta reubicación, actuando de intermediaro entre los sectores físicos (P-CHS y L-CHS) y unos virtuales, conocidos como LBA, que son lo que se presentan al host. Dependiendo del caso (sectores que no pasan el test de calidad en fábrica, o durante el funcionamiento posterior), el Translator puede consiguir que, si el sector K-1 tiene un LBA 560, el K+1 tenga el LBA 561, o que el sector K+X (uno de reserva) adopte el LBA 561 y deje al K+1 con su antiguo LBA 562. Esto depende del momento en el que se haya detectado el fallo.
Volviendo a la copia, ésta se hace solamente sobre los LBA, por lo que solo se copiarán los sectores que tengan asignados un LBA en el estado actual del disco duro. El mismo disco duro se encarga de ocultar el resto de sectores al exterior, porque, o bien son de reserva, o bien están marcados como defectuosos. El pitfall empieza a dejarse ver.
Por otro lado, hay dos cosas que no se copian en absoluto: La memoria ROM, y el Área de Servicio. Esto, naturalmente, tiene su lógica: Contienen datos que solo son relevantes para cada unidad de disco duro que existe en el mundo, además de contener datos que solo son útiles para cada fabricante y modelo. Si uno intentase sobreescribir el área de servicio de su disco duro con la del disco que pretende clonar, con toda probabilidad terminaría uno con un disco inservible entre manos. Hay que tener presente que las superficies magnéticas de los discos duros no son una ciencia exacta y presentan irregularidades, desperfectos e impurezas que las hacen completamente únicas, por lo que cada superficie debe ser individualmente preparada (pistas de servo, bandas de corrección de ganancia, etc.) y formateada a bajo nivel, y debidamente testeada en busca de zonas con irregularidades, que quedan registradas en la P-List en fábrica.
Y, en tercer lugar, la protección de escritura tampoco es tal. Lo es, para la zona de datos de usuario. Pero no para el área de servicio o la ROM: Los logs se siguen escribiendo, los sectores se siguen “recolocando”, las tablas de defectos evolucionan, y cualquier información de la que maneja internamente el disco duro es libre de ser modificada o borrada en cualquier momento y sin previo aviso.
Con todo esto no quiero decir que no sea útil una clonadora; son cómodas y rápidas, pero nos dan la misma visibilidad del disco (sumando en ocasiones HPA’s y DCO’s) que nos da nuestro sistema operativo, y, ciertamente, protegen de lo que tienen que proteger y copian los datos de la manera más lógica de cara a acceder a ella en las mismas condiciones que desde el disco duro original.
Ocultando datos en el disco duro
Ahora viene lo interesante. Vamos a hablar de dos técnicas que nos permitirían guardar datos en un disco duro, evitando que los mismos fuesen copiados en cualquier proceso de clonado de discos duros, dejándolos por tanto totalmente fuera de la vista del investigador forense que usa “clones” en sus investigaciones. Tampoco quiero que suene muy sensacionalista: Hacer esto requiere de ciertos conocimientos avanzados y específicos, herramientas especializadas o un conocimiento profundo de los comandos de terminal de cada fabricante y familia de discos duros (que permita prescindir de las otras herramientas), y no es en absoluto práctico. Debido a ello, el uso de esta técnica prácticamente quedaría limitada a la ocultación de datos específicos y muy concretos y controlados; por ejemplo, la receta de la Coca-Cola, o las claves de acceso a Zion, pero quedaría fuera del alcance de algo de uso frecuente.
Las dos técnicas propuestas consisten en:
- Guardar un fichero en una zona cualquiera del disco (a), acceder vía terminal (usando una herramienta con built-in commands) al área de servicio del disco duro (b), y marcar los sectores que ocupa el fichero como defectuosos en la P-List o la G-List. Posteriormente, comprobaremos los resultados con un visor de sectores (LBA).
- Escribir directamente en el área de servicio, en alguno de los módulos no críticos para el funcionamiento del disco. Conocer los módulos críticos y los que no lo son es otro cantar, pero nosotros que los conocemos, os enseñaremos más adelante cómo hacerlo en uno de ellos. Esta misma técnica se puede usar para sobreescribir módulos no críticos de la ROM.
Para la prueba de concepto, hemos optado por el caso primero.
MARCANDO SECTORES COMO DEFECTUOSOS
Antes de comenzar, quiero aclarar que existen sectores defectuosos a la vista del sistema de ficheros (que pueden ser sectores con LBA asignado) y por tanto del host, y sectores defectuosos que solo están en conocimiento del propio disco. Los primeros, se registran en bloques completos del tamaño de la unidad mínima de asignación (un clúster) en una tabla cuyo formato y nombre dependen del sistema de ficheros (en NTFS, $BadClus, con cada bit representando el estado de cada clúster de la partición); y los segundos, se registran en las tablas del Área de Servicio ya mencionadas, P-List y G/A/S-List.
Material que usaremos:
- Una tarjeta especializada de Data Recovery, con interfaz ATA que, junto con otra utilidad software, nos va a permitir acceder a y modificar el área de servicio de un disco duro. Se conecta a través del puerto serie del disco duro, para enviar los comandos que lleva programados (desbloquear el acceso al área de servicio, leer módulos, escribir módulos, etc.). Como ya hemos dicho, es prescindible, pero facilita el trabajo al haber muy pocas referencias sobre los comandos de terminal de los discos duros (que, sorprendentemente, tienen un comando help, que depende de cada fabricante y modelo, aunque no suele dar mucha información). Para la conexión por un terminal serie convencional, podéis echar un ojo a un post anterior de este blog: //hard2bit.com/blog/?p=33
- Un disco duro. Usaremos un Samsung algo antiguo, modelo SV2001H.
- Un ordenador con conexión a un puerto serie y un programa de hyperterminal.
- Un visor y editor hexadecimal.
Para empezar, necesitamos acceder al área de servicio. Eso no es sencillo. En algunos modelos de algunos fabricantes, ni siquiera circula información sobre cómo hacerlo. Además, teniendo herramientas, cada familia de discos duros, de cada uno de los fabricantes, responde a un juego de comandos distintos, tampoco documentados abiertamente por supuesto, y conocer los comandos que dan acceso al área de servicio y saber cómo usarlos puede llegar a ser todo un auténtico misterio. Del Samsung que usaremos, se accede al help desde el terminal escribiendo HE en el prompt, que debe mostrar las letras ENG>. Se puede entrar al modo debug presionando el escape, cambiando el prompt a DBG>. Como digo, nosotros usaremos una herramienta que nos ahorra trabajo aquí.
Cómo planteamos la prueba de concepto:
- Hemos marcado un sector K (LBA) con su número de sector actual y la palabra PREVIO usando un editor hexadecimal con accedo en crudo al disco.
- Hemos escrito información importante en el sector K+1.
- Hemos marcado el sector K+2 con su número de sector y la palabra POSTERIOR.
Hemos usado el valor K=50, por lo que hemos usado sectores que normalmente no se particionan dado que suele hacerse la primera partición a partir del LBA 63 o el 2048.
Así es como está nuestro disco ahora:
Ahora, a través de la herramienta, obtenemos las tablas de defectos del disco duro. Se muestra a continuación parte del contenido de la S-List, que indica la zona (que agrupa áreas consecutivas de lectura y escritura), cabeza, cilindro y sector que han sido marcados como defectuosos y excluidos del conjunto de sectores que presenta el disco duro al exterior:
Ahora, usando la utilidad, añadimos un nuevo registro a la S-List. Tenemos un problema aquí, y es que no sabemos cómo ocultar el sector LBA 51 si tenemos que especificar su ubicación en PCHS, que es como hay que hacerlo. Los cálculos pueden hacerse un tanto complicados porque hay que tener en cuenta todos los defectos encontrados en el disco, y cómo está tratándolos el Translator, para averiguar en qué cabeza, cilindro y sector físico estamos ubicados.
En este caso, hemos usado la utilidad (de nuevo, un comando del terminal) para averiguar el tamaño de la SA, que ha resultado ser de 8 cilindros (de los que ocupa solo 3). Por lo tanto, y tentando a la suerte un poco, hemos forzado un nuevo sector defectuoso, el 8:0:52, que coincidiría con el sector 0:0:52 en formato LCHS, y, como CHS comienza con el 1, sería el sector 51 de la zona de usuario.
Si hay suerte, y no tenemos otras reubicaciones o defectos (cosa que parece, a la luz de la tabla de defectos), habremos “ocultado” el sector LBA 51. Y, efectivamente: Apagando el disco y volviéndolo a encender (para que tenga efecto el sector añadido a la tabla), y visualizándolo con un editor hexadecimal, vemos:
Ya tenemos el sector oculto. Solo para que quede claro, repetimos que no hay manera de ver ese sector de nuevo desde más allá de la interfaz ATA, sin volver a habilitarlo en el área de servicio. Cualquier intento de verlo desde un PC será frustrado, al ser el propio disco que lo ha ocultado de la existencia: El sector siguiente lo ha reemplazado, y todos los LBA se han desplazado exactamente una posición hacia atrás.
Para terminar la prueba de concepto, hemos eliminado de la tabla el sector oculto, para ver si podemos recuperar los datos del disco duro. Que nadie piense que hay trampa; el sector ha vuelto sano y salvo:
¡Ahí lo tenemos! Cierto es que con un poco más de tiempo, se habría podido ocultar un fichero de cierto tamaño, habiendo calculado bien las posiciones absolutas de cada LBA implicado.
También puede ser de interés…
Ya hemos visto que una copia de un disco duro, y la forma en que el disco duro se presenta al sistema, funciona a nivel de LBA. Es interesante tener en cuenta para un análisis forense muy minucioso la posibilidad de que durante el uso normal del disco, es habitual que algunos sectores hayan sufrido un error de lectura en un momento determinado y hayan sido incluidos en la G-List, y reubicados en caso de existir posibilidad de ello. Cualquier operación que haya sufrido un disco duro a posteriori, incluido un borrado seguro [lógico] de cualquier nivel (DoD 5220.22-M, Schneier, Gutmann, etc.), no habrá tenido en cuenta los sectores sin LBA asignado, por lo que es posible aún recuperar algo de información de ellos. Cierto es que, si estaban marcados como defectuosos, no será fácil extraer algo de ellos: a veces, están bien (solo tuvieron un mal día, o un tiempo de lectura o escritura demasiado alto), y a veces, con el comando de lectura adecuado, se pueden ignorar los CRC/ECC e inspeccionar visualmente el sector leído, con la suerte de que solo un par de bits estén invertidos. Hablaremos de ello en nuestro próximo post.
Cualquier comentario, por favor, sin dudarlo.
Hard2bit Data Forensics
Este post es simplemente genial… felicidades.
Excelente post, muy didactico.
Está claro que sois unos profesionales….un post genial¡
Muy bueno! Enhorabuena.
Muy buen post. Realmente se trata de un método para ocultar información para nada trivial, pero muy muy interesante.
Buen artículo.
Esto es lo que se llama informática forense…
Alucino pepinillos…este post está genial!
Excelente material
Sin desmerecer el artículo, solo le falto algo de referencias a fin de que el lector pueda crecer.
Ya los tengo en mis favoritos. >-<
Hola Eduardo,
Gracias por el comentario. Intentaremos introducir referencias en el futuro, que es cierto que lecturas profundas lo agradecen. En este caso la mayor parte del trabajo es investigación nuestra (no queriendo decir con ello que no existan referencias ya), por lo que no podemos meter tantas como nos gustaría.
De todos modos, tienes razón y trataremos de hacerlo. ¡Un saludo y muchas gracias!
He leido esta manera de ocultar datos con mucho interes y me ha parecido didáctico además de claro en su contenido. No dejeis de cuidar este blog, es bueno.
Es muy interesante esta técnica antiforense… muy bueno el articulo. Saludos.
Genial, ahora ya sé dónde meter el… pero un momento, no cabe!
Excelente trabajo. Habéis planteado la posibilidad de extenderlo a dispositivos flash?
Buenas tardes,
Estamos trabajando en ello 😉 publicaremos algo al respecto en un futuro cercano.
Un saludo y muchas gracias.
Una información muy completa y rigurosa, enhorabuena 😉
Quisiera hacer una honesta consulta, mi disco duro fue formateado, previamente recibió tratamientos constantes con CCLEANER usando la categoría de mayores pasadas. Por equivocación, previo al formateo de mi disco, yo dañe por cambiar el nombre una base de datos Lotus Notes, pedí en mi empresa la recuperación de la misma y dijeron que era imposible. Previo a eso había solicitado el mantenimiento del equipo ya que uso aplicaciones que requerían java actualizado y el mismo, por razones desconocidas regresaba a la versión original. Hicieron respaldo de mi información, formatearon el disco, instalaron Java actualizado y devolvieron la data. Pese a todo esto ¿Aún es posible recuperar la base de datos de Lotus Note? Me urge su respuesta y me disculpo por mi ignorancia y probable mala redacción de los hechos. Saludos cordiales
Buenos días Mistik,
¿La base de datos estaba contenida en el disco duro anterior o posteriormente a haber realizado un borrado seguro con CCleaner? Es decir, ¿la base de datos se borró, junto con el resto del disco, de forma segura usando CCleaner (y luego se formateó)? ¿O la base de datos se ha perdido únicamente por el formateo + posterior escritura en el disco duro? En caso de que la base de datos formara parte de la información sobreescrita con CCleaner, me temo que las posibilidades son prácticamente nulas. En el segundo caso, se podría recuperar algo, aunque cada caso requiere un análisis.
Excelente artículo!! O mejor dicho material “didáctico” o tutorial. Es como todo…depende en manos de quien esté…