Las operaciones redo/undo del $LogFile de NTFS, explicadas

TL;DR. Un registro del diario de NTFS es una cabecera LFS (LSN, LSN anterior, id. de transacción…) seguida de una cabecera NTFS: opcode redo, opcode undo, dónde están los bytes redo y undo, a qué atributo abierto se refieren y en qué punto de él. Existen treinta y ocho opcodes (0x00–0x25), pero unos pocos concentran casi todo el valor forense: InitializeFileRecordSegment, DeallocateFileRecordSegment, CreateAttribute / DeleteAttribute, UpdateResidentValue y las cuatro operaciones Add/DeleteIndexEntry*. Todo lo demás es contabilidad interna que, aun así, necesitas para resolver los destinos y agrupar los registros.

Si $LogFile te parece opaco es porque una sola acción del usuario —«renombrar este archivo»— se convierte en varios registros, y cada uno solo tiene sentido con el contexto adecuado: qué atributo está abierto con qué índice, qué tamaño de clúster usa el volumen, cómo era el registro FILE antes. Este artículo es la tabla de descifrado. La visión de conjunto está en Análisis forense del $LogFile de NTFS: la guía completa.

Dos cabeceras por registro

Todo registro del diario empieza con la cabecera de registro LFS, seguida de los datos del cliente. En el caso del cliente NTFS, esos datos empiezan con su propia cabecera. Desplazamientos tomados del fslog.c de ntfs3 de Linux:

Cabecera de registro LFS (0x30 bytes)

Cabecera del registro NTFS (inicio de los datos del cliente)

Los registros de tipo 2 son checkpoints (áreas de reinicio del cliente), no cambios. Los trata el artículo $LogFile: el área de reinicio y los LSN, explicados.

Encontrar la entrada de la MFT que toca un registro

Los registros no dicen «entrada 322 de la MFT». Dicen «atributo n.º N de la tabla de atributos abiertos, VCN v, desplazamiento de bloque de clúster c». Cuando el atributo destino es $MFT:$DATA, la entrada es:

entry = (VCN × cluster_size + cluster_block_offset × 512) / mft_record_size

Hacen falta dos parámetros del volumen. Un analizador puede tomarlos del sector de arranque o, como hace el analizador de $LogFile en el navegador, calibrarlos a partir del propio diario: los registros InitializeFileRecordSegment contienen una imagen completa de un registro FILE cuya cabecera indica su propio número de registro, así que gana la combinación de tamaño de clúster y tamaño de registro que ubica correctamente la mayoría de ellos.

La tabla de atributos abiertos se reconstruye a partir de los registros OpenNonresidentAttribute y de los OpenAttributeTableDump y AttributeNamesDump escritos en cada checkpoint. La estructura de sus entradas varía según la versión del cliente NTFS (0x28 frente a 0x2C bytes), y ese es uno de los puntos en los que los analizadores pueden discrepar.

Las 38 operaciones, agrupadas

Los nombres siguientes son los del enum NTFS_LOG_OPERATION de ntfs3, que también usa el analizador.

El undo suele ser el inverso del redo: AddIndexEntryRoot se deshace con DeleteIndexEntryRoot, CreateAttribute con DeleteAttribute, SetBits… con ClearBits…, y UpdateResidentValue con otro UpdateResidentValue que lleva los bytes antiguos. Las operaciones cuya reversión no necesita nada, como inicializar un registro FILE nuevo, suelen tener Noop como undo.

Cómo se ven las acciones habituales

Estos son los patrones que busca un analizador. Las secuencias reales contienen más registros (bitmaps, tamaños, seguridad, escrituras USN) y el orden exacto puede variar según la versión de Windows.

Creación de un archivo

• InitializeFileRecordSegment sobre la nueva entrada. Redo = imagen completa del registro FILE: cabecera (número de secuencia, flags), $STANDARD_INFORMATION, $FILE_NAME (nombre, referencia del padre, cuatro horas) y quizá un $DATA pequeño.
• AddIndexEntryRoot o AddIndexEntryAllocation en el índice $I30 de la carpeta padre. La entrada de índice incluye una copia de $FILE_NAME.

Borrado

• DeleteIndexEntryRoot / DeleteIndexEntryAllocation, que quitan el nombre de la carpeta padre (la entrada eliminada está en los bytes undo, a veces en los redo).
• DeallocateFileRecordSegment sobre la entrada, con ClearBitsInNonresidentBitMap sobre el bitmap de la MFT.

Renombrado o movimiento

• dfir.ru documenta un renombrado como DeleteIndexEntryRoot, DeleteAttribute ($FILE_NAME antiguo), CreateAttribute ($FILE_NAME nuevo), AddIndexEntryRoot (How the $LogFile works?). Un movimiento es lo mismo con otra carpeta padre en la entrada añadida. En carpetas grandes aparecen las variantes …Allocation en lugar de …Root.

Cambio de marca de tiempo

• UpdateResidentValue sobre el atributo $STANDARD_INFORMATION (el primer atributo de un registro FILE, en el desplazamiento 0x38 en los registros de NTFS 3.1). El redo contiene los bytes nuevos; el undo, los antiguos. La actualización puede ser parcial —dfir.ru señala que puede empezar en la marca M—, así que un analizador debe usar el desplazamiento de atributo para saber cuál de las cuatro horas está leyendo. Detectar timestomping con el $LogFile de NTFS se basa en esto.

Contenido de archivos pequeños

• Un atributo $DATA residente creado con CreateAttribute o incluido en la imagen del registro FILE puede llevar los primeros bytes de un archivo pequeño. Las ediciones posteriores son otra historia: la documentación de LogFileParser indica que, en Windows moderno, el contenido de los cambios en datos residentes no suele guardarse, solo el hecho de que hubo un cambio. Consulta $LogFile: recuperar evidencias de archivos borrados.

Agrupar registros en acciones

Dos enfoques:

1. Por transacción. Usar el id. de transacción y la cadena de LSN anteriores, delimitada por registros ForgetTransaction o de confirmación. Es el más fiel, pero más difícil de hacer bien a través de los checkpoints.
2. Por entrada de la MFT y proximidad. Tomar los registros que tocan la misma entrada dentro de una ventana de LSN. Es más sencillo y resiste mejor las páginas dañadas, pero dos acciones sin relación sobre el mismo archivo, muy seguidas, pueden fusionarse.

El analizador en el navegador usa por ahora el segundo enfoque (una ventana de ±256 registros por entrada de la MFT) y expone cada registro en bruto para que puedas comprobar la agrupación. La agrupación por transacciones está en su hoja de ruta; conviene usar LogFileParser y NTFS Log Tracker para confirmar.

Leer los bytes uno mismo

Cuando un evento importa, abre el registro en bruto: comprueba los opcodes redo/undo, el atributo destino (por ejemplo #322:$STANDARD_INFORMATION o $MFT:$DATA), el desplazamiento de registro, el desplazamiento de atributo y el hexadecimal. Un undo de 32 bytes en el desplazamiento de atributo 0 de $STANDARD_INFORMATION contiene cuatro valores FILETIME en little-endian: creación, modificación, cambio MFT y acceso.

Preguntas frecuentes

¿Qué son las operaciones redo y undo del $LogFile?

Cada registro del diario de NTFS describe un cambio de metadatos dos veces: la operación y los bytes redo indican cómo volver a aplicar el cambio, y la operación y los bytes undo, cómo revertirlo. La recuperación reaplica redo en las transacciones confirmadas y aplica undo en las no confirmadas.

¿Qué operaciones del $LogFile muestran la creación o el borrado de un archivo?

Una creación suele mostrar InitializeFileRecordSegment sobre el nuevo registro FILE más AddIndexEntryRoot o AddIndexEntryAllocation en la carpeta padre. Un borrado muestra DeleteIndexEntryRoot o DeleteIndexEntryAllocation seguido de DeallocateFileRecordSegment.

Para saber más

• Kernel de Linux, fs/ntfs3/fslog.c: definiciones de las estructuras y una implementación completa de la reproducción del diario.
• Joakim Schicht, readme de LogFileParser: qué operaciones decodifica y qué contienen.
• Maxim Suhanov, How the $LogFile works?

Artículos relacionados

• $LogFile: el área de reinicio y los LSN, explicados
• Detectar timestomping con el $LogFile de NTFS
• Cómo analizar un $LogFile de NTFS paso a paso