How do you interpret the Cluster Chain Run in an NTFS MFT record?

Question

For mostly academic reasons, I've been learning how to interpret the Cluster Chain Run from the Data Attribute Block from an MFT Record from a NTFS volume.

I watched a video that walks through an example. Here's the example:

Flags | Cluster count | First cluster
41 02 f8 38 c7 01
21 02 c5 07
31 04 83 43 01
21 08 c0 fc
31 10 44 0b 00
31 01 f7 ef f9
21 1f c6 e7
21 10 6b 28
31 01 00 52 e4

Now, the video shows some disk editing software that is interpreting the hex output. This is helpful, because the author of the video completely skips over at least 3 fundamental concepts:

1. The "First cluster" field is cumulative. Easy enough to figure out if you use a calculator.
2. The "First cluster" field is a signed integer, so that it can navigate backwards on the disk. This was trickier to figure out, but I got it.
3. The third completely ignored concept is when the the least significant byte of the "First cluster" field is zeros. Since these fields are interpreted little-endian, and since this is a flexible-length field (the flags say how many bytes), then why would you have leading zeros?

So, here's how I calculate it.

Flags | Cluster count | First cluster
41 02 f8 38 c7 01
2 clusters starting at cluster # 29,833,464
21 02 c5 07
2 more clusters starting 1,989 from 29,833,464, which is cluster # 29,835,453
31 04 83 43 01
4 more clusters starting 82,819 from 29,835,453, which is cluster # 29,918,272
21 08 c0 fc
8 more clusters starting 832 earlier than 29,918,272, which is cluster # 29,917,440
31 10 44 0b 00
16 more clusters starting 2,884 from 29,917,440, which is cluster # 29,920,324
This is where my math deviates from their math. They say cluster # 29,840,452. I need help here.
31 01 f7 ef f9
21 1f c6 e7
21 10 6b 28
31 01 00 52 e4

How does the math work when you have leading zeros in one of the fields? I also have a separate example where the leading zeros are in the "Cluster count" field, not the "First cluster" field; is that treated any different?"

Answer 1

31 10 44 0b 00, 16 more clusters starting 2,884 from 29,917,440, which is cluster # 29,920,324 This is where my math deviates from their math. They say cluster # 29,840,452. I need help

It's not your math that's wrong, the guy demonstrating in the video is wrong or at least ignores an important issue:

He cheats a little and he just reads the values from the interpreted values from the column on the left as if he's converting the values he highlights 'on the fly'.

But his handy tool already converted values take into account the update sequence array which he fails to mention and point out.

Update Sequence Array and fixup value

The run you're having a problem with is not 31 10 44 0b 00. If we look closely at his sequence of bytes in the video we see the last two bytes of the run are the last two bytes in a 512 byte sector:

Therefore 0b 00 are not the two bytes that belong to this run, it is the 'fixup'. To get the actual values you need to read them from the so called 'Update Sequence Array' for which the offset is stored at byte offset 4 in the MFT entry (usually 0x30).

At offset 0x30 you'll see the bytes 0b 00 (the fixup value), next two bytes will be original values of last two bytes of first sector of the MFT entry, next 2 the ones for the next sector.

I'll Illustrate using a MFT entry from my drive:

So 31 10 44 0b 00 is actually 31 10 44 xx xx where you replace xx with the bytes from the update sequence array, then you do your math.

The purpose of fixup values is detecting corruption. So as soon as we read the MFT entry we check fixup value and compare it to last 2 bytes of each sector, they should match, if not the sector is corrupt. To then actually work with the entry we need to correct fixup value with values from the update sequence array first.

Since these fields are interpreted little-endian, and since this is a flexible-length field (the flags say how many bytes), then why would you have leading zeros?

TBH, I haven't got the foggiest idea. At the time I was studying this, I did so for writing a NTFS file recovery program (aside, I re-discovered it's source code very recently and recompiled to see if would still run. It did!)

Anyway, point is, when I figured out data runs I never looked at those runs very closely again because I wrote code to handle them.

But yes, you are right. Again I turned to my own hard drive and got this entry:

So we get:

31 - 38 - 12 39 09 
43 - 76 2B 01 - 42 77 BB 03 
43 - A7 82 01 - 91 14 D6 00 <<
33 - DC D1 01 - 5B 2B FE  
33 - D9 E4 01 - A2 B3 FD 
etc ..

And indeed the << zeros make no difference what-so-ever as far as I can see. In fact if we ask DMDE to interpret the run-list it simply ignores the zeros too:

Reference: https://flatcap.github.io/linux-ntfs/ntfs/concepts/file_record.html