$LogFile 1.1 frente a 2.0: qué cambió en Windows 8

TL;DR. Las dos versiones empiezan con dos páginas de reinicio RSTR. LFS 1.1 (Windows XP–7, y Windows 8+ tras un apagado limpio) va seguida de dos páginas de cola —copias de la página que se está escribiendo— y empieza el área circular en 0x4000 (páginas de 4 KiB). LFS 2.0 (Windows 8+ con el volumen montado) usa en su lugar 32 páginas rápidas y empieza el área circular en 0x22000. En una captura en vivo, los registros más recientes pueden existir solo en el área de cola o de páginas rápidas. Un analizador que la ignore pierde la actividad más reciente; uno que asuma la versión equivocada interpreta mal el archivo.

La versión está en la cabecera de la página de reinicio: versión menor en 0x1A, mayor en 0x1C (libfsntfs, ntfs3). Todo lo demás en este artículo se deriva de ese único número.

Las dos estructuras

Los desplazamientos son los que usa el controlador ntfs3 de Linux (first_page = major_ver >= 2 ? 0x22 * page_size : …), que reproduce ambas versiones.

Páginas de cola (1.1)

El LFS escribe los registros en la página actual del área circular. Reescribir esa página in situ con cada registro nuevo supone el riesgo de que una escritura interrumpida destruya registros ya confirmados en ella. LFS 1.1 se protege con dos páginas de cola: la página actual se escribe primero en el área especial y más tarde en su posición circular. Como describe dfir.ru, el área especial contiene dos copias de la página de registros actual.

Para el analista, la consecuencia es sencilla: la página más reciente de un diario 1.1 capturado en vivo puede estar más completa en el área de cola que en el área circular.

Páginas rápidas (2.0)

Windows 8 amplió el área especial a 32 páginas. En lugar de reescribir la página actual, el LFS escribe las páginas actualizadas en un hueco libre del área de páginas rápidas y solo más tarde en el área circular, lo que reduce las escrituras en esta. Las versiones anteriores de la misma página permanecen en el área rápida y pueden servir para la recuperación tras una escritura interrumpida (de nuevo según dfir.ru).

Cada página rápida lleva el desplazamiento en el archivo de la página circular que representa, en 0x3C de la cabecera RCRD (file_off en ntfs3, «used when major version >= 2»). Ese campo es lo que permite al analizador saber dónde encaja una página rápida.

Por qué una captura en vivo difiere de una imagen en frío

dfir.ru señala que la versión del diario se degrada a 1.1 durante un apagado limpio por defecto. Así, en la misma máquina con Windows 11:

El área de reinicio contiene además un flag que el analizador en el navegador interpreta como «desmontado limpiamente» (bit 0x2 de los flags del área de reinicio); en una captura en vivo o tras un fallo está a cero. Juntos, la versión y ese flag dicen mucho sobre cómo se adquirió la evidencia, algo que conviene anotar en el informe.

Qué debe hacer un analizador

1. Leer las dos páginas de reinicio, validar sus update sequence arrays y usar la que tenga el LSN actual más alto.
2. Tomar de ella la versión mayor y calcular dónde empieza el área circular.
3. Leer todas las páginas circulares.
4. Leer las páginas de cola o páginas rápidas, averiguar qué página circular representa cada una y sustituir la página circular cuando la copia especial sea más reciente.
5. Solo entonces buscar los registros, recomponiendo los que ocupan varias páginas o dan la vuelta desde el final del archivo hasta el inicio del área circular.

El analizador en el navegador hace exactamente esto e indica «N página(s) más reciente(s) leída(s) del área de cola / páginas rápidas» en su línea de cabecera. En su muestra sintética (LFS 2.0, capturada en vivo), una página procedía del área rápida; sin ella faltarían los últimos eventos de la intrusión ficticia. Todavía no extrae las copias antiguas de páginas que puedan quedar en el área rápida, una posible fuente de registros adicionales.

Errores habituales

• Fijar 0x4000 en el código. Un analizador que solo conoce 1.1, ejecutado sobre un diario 2.0, trata las páginas rápidas como páginas circulares y coloca mal o duplica registros.
• Ignorar el área especial. La página más reciente de una captura en vivo puede estar solo ahí.
• Dar por hecho 4 KiB. Los tamaños de página del sistema y del diario están en la cabecera de la página de reinicio (0x10, 0x14); léelos.
• Fiarse de una página CHKD. Una página de reinicio con la firma CHKD indica que chkdsk ha trabajado sobre el diario; trata su contenido con cautela.

dfir.ru menciona también una versión 3.0 prevista para volúmenes DAX, con sumas CRC32 en lugar de update sequence arrays. Ni el controlador de Linux ni el analizador de este sitio la soportan; si alguna vez ves la versión mayor 3, cuenta con que los analizadores rechacen el archivo.

Preguntas frecuentes

¿Qué versiones de Windows usan la versión 2.0 del $LogFile?

Windows 8 y posteriores usan el formato de diario 2.0 mientras el volumen NTFS está montado. Por defecto, el diario se degrada a 1.1 en un apagado limpio, así que una imagen de un disco Windows 10 u 11 apagado limpiamente puede mostrar 1.1 mientras que una captura en vivo muestra 2.0.

¿Por qué necesita un analizador conocer la versión del diario?

La versión determina dónde empieza el área circular de registros (0x4000 o 0x22000 con páginas de 4 KiB) y cómo se corresponden las páginas de cola o rápidas con las páginas circulares. Leer un diario 2.0 con supuestos de 1.1 trata las 32 páginas rápidas como registros normales y coloca mal los datos más recientes.

Lecturas recomendadas

• Maxim Suhanov, How the $LogFile works?: la fuente del comportamiento de 1.1/2.0 descrito aquí.
• Kernel de Linux, fs/ntfs3/fslog.c: log_init_pg_hdr, gestión de las páginas de cola y RECORD_PAGE_HDR.file_off.

Artículos relacionados

• El área de reinicio y los LSN del $LogFile, explicados
• Cómo adquirir el $LogFile de NTFS
• Análisis forense del $LogFile de NTFS: la guía completa