Problem with 3TB NTFS

Tool requests, development, and troubleshooting topics related to TSK.

Moderator: carrier

Problem with 3TB NTFS

Postby sedoy107 » Tue Mar 29, 2016 3:17 pm

Hi everyone,

I've been using TSK API (The Sleuth Kit ver 4.2.0) for my project, and while was conducting tests I have found an interesting bug. TSK fails to correctly identify the size of 3TB NTFS file system. I used standard TSK tools to make sure that I haven't messed anything on my side.
I tried fsstat on the same disk and it's approved my suspicions:

xyz@xyz-xyz:~$ sudo fsstat -f ntfs /dev/sdc1

File System Type: NTFS
Volume Serial Number: 26BFB80D26621569
Volume Name: 3tb
Version: Windows XP

First Cluster of MFT: 4
First Cluster of MFT Mirror: 366283135
Size of MFT Entries: 1024 bytes
Size of Index Records: 4096 bytes
Range: 0 - 27
Root Directory: 5

Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 195695358
Total Sector Range: 0 - 5860530174

Multiplying the number of sectors by the sector size: 5860530174 x 512 = 3,000,591,449,088 (sounds about right)
Doing the same for clusters: 195695358 x 512 = 801,568,186,368 (which is wrong!)

Having reduced size down to 2TB everything goes correct:
Sector Size: 512
Cluster Size: 4096
Total Cluster Range: 0 - 511999998 = 2,097,151,991,808
Total Sector Range: 0 - 4095999991 = 2,097,151,995,392

The difference of 512 bytes, which is fine as the NTFS maintains the copy of the bootsector in the very last sector of its partition.

In addition the to wrongly identified size of the 3TB NTFS I also couldn't access the following NTFS metadata entries via icat:

1 - $MFTMirr
2 - $LogFile
8 - $BadClus

The first two reported: Error in metadata structure (ntfs_make_run: Run offset and length is larger than file system) ( - proc_attrseq)
And, the $BadClus reported: Error in metadata structure (ntfs_make_run: Run length is larger than file system) ( - proc_attrseq)

Has anyone seen this issue before?
Posts: 2
Joined: Wed Mar 23, 2016 12:36 am

Re: Problem with 3TB NTFS

Postby akukoba » Thu May 26, 2016 10:43 am

I've found that it's happening due to a bug in ntfs.c
There's a code:
Code: Select all
        fs->block_count =
        (TSK_DADDR_T) tsk_getu32(fs->endian,
        ntfs->fs->vol_size_s) / ntfs->fs->csize;

using tsk_getu32 extract only lower 32 bits of volume size. This causes wrong block count. I've tried to change it to tsk_getu64 and it worked for my 4Tb sshd drive.
But there's a comment above the code I've mentioned:
Code: Select all
     /* This field is defined as 64-bits but according to the
     * NTFS drivers in Linux, windows only uses 32-bits

So I still don't know if using tsk_getu64 won't break NTFS processing in all other cases...
Posts: 1
Joined: Thu May 26, 2016 10:37 am

Return to The Sleuth Kit (TSK)

Who is online

Users browsing this forum: No registered users and 1 guest