En este artículo abordaré la recuperación de mensajes borrado en la aplicación WhatsApp, como ya comente en la parte I y II, la capacidad de recuperación de mensajes eliminados es inversamente proporcional al periodo de tiempo transcurrido desde que se produjo el hecho, así como a la intensidad de uso de la aplicación en dicho periodo.
Es decir, cuanto mayor sea la intensidad y el tiempo transcurrido menor es la probabilidad de recuperar la información.
Recuperando mensajes eliminados de WhatsApp - Recovery Data
Si recordamos en la segunda parte, el timestamp de un mensaje consta de 6 bytes y se encuentra justo a continuación de los datos, tal y como se puede ver en la siguiente imagen:
 |
| ST2Labs 13 - Cell Data to Offset 11358 |
Pero antes de ponernos manos a la obra y decodificar el timestamp, se puede analizar la base de datos en busca de información eliminada, para ello, se deben de examinar el espacio sin utilizar (unallocated), los freeblock o incluso los freelist.
En las base de datos SQLite, existe la posibilidad de indicar que un registro (cell record) ha sido eliminado marcando el mismo como "freeblock" dentro de una página, además si se elimina una página entera, se puede marcar como Freelist.
La información residual que queda en una base de datos cuando no se sigue el estándar, es aquella que es eliminada desde la aplicación (chat) y simplemente se elimina su "indexación" en la base de datos, es decir, en aquel espacio que no esta asignado a ninguna función es denominado unallocated, y puede contener información que previamente ha sido eliminada, y que por tanto, no se encuentra indexada en la base de datos.
Por tanto resumiendo, la información eliminada puede estar ubicada en:
- unallocated space
- freeblock
- freelist
Además, si la base de datos es configurada con "rollback", puede existir archivos WAL (Write-Ahead Log) o Journal, que permite guardar una copia de seguridad de una página mientras esta se esta modificando y no ha recibido un "commit".
Si existe el fichero db-wal o db-journal, es muy recomendable realizar un análisis forense de dichos archivos, en busca de información relevante. Si existen esto archivos, no se recomienda abrir la base de datos con un visor de SQLite, ya que puede ejecutar un "commit" pendiente y borrar por completo toda la información que pudiera contener.
En nuestro caso, no disponemos de archivo db-wal, por lo que procedemos a analizar la información contenida en el archivo y que no esta consideraba como "válida", es decir, analizaremos todos los freeblock, unallocated y freelist que existan.
Realizar esta tarea de forma manual es bastante tediosa, ya que para cada página se debe de extraer la información que existe entre la ultima "celda - registro" y el final de Cell Pointer Array (como recordáis del artículo anterior".
Pero además, puede exisitr espacio "unallocated" entre celdas, y /o freeblock (son aquellas celdas que han sido marcadas como disponibles) al realizar la acción de eliminar mensajes.
Vamos con un ejemplo:
Abrimos la base de datos con un editor hexadecimal y analizamos el contenido de toda la página 3, ya que consideramos que es la más indicada al ser la que contiene la información de "mensajes". Si se ha eliminado algún mensaje debe de ser de esta página.
Datos de interés para la página 3, según la información analizada en el articulo 2:
- Offset page 3: 8192
- Ultima celda (registro) Offset: 11358
- Offset cell pointer: 8200
- Size Cell Pointer: 8 bytes
Por tanto, el espacio "unallocated" entre la utlima celda (registro) y el final de Cell Pointer Array se puede calcular tal que así:
Ini unallocated Offset = 8208
Size = 11358 - 8208 = 3150 bytes
Con ayuda de un editor hexadecimal, se obtiene:
 |
| ST2Labs 14 - Unallocated database pace for page 3 |
Se puede observar que existen varios mensajes como información residual en la página 3 de la base de datos, el key_id (identificador único de cada mensaje) esta compuesto por un "hash" y un número de secuencia, además con el timestamp de los mensajes se puede realizar el timeline correspondiente.
Por ejemplo, se procede a analizar la información para el mensaje:
 |
| ST2Labs 15 - Recovery Delete Message - Whatsapp
No existe una forma normalizada de finalizar un mensaje, para calcular el tamaño exacto del mensaje, se debe de decodificar el cell header y el payloda header, sin embargo, para los datos que han sido eliminado (no están indexados) no se conoce el offset de los registro eliminados, por lo que no se puede a priori determinar el inicio de la celda, salvo mediante técnica de prueba y error.
Por ello, obtener el timetamp, es coger los 6 bytes seguido al final del mensaje, para el caso de ejemplo, acaba sin ".", en otros casos puede que haya que probar más de una vez, por si el carácter "." forma parte del mensaje de texto o no.
|
En nuestro caso de ejemplo:
Timestamp: 01513407d3f8
Utilizando DFTime, la herramienta para convertir el timestamp a Fecha y Hora, se obtiene:
 |
| ST2Labs 16 - DFTime - Timestamp converter tools |
Sin embargo, para asegurarse que no existe ningún otro mensaje eliminado disperso por la base de datos, se debe de analizar los freeblock dentro de la página 3.
La información, si existen freeblock o no, se encuentra dentro de la cabecera de cada una de las páginas, con ayuda de la herramienta DFSLite, se puede consultar todas y cada una de las cabeceras de las páginas de la base de datos, con el comando -B.
 |
| ST2Labs 17 - Page header - freeblock |
Se analiza la información, y para la página 3 se detecta que existen 2 freeblock, donde el offset del primer freeblock es 3514 relativo a al offset de la página.
Se utiliza DFSLite, con la opción -u para obtener la información contenida dentro de los freeblock, y unallocated, tal que:
 |
| ST2Labs 18 - All messages recovery |
Se ha utilizado strings para visualizar mejor los mensajes, pues la herramienta muestra la información en bruto (raw data). No obstante, para determinar el timestamp de los mensajes y montar un "timeline", se debe de abrir el archivo en hexadecimal y analizar de forma manual, tal y como se ha visto en este artículo.
Para descubrir todos los mensajes se deberá de analizar todas las páginas de la base de datos, por tanto cuanto mayor sea la base de datos, mas elaborado y mayor será el tiempo que se tardará en obtener los resultados.
Espero que haya sido de utilidad, a continuación os dejo el enlace al repositorio donde voy subiendo las herramientas.
DFTime Tools
Se puede descargar la herramienta desde el repositorio oficial de ST2Labs (https://github.com/ST2Labs/DFIR/tree/master/SQLite)
#ST2Labs
#GEOSystemSoftware
www.st2labs.com | www.seguridadparatodos.es
PD: El análisis de las freelist page os lo dejo como "trabajo" para casa. :) Al igual que realizar un análisis manual de los freeblock.
