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.
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.
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 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.
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).
The most common locations are
sector 0x600800
and
sector 0x60003F (XP systems)
NB searching for FILE0 may well find entries before the MFT
One way to proceed;
1)
Grab the MFT records with https://
2)
Decode the output with https://
3)
Grab RCRD records with https://
4)
Decode the output with https://
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://
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.
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
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.
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//
jaclaz