NTFS Analysis on DD...
 
Notifications
Clear all

NTFS Analysis on DD image  

  RSS
aina
 aina
(@aina)
New Member

I'm trying to analyze a given USB image (.dd) to find out the location of the MFT table. The problem is I'm having trouble to mount the DD image.

My objective is want to use command like mmls, fls and icat to locate the MFT table. I tried on different image(.vdi) and I was able to do so. I just want to understand better on raw file like DD

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

fdisk -l ntfs5.dd
Disk ntfs5.dd 25 MiB, 26214400 bytes, 51200 sectors
Units sectors of 1 * 512 = 512 bytes
Sector size (logical/physical) 512 bytes / 512 bytes
I/O size (minimum/optimal) 512 bytes / 512 bytes
Disklabel type dos

Disk identifier 0x6f20736b

Device Boot Start End Sectors Size Id Type
ntfs5.dd1 778135908 1919645538 1141509631 544.3G 72 unknown

ntfs5.dd2 168689522 2104717761 1936028240 923.2G 65 Novell Netware 386

ntfs5.dd3 1869881465 3805909656 1936028192 923.2G 79 unknown

ntfs5.dd4 0 3637226495 3637226496 1.7T d unknown
Partition table entries are not in disk order.

Here is the command that used to mount the DD image

mount -o loop,offset=$((168689522*512)),ro,noatime,noexec,show_sys_files test1/ntfs5.dd newmountdir/

Here's the error message
mount wrong fs type, bad option, bad superblock on /dev/loop0,
missing codepage or helper program, or other error

In some cases useful info is found in syslog - try
dmesg | tail or so.

Just wondering where did I go wrong in mounting the image? and apologize for the messy fdisk output.

Quote
Posted : 02/11/2017 5:58 pm
JaredDM
(@jareddm)
Active Member

If you're just trying to find the start of the MFT and you're sure it's NTFS, just open the dd file in Hex and search the ANSI string "FILE0". If the first record you find has 00 00 00 00 as the record number (as I've highlighted in this picture) you've found the beginning of the MFT.

ReplyQuote
Posted : 02/11/2017 6:30 pm
aina
 aina
(@aina)
New Member

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?

ReplyQuote
Posted : 02/11/2017 9:25 pm
JaredDM
(@jareddm)
Active Member

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).

What exactly are you trying to accomplish? Recover a file, just get info on the MFT itself, something else? If I knew what you were trying to do, I could offer a lot more help.

ReplyQuote
Posted : 02/11/2017 9:38 pm
aina
 aina
(@aina)
New Member

Basically getting the info of the MFT, e.g Locate MFT table and recover the MFT file records (offsets), extract if there's any data e.g timestamp, file name, data attribute (determine if its resident or non-resident).

ReplyQuote
Posted : 02/11/2017 11:12 pm
mscotgrove
(@mscotgrove)
Senior Member

The most common locations are

sector 0x600800
and
sector 0x60003F (XP systems)

NB searching for FILE0 may well find entries before the MFT

ReplyQuote
Posted : 03/11/2017 12:48 pm
joakims
(@joakims)
Active Member

One way to proceed;

1)
Grab the MFT records with https://github.com/jschicht/MftCarver

2)
Decode the output with https://github.com/jschicht/Mft2Csv

3)
Grab RCRD records with https://github.com/jschicht/RcrdCarver

4)
Decode the output with https://github.com/jschicht/LogFileParser

5)
Check the output in 2) and consider running MftCsv on the MFT output from 4). Now you should be able to investigate some csv output and try to find the file you are looking for.

6)
If file is identified, consider running https://github.com/jschicht/ExtractFromDataRun to extract the non-resident data of the file.

This process may work fine for a few files, but not for large number of files. The reason why I mentioned RCRD and LogFileParser is that in the case when MFT records have been overwritten, you may still find them in $LogFile.

ReplyQuote
Posted : 03/11/2017 5:02 pm
jaclaz
(@jaclaz)
Community Legend

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
etc.

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?

@aina
Quick check, if the first three bytes of the .dd image are
EB xx 90
or
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?

jaclaz

ReplyQuote
Posted : 03/11/2017 8:04 pm
athulin
(@athulin)
Community Legend

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.

ReplyQuote
Posted : 04/11/2017 8:26 am
jaclaz
(@jaclaz)
Community Legend

Found it. mrgreen

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
http//uploads.im/TzKhI.jpg

jaclaz

ReplyQuote
Posted : 04/11/2017 8:51 am
sdenis
(@sdenis)
New Member

This sure looks like an assignment from the UCD MSc program

ReplyQuote
Posted : 05/12/2017 4:46 pm
keydet89
(@keydet89)
Community Legend

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?

Fascinating.

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.

ReplyQuote
Posted : 06/12/2017 3:42 pm
Share: