The DFIR-ORC tool can't parse an extremely fragmented $MFT file

[msuhanov]

A sample file system image: https://mega.nz/#!uVdHmAKD!8piInddWWdV0qsMuy9j6KYlGrxGY7IZmGs1Xz1IpzXI

The output is:

C:\Users\U\Downloads>DFIR-Orc_x64.exe ntfsutil /mft /record=0 \\.\e:

NTFSUtil v10.0.8-18-gb5f71fa
Various NTFS related utilities

Start time            : 03/19/2020 13:35:06.150 (UTC)

Computer              : DESKTOP-RD341HA
Volume name           : \\.\e:

C:\Users\U\Downloads>

The output is as expected for other volumes. The fsutil file layout E:\$MFT command gives this output:

********* File 0x0001000000000000 *********
File reference number   : 0x0001000000000000
File attributes         : 0x00000006: Hidden | System
File entry flags        : 0x00000000
Link (ParentID: Name)   : 0x0005000000000005: NTFS+DOS Name: \$Mft
Creation Time           : 5/6/2019 0:40:19
Last Access Time        : 5/6/2019 0:40:19
Last Write Time         : 5/6/2019 0:40:19
Change Time             : 5/6/2019 0:40:19
LastUsn                 : 0
OwnerId                 : 0
SecurityId              : 256
StorageReserveId        : 0
Stream                  : 0x010  ::$STANDARD_INFORMATION
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x0000000c: Resident | No clusters allocated
    Size                : 72
    Allocated Size      : 72
Stream                  : 0x030  ::$FILE_NAME
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x0000000c: Resident | No clusters allocated
    Size                : 74
    Allocated Size      : 80
Stream                  : 0x080  ::$DATA
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x00000010: Has Parsed Information
    Size                : 52,166,656,000 (48.6 GB)
    Allocated Size      : 52,166,656,000 (48.6 GB)
    Vdl                 : 52,166,656,000 (48.6 GB)
    Extents             : 238 Extents
Stream                  : 0x0b0  ::$BITMAP
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x00000000: *NONE*
    Size                : 6,369,280
    Allocated Size      : 6,369,280
    Extents             : 1,555 Extents
Stream                  : 0x020  ::$ATTRIBUTE_LIST
    Attributes          : 0x00000000: *NONE*
    Flags               : 0x00000000: *NONE*
    Size                : 448
    Allocated Size      : 262,144
    Extents             : 1 Extents

It seems that the problem is in this function: https://github.com/DFIR-ORC/dfir-orc/blob/92881ca7836830789f9bf81d2fd12b4f4bc9c149/src/OrcLib/MFTOnline.cpp#L60

It doesn't read mapping pairs (data runs) outside of the first file record segment.

[fabienfl-orc]

Thank you very much. MFT parsing is being reworked and it is a priority. This will be fixed asap.

[ruchirarya]

Any information on when the users can expect a reworked MFT parser with bug fixes?

[fabienfl-orc]

Hello, I have done multiple fixes in the last releases. At least another one is coming with the near 10.1.1.

I reproduced one bug with the sample you provided. Is there any intentional corrupted bytes ? I am having some trouble parsing some extents from $DATA.

[ruchirarya]

Not sure if the reply is to me, but the one shared the MFT sample is different person. I haven't inspected the MFT shared by msuhano so can't help if it has intentionally corrupted bytes. I hope @msuhanov responds.

[msuhanov]

Hello.

No, my sample is not manipulated. It was generated using Windows.

[fabienfl-orc]

Hello,

I have been able to fix the issue thanks to your image.

When parsing the $DATA from $MFT to build the extent list the MFT record fixup were not applied yet. This was usually working because the stored extent list was short enough to end before the fixup bytes. Your MFT got a lot of extents.

The fix will be release with the 10.1.1.

Thank you again for your test set.