±Forensic Focus Partners

Become an advertising partner

±Your Account


Forgotten password/username?

Site Members:

New Today: 0 Overall: 34837
New Yesterday: 0 Visitors: 122

±Follow Forensic Focus

Forensic Focus Facebook PageForensic Focus on TwitterForensic Focus LinkedIn GroupForensic Focus YouTube Channel

RSS feeds: News Forums Articles

±Latest Articles

±Latest Webinars

NTFS Analysis on DD image

Computer forensics discussion. Please ensure that your post is not better suited to one of the forums below (if it is, please post it there instead!)
Reply to topicReply to topic Printer Friendly Page
Forum FAQSearchView unanswered posts
Go to page Previous  1, 2 

Re: NTFS Analysis on DD image

Post Posted: Fri Nov 03, 2017 2:04 pm

- JaredDM
If the partition was formatted, there's a good chance the MFT is partly overwritten by the FAT table (yes I know saying 'table' is redundant here).

Yes and no (mostly no)
Actually it depends greatly on the system where the volume/filesystem was created.

Both 2K and XP tend to put the $MFT "well inside" the volume (and thus well beyond the FAT area, which is instead "fixed" to just after the bootsector).

AFAICR Vista also behaves the same, whilst I have seen quite a few NTFS volumes created under 7 (but without a proper documentation on how exactly they were created, very likely by third party utilities) with the $MFT starting right after the $Boot file, on cluster 2

BTW, on earlier NTFS (NT and Windows 2000) the leading string is FILE* (as opposed to FILE0).

BUT in the specific case, the .dd image is seemingly extremely small:

fdisk -l ntfs5.dd
Disk ntfs5.dd: 25 MiB, 26214400 bytes, 51200 sectors

and, from the output of the tool, the "partition types" coming out as 72, 65, 79 etc. make me think that it is a Superfloppy.

Using a MBR parser on a NTFS bootsector (or PBR or VBR) gives for the first three partitions:
The NT52 one, (i.e. the one invoking NTLDR from XP): 72, 74, 65
The NT60 one (i.e. the one invoking BOOTMGR from Vista): 70,43,72
The NT61 one (i.e. the one invoking BOOTMGR from 7): 4F,73,2B
The NT62 one (i.e. the one invoking BOOTMGR from 8): 72,6C,00

A quick check for the standard bootsectors for FAT12/16 and FAT32 (which should be a logical impossibility) doesn't give me any "72,65,79" but since the area where the partition table is in the MBR is roughly where "error messages" are in the bootsectors, it is entirely possible that is some uncommon bootsector or a non-English one.

Since the label is reported as "dos" it may be a DOS bootsector?

Quick check, if the first three bytes of the .dd image are:
EB xx 90
E9 xx xx
(where xx means "any value")
the image starts with a bootsector (ie. there is no MBR and it is a "superfloppy").

Also, can you confirm that the size is only 25 Mb?

- In theory there is no difference between theory and practice, but in practice there is. - 

Senior Member

Re: NTFS Analysis on DD image

Post Posted: Sat Nov 04, 2017 2:26 am

- aina
When I run fdisk -l ntfs5.dd here's the output that I get:

(Added: it is probably important to know just what fdisk utility you're using. When I check the util-linux-ng fdisk source, I can't find the 'Disklabel type' text that your fdisk outputs. So this may be an older version, or some other utility entirely ... in which case it's difficult to say if it's a good utility or not. Nor do I find any in the skypher version. My comments below assumed the util-linux-ng ...)

A problem here is that fdisk works for a certain number of situations. Have you established that any of those are present? That is, have you established that the image contains GPT, MBR, Sun, SGI or BSD partitions? (See your man page for your particular fdisk version).

I'm assuming you have verified that you have the usual 55 AA signature. Those, however, are use for more than just MBR sectors, so you need to be careful.

If your image does not contain a MBR, but only a VBR ... what happens? Do you get an error message? Or do you get nonsense?

The only certain way I know to handle that situation is the imaging report. It should state unambiguously how the image was produced. What has been imaged, and how? If you don't have that information, you should get it.

The partition table you provide looks like nonsense -- so I suspect that fdisk is not the right tool to use. Can you verify that it is? If it isn't, the mounting command you include is also nonsense, and it should be no surprise that it isn't working.

A wild guess, based on no information that you have provided, is that you don't have a partitioned disk, but only a single partition (or partition equivalent). In that case -- which you should confirm before you do anything else -- you would (probably) mount the image as it is.

You may want to check what file(1) says about the image. You may also want to check what disktype (download from sourceforge) says -- it's supposed to identify various image formats, but I can't remember that I've tried it on a VBR/VBR-equivalent image. Or try another partition managing program, such as gpart or GNU parted.  

Last edited by athulin on Sat Nov 04, 2017 4:24 am; edited 1 time in total

Senior Member

Re: NTFS Analysis on DD image

Post Posted: Sat Nov 04, 2017 2:51 am

Found it. Mr. Green

It is the "standard" English NT bootsector for FAT12/16 (which makes sense, given the 25 Mb size), the one invoking NTLDR and with "MSDOS5.0" as OEM string.
Besides the "Partition ID" also the "Partition Sizes" match the OP fdisk output.

Here it is:

- In theory there is no difference between theory and practice, but in practice there is. - 

Senior Member

Re: NTFS Analysis on DD image

Post Posted: Tue Dec 05, 2017 10:46 am

This sure looks like an assignment from the UCD MSc program  


Re: NTFS Analysis on DD image

Post Posted: Wed Dec 06, 2017 9:42 am

- aina
Thanks for the info @JaredDM. I'm able to open the file in hex. The challenge that i'm actually having is the USB image (ntfs5.dd) was on NTFS previously and then it got formatted to FAT. I need to locate the MFT and its timestamp, files, and its attribute. I'm new to NTFS analysis, do you have any other suggestion or workaround?


If the format of the device *was* NTFS, but was reformatted to FAT, I'd recommend going back to @JaredDM's solution.

You're not doing NTFS analysis at this point, you're trying to NTFS recovery. So...why not just locate all instances of "FILE0", grab 1024 bytes from (and including) the "F", and the proceed on. Dump all of these to a file, and you'll have what could be an MFT, or a partial one.

*Then* you can do some modicum of NTFS analysis, albeit without the actual file system.  

Senior Member

Page 2 of 2
Go to page Previous  1, 2