Recovery of Deleted Non-Resident Files in the NTFS File System Using $LogFile Record Information
Analysis Overview
$LogFile is one of the metadata system files used by the NTFS file system. It records transaction logs related to file operations, such as file creation, deletion, and modification. For recovery purposes, each record contains both Redo and Undo data.
This document presents an analysis of a method for recovering deleted files whose $DATA attributes are stored in Non-Resident form, based on $LogFile transaction log information remaining after file deletion on a Windows system using the NTFS file system.
(This post focuses primarily on key record information rather than the detailed internal structure of $LogFile. For more information about the $LogFile structure, the following reference may be helpful:
https://flatcap.github.io/linux-ntfs/ntfs/files/logfile.html)
Analysis Tools
Creation and Deletion of the Test File “NTFS_TEST_FILE.pdf”
[Figure] Contents of the NTFS_TEST_FILE.pdf Document
| File Name |
NTFS_TEST_FILE.pdf |
| Full Path |
C:\Users\codecure\Downloads\NTFS_TEST_FILE.pdf |
| Actual Size |
20,611 Bytes |
| Allocated Size |
24,576 Bytes (6 Clusters, 81,216 Start Cluster Num) |
| MFT Record Number |
2,984 |
| Creation Time |
2026-09-03 13:46:36(UTC) |
| Last Modified Time |
2026-09-03 13:46:37(UTC) |
| Last Access Time |
2026-09-03 14:02:04(UTC) |
[Table] NTFS_TEST_FILE.pdf File Information
For the analysis, a file named NTFS_TEST_FILE.pdf with a size of 20,611 Bytes was created.
[Figure] Permanent Deletion of NTFS_TEST_FILE.pdf
[Figure] Result of Searching the Deleted “NTFS_TEST_FILE.pdf” File Log Using NTFS Log Tracker ($LogFile)
After permanently deleting the “NTFS_TEST_FILE.pdf” file using Shift+Delete, the PC was shut down and the $LogFile was extracted. When the file name was searched using NTFS Log Tracker, LSN 1,110,407,404, corresponding to a DeallocateFileRecordSegment record associated with a “File Deletion” event, was identified.
When searching for the deleted file name using NTFS Log Tracker, the deletion log for the file could be identified. However, the tool did not provide information about the cluster locations in which the deleted file data had been stored.
To examine the file deletion transaction log in greater detail, the $LogFile was opened using HxD, and the LSN 1,110,407,404 record identified by NTFS Log Tracker was located.
[Figure] LSN 1,110,407,404 Record
Because the first 8 bytes of a $LogFile record contain the record's LSN value, the record area could be located by searching $LogFile for LSN 1,110,407,404 (0x422F78EC).
The LSN 1,110,407,404 record contained the LSN value of the previous record, and subsequent related records were also identified. Therefore, the deletion transaction was analyzed by following the chain of associated records.
The following transaction record pattern was identified in $LogFile for the permanent deletion of the Non-Resident file “NTFS_TEST_FILE.pdf”.
| Order |
Redo (Opcode) |
Undo (Opcode) |
Description |
| 1 |
ClearBitsInNonResidentBitMap (0x16) |
SetBitsInNonResidentBitMap (0x15) |
Modifies the bitmap values corresponding to the allocated clusters in the $Bitmap area to 0, thereby deallocating the clusters |
| 2 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Deletes an Index Entry from the parent directory |
| 3 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Deletes an Index Entry from the parent directory |
| 4 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Deletes an Index Entry from the parent directory |
| 5 |
DeallocateFileRecordSegment (0x03) |
InitializeFileRecordSegment (0x02) |
Deallocates the file record segment |
| 6 |
ClearBitsInNonResidentBitMap (0x16) |
SetBitsInNonResidentBitMap (0x15) |
Modifies the bitmap value of the previously used MFT Entry number in the $BITMAP attribute of $MFT to 0, thereby deallocating the MFT Entry |
| 7 |
SetNewAttributeSizes (0x0B) |
SetNewAttributeSizes (0x0B) |
Modifies the size of the $DATA attribute of the $UsnJrnl:$J file |
| 8 |
UpdateNonResidentAttributeValue (0x08) |
None (0x00) |
Creates a file deletion journal record in $UsnJrnl:$J |
| 9 |
SetNewAttributeSizes (0x0B) |
SetNewAttributeSizes (0x0B) |
Modifies the size of the $DATA attribute of the $UsnJrnl:$J file |
| 10 |
ForgetTransaction (0x1B) |
CompensationLogRecord (0x01) |
|
[Table] Transaction Record Pattern Remaining in $LogFile After Permanent Deletion of the Non-Resident File “NTFS_TEST_FILE.pdf”
A total of 10 transaction records related to the deletion of “NTFS_TEST_FILE.pdf” were identified.
From a file recovery perspective, the first and sixth ClearBitsInNonResidentBitMap(0x16)/SetBitsInNonResidentBitMap(0x15) records are particularly important because the Redo/Undo data contained in these records can be used to calculate the cluster location where the deleted file had been stored and the corresponding MFT Entry number.
Cluster Bitmap Deallocation Record of the $Bitmap File (0x16, 0x15)
[Figure] First 0x16/0x15 Record in the “NTFS_TEST_FILE.pdf” File Deletion Transaction
The first record of the “NTFS_TEST_FILE.pdf” file deletion transaction was identified by tracing backward through the previous-record LSN stored in LSN 1,110,407,404, which had been identified using NTFS Log Tracker.
This process led to LSN 1,110,407,319 (0x422F7897), the first record with no preceding record LSN.
The record was identified as a ClearBitsInNonResidentBitMap(0x16)/SetBitsInNonResidentBitMap(0x15) record. The Opcode names themselves indicate that this record modifies a bitmap.
[Figure] VCN and LCN Values to Which the Modification Is Applied
The target LCN at which the bitmap value is modified was identified as 785,921 (0x0BFE01), while the relative VCN value was identified as 2 (0x02).
[Figure] $DATA Cluster Run List of the $Bitmap Metadata File at MFT Entry 6
The $DATA attribute cluster run list of the $Bitmap metadata file at MFT Entry 6 was identified as:
32 FA 01 FF FD 0B
Based on this run list, the $Bitmap file is stored in 506 (0x1FA) consecutive clusters beginning at cluster 785,919 (0x0BFDFF).
The target LCN 785,921, identified in the 0x16/0x15 record, falls within the cluster region occupied by the $Bitmap file and corresponds to the second cluster relative to the starting cluster 785,919.
It was also confirmed that the VCN recorded as the Redo/Undo target in the 0x16/0x15 record is relative to the starting cluster of $Bitmap.
[Figure] Deallocated Bitmap Position Information Recorded in the Redo/Undo Data of the 0x16/0x15 Record
For this 0x16/0x15 record, the Redo and Undo data each contain an 8-byte value in the same location.
The first 4 bytes represent the bit offset relative to the target LCN and indicate the starting position of the bitmap region being deallocated.
The remaining 4 bytes represent the number of consecutive bitmap bits being deallocated from that starting position.
The starting bitmap position being changed to the deallocated state corresponds to the 15,680th bit within cluster 785,921 (LCN).
Converting this into a byte offset gives:
15,680 / 8 = 1,960
Therefore, the bitmap position corresponds to the 1,960th byte within cluster 785,921.
[Figure] Bitmap at the 1,960th Byte Within $Bitmap Cluster 785,921 (LCN)
The bitmap manages cluster allocation and deallocation states using bit values of 0 and 1.
The bitmap value changed to the deallocated state was identified as C0, which is represented in binary as:
1100 0000
Within a one-byte bitmap value, the cluster order begins from the least significant bit. Therefore, the value 1100 0000 indicates that a total of six consecutive clusters are in the deallocated state.
The $Bitmap metadata file records allocation information for all clusters in the file system on a bit-by-bit basis.
Therefore, by calculating the location of the bitmap bits changed to the deallocated state relative to the beginning of $Bitmap, the cluster number where the deleted file had previously been stored can be determined.
[VCN targeted by Redo/Undo data] * ([Cluster Size] * 8) + [Starting Position of the Deallocated Bitmap] = Starting Cluster of the Deleted Non-Resident File
Because one cluster is 4,096 Bytes, each cluster of $Bitmap contains bitmap information for:
4,096 * 8 = 32,768
file-system clusters.
In the record above, the VCN targeted by the Redo/Undo data is 2, and the target position within that cluster is 15,680.
Therefore:
2 * 32,768 + 15,680 = 81,216
This calculation shows that the deleted “NTFS_TEST_FILE.pdf” file had been stored in a total of six consecutive clusters beginning at cluster 81,216.
[Figure] Deleted “NTFS_TEST_FILE.pdf” Data Remaining at Cluster 81,216
[Figure] Successfully Recovered “NTFS_TEST_FILE.pdf” File
When cluster 81,216 was examined, the data of the deleted “NTFS_TEST_FILE.pdf” file remained intact.
By extracting the six consecutive clusters from 81,216 through 81,221, the deleted PDF file could be successfully recovered.
$BITMAP Attribute Bitmap Deallocation Record of the $MFT File (0x16, 0x15)
[Figure] Sixth 0x16/0x15 Bitmap Modification Record in the File Deletion Transaction
The sixth bitmap modification record in the Non-Resident file deletion transaction was another ClearBitsInNonResidentBitMap(0x16)/SetBitsInNonResidentBitMap(0x15) record.
The target LCN of this record was identified as cluster 786,431 (0xBFFFF), while its VCN value was 0 (0x00).
[Figure] Cluster Run List of the $BITMAP (0xB0) Attribute of the $MFT File
The target LCN 786,431 (0xBFFFF) of the 0x16/0x15 record was identified as belonging to the bitmap cluster area that stores MFT Entry allocation information, as indicated by the first cluster run list of the $BITMAP (0xB0) attribute of the $MFT file.
[Figure] Deallocated Bitmap Position Information Recorded in the Redo/Undo Data of the 0x16/0x15 Record
The starting position of the bitmap being changed to the deallocated state corresponds to the 2,984th bit relative to cluster 786,431 (LCN).
Converting this value into a byte offset gives:
2,984 / 8 = 373
Thus, the target corresponds to the 373rd byte within the relevant bitmap cluster.
[Figure] Bitmap at the 373rd Byte of the MFT Entry Bitmap
When the bitmap value at the 373rd byte of the $BITMAP attribute of the $MFT file was examined, the value was found to be FF.
This indicates that the MFT Entry that had been deallocated following deletion had already been reallocated to another file.
In the same way that the Redo/Undo data of the $Bitmap metadata file's bitmap deallocation record can be used to calculate the cluster location of a deleted file, the Redo/Undo data related to MFT Entry bitmap deallocation can be used to determine the MFT Entry number of the deleted “NTFS_TEST_FILE.pdf” file.
[VCN targeted by Redo/Undo data] * ([Cluster Size] * 8) + [Starting Position of the Deallocated Bitmap] = MFT Entry Number
Based on this calculation, the metadata for “NTFS_TEST_FILE.pdf” was stored in MFT Entry 2,984.
[Figure] MFT Entry of “NTFS_TEST_FILE.pdf” (Offset 0x2EA000 Within the $MFT File)
Before “NTFS_TEST_FILE.pdf” was deleted, its MFT Entry was stored as the 2,984th entry at:
Offset 0x2EA000 (2,984 * 1,024)
within the $MFT file.
This result matches the information calculated from the ClearBitsInNonResidentBitMap(0x16)/SetBitsInNonResidentBitMap(0x15) record data.
Analysis Conclusion
[Figure] MFT Entry Reallocated to Another File After the Deletion of “NTFS_TEST_FILE.pdf”
As observed in the $BITMAP attribute of the $MFT file, the MFT Entry associated with “NTFS_TEST_FILE.pdf” was reallocated to another file after deletion.
Therefore, even if the original MFT Entry number of “NTFS_TEST_FILE.pdf” is known, it is no longer possible to directly recover the file by obtaining the original cluster location from the $DATA attribute of that MFT Entry.
[Figure] “NTFS_TEST_FILE.pdf” Not Recoverable Using FTK Imager
When both the MFT Entry and the cluster area of a deleted file remain intact, FTK Imager can identify deleted files at their original locations using an “X” icon and can recover them.
However, in the case examined here, although the clusters containing the deleted file had not been reallocated and the original file data remained intact, the corresponding MFT Entry had already been reallocated to another file.
Under these circumstances, FTK Imager did not directly support recovery of the deleted file.
| Record Order |
Redo (Opcode) |
Undo (Opcode) |
Information That Can Be Identified |
| 1 |
ClearBitsInNonResidentBitMap (0x16) |
SetBitsInNonResidentBitMap (0x15) |
Cluster address of the deleted file |
| 2 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Parent directory reference address and deleted file name |
| 3 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Parent directory reference address and deleted file name |
| 4 |
DeleteIndexEntryFromAllocationBuffer (0x0F) |
AddIndexEntryToAllocationBuffer (0x0E) |
Parent directory reference address and deleted file name |
| 6 |
ClearBitsInNonResidentBitMap (0x16) |
SetBitsInNonResidentBitMap (0x15) |
MFT Entry number of the deleted file |
| 8 |
UpdateNonResidentAttributeValue (0x08) |
None (0x00) |
File deletion journal record stored in $UsnJrnl:$J |
[Table] Key Information Obtainable from Non-Resident File Deletion Transaction Records in $LogFile
However, as demonstrated above, the first ClearBitsInNonResidentBitMap(0x16)/SetBitsInNonResidentBitMap(0x15) record associated with $Bitmap among the file deletion transaction records remaining in $LogFile contains information about the location of the cluster allocation bitmap.
Using this information, it is possible to determine the cluster region that had been allocated to the deleted file.
Therefore, even when the corresponding MFT Entry has already been reallocated, if the original data clusters have not yet been reallocated and remain in an unallocated state, the deleted file can still be recovered by identifying and extracting those clusters based on the $LogFile transaction record information.
References