¿Hasta dónde llega el $LogFile? Límites y trampas
Retención real del $LogFile de NTFS y sus otros puntos ciegos: sin reloj, sin nombres, solo metadatos, reescrito por chkdsk o ntfs-3g, parsers discrepantes.
TL;DR. $LogFile es un búfer circular de unos 64 MiB en la mayoría de los volúmenes actuales. En una unidad de sistema con mucha actividad eso equivale a de minutos a horas de historial; en una unidad secundaria o extraíble puede ser mucho más. Además de la retención, tiene cuatro puntos ciegos estructurales: no hay hora de reloj, los nombres solo aparecen cuando cambian, solo metadatos (nada de contenido no residente) y fragilidad (chkdsk, ntfs-3g y tu propia actividad lo reescriben). Además, los analizadores discrepan en los detalles. Úsalo para la última ventana de actividad y combínalo con el diario USN, el $MFT y las instantáneas de volumen.
Nada de esto hace que el diario sea menos útil. Lo convierte en un instrumento preciso de corto alcance, y los informes que olvidan ese alcance acaban siendo cuestionados.
Retención: cómo son las cifras
| Factor | Efecto |
|---|---|
| Tamaño del diario | Por defecto suele rondar los 64 MiB en los volúmenes Windows actuales; chkdsk /L lo muestra o lo cambia (Microsoft Learn). Los volúmenes antiguos o pequeños pueden tenerlo menor: el propio ejemplo de chkdsk de Microsoft muestra 22.544 KB (KB 814594) |
| Actividad de metadatos | Cada creación, renombrado o borrado de archivo y cada cambio de atributo o de índice consume espacio del diario. Navegadores, actualizaciones, análisis antivirus, indexación y SRUM generan actividad constante |
| Función del volumen | Los volúmenes de sistema son los que más actividad tienen; los de datos y extraíbles, los que menos |
| Checkpoints | Los volcados de tablas escritos en cada checkpoint también consumen espacio |
Observaciones publicadas:
- Maxim Suhanov midió el tiempo que tardan en sobrescribirse los datos antiguos en Windows 10: 16 minutos en una prueba, 5 horas y 20 minutos en otra (How the $LogFile works?).
- El readme de LogFileParser de Joakim Schicht habla de «unas pocas horas» en una unidad de sistema de uso frecuente y de mucho más en discos externos o secundarios.
- TZWorks describe unas pocas horas de actividad con un uso normal para un diario de 64 MB (mala).
Tómalas como órdenes de magnitud. La única cifra fiable es la de tu evidencia: el rango de LSN que da el analizador y el evento fechado más antiguo.
Obtener más historial
- Adquiere pronto. Antes del triaje que consume mucha memoria y antes de copiar herramientas al equipo.
- Todos los volúmenes. Una memoria USB o un volumen de datos pueden conservar todavía lo de ayer.
- Instantáneas de volumen (VSS). Cada instantánea contiene un
$LogFilemás antiguo. Analiza cada una y etiquétala con la hora de la instantánea. - Preparación. En los sistemas que administras, un diario más grande (
chkdsk C: /L:<tamaño en KB>) conserva más historial. El readme de LogFileParser dachkdsk D: /L:2097152como ejemplo para 2 GB. Prueba antes el impacto en el rendimiento y no lo hagas nunca en un sistema que vayas a adquirir.
Punto ciego 1: sin reloj
Los registros del LFS llevan LSN, no horas. Cualquier hora que muestre un analizador procede del interior de los datos registrados:
| Evento | Origen de la hora | Fiabilidad |
|---|---|---|
| Creación | Creación de $FILE_NAME en el registro FILE o en la entrada de índice | Buena |
| Renombrado / movido | Cambio de $FILE_NAME | Buena |
Cambio de $SI | Nuevo valor de $SI | Buena, salvo que se haya antedatado (timestomping) |
| Borrado | Última hora conocida del archivo | Solo cota inferior |
| Cualquier otro | Vecino fechado más cercano (≈) | Aproximada |
Por eso el analizador de $LogFile en el navegador etiqueta cada evento con el origen de su hora. Para obtener horas exactas, correlaciona con $UsnJrnl:$J (analizador del diario USN) y compara los artefactos.
Punto ciego 2: los nombres no siempre están
La mayoría de los registros designan una entrada de la MFT, no un archivo. Los nombres aparecen cuando se añade o elimina una entrada de índice (creación, renombrado, borrado) o cuando se escribe un registro FILE completo. Un cambio de marca de tiempo en un archivo creado la semana pasada viene solo con un número de entrada. El $MFT del mismo volumen resuelve el resto; sin él, las rutas empiezan por [MFT #n]. Si el $MFT se adquirió después que el diario, las entradas reutilizadas pueden resolverse con nombres equivocados: comprueba los números de secuencia.
Punto ciego 3: solo metadatos
- El contenido no residente de los archivos nunca pasa por el diario.
- Los archivos pequeños y residentes pueden aparecer en imágenes de registros FILE o en creaciones de atributos. La documentación de LogFileParser añade que, en Windows moderno, los cambios posteriores en datos residentes no suelen registrarse con su contenido.
- Las lecturas de archivos no se registran (las actualizaciones del último acceso son metadatos, pero a menudo están desactivadas o diferidas).
Punto ciego 4: es fácil de destruir
- Tu propia actividad. Cada archivo que escribes en el volumen de la evidencia añade registros al diario.
- chkdsk. Puede modificar o redimensionar el diario; una página de reinicio con la firma
CHKDlo delata. - ntfs-3g en Linux. Si se le pide montar con su opción de recuperación un volumen que no se cerró limpiamente, ntfs-3g «vacía» el diario rellenándolo con
0xFF(ntfs_logfile_reseten libntfs-3g). Conecta siempre la evidencia en solo lectura. - Apagado forzado frente a apagado limpio. Un apagado limpio en Windows 8+ vuelve a escribir el diario como versión 1.1 (versiones del formato); un fallo deja en su sitio las páginas rápidas de la 2.0. Ninguno de los dos destruye registros por sí mismo, pero cambian dónde está la página más reciente.
Punto ciego 5: los analizadores discrepan
El formato solo está documentado por ingeniería inversa. Las diferencias reales entre herramientas incluyen:
- si se fusionan las páginas de cola/rápidas, y cómo;
- qué parte (redo o undo) de un borrado de índice contiene la entrada;
- la estructura de las entradas de la tabla de atributos abiertos;
- la agrupación de registros en acciones (por transacciones o por proximidad);
- las actualizaciones parciales de
$SI.
El analizador en el navegador es transparente sobre su propio estado: está validado con diarios sintéticos construidos a partir de las estructuras publicadas (Linux ntfs3, libfsntfs, dfir.ru), no todavía con un corpus de diarios reales de Windows. Agrupa por entrada de la MFT dentro de una ventana de registros en lugar de por transacción, supone $SI en el desplazamiento 0x38 cuando no conoce la estructura del registro, no sigue las listas de atributos y no comprueba los números de secuencia al resolver rutas desde el $MFT. Confirma los hallazgos importantes con una segunda herramienta: consulta la comparativa de analizadores de $LogFile.
Dejar constancia de los límites en el informe
Basta con una frase por hallazgo:
El diario de transacciones NTFS abarca desde el LSN 115720 hasta el 117880; el evento fechado más antiguo es de las 09:58:12 UTC. La actividad anterior a esa hora no está representada en este artefacto. Los registros del diario no llevan marcas de tiempo; las horas indicadas proceden de las marcas de tiempo del sistema de archivos contenidas en los registros, según se indica en cada evento.
Preguntas frecuentes
¿Hasta dónde llega hacia atrás el $LogFile de NTFS?
Depende del tamaño del diario y de la actividad. El diario es circular y suele rondar los 64 MiB; en un volumen de sistema con mucha actividad puede cubrir de minutos a unas pocas horas, y en un volumen de datos o extraíble tranquilo, mucho más. En pruebas publicadas con Windows 10, los datos antiguos se sobrescribieron a los 16 minutos en un caso y a las 5 horas y 20 minutos en otro.
¿Se puede hacer que el $LogFile conserve más historial?
Sí, como medida de preparación antes de un incidente: chkdsk /L:tamaño cambia el tamaño del diario en un volumen NTFS. Un diario más grande conserva más historial. No lo ejecutes en un volumen que vayas a adquirir como evidencia, porque modifica el diario.