I've created a .DD copy of a laptop's hard drive that I'd like to mount via helix to for investigative purposes, but for some reason when i wanna determine the offset of the partition i wanna mount, both mmls, fls & fsstat tell me they "Cannot determine partition type".
ubuntu@ubuntu~$ mmls /media/sdc1/laptopp.dd
Cannot determine partition type
ubuntu@ubuntu~$ fsstat /media/sdc1/laptopp.dd
Cannot determine partition type
ubuntu@ubuntu~$ fls /media/sdc1/laptopp.dd
Cannot determine partition type
When i run fdisk -lu on the same dd, this is the output i get
ubuntu@ubuntu~$ fdisk -lu /media/sdc1/laptopp.dd
You must set cylinders.
You can do this from the extra functions menu.
Disk /media/sdc1/laptopp.dd 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders, total 0 sectors
Units = sectors of 1*512 = 512 bytes
Disk identifier 0xf74061d6
Device Boot Start End Blocks Id System
/media/sdc1/laptopp.dd1 2048 1924849663 962423808 7 HPFS/NTFS
Partition 1 has different physical/logical endings
phys=(1023, 254, 63) logical=(119816, 89, 17)
/media/sdc1/laptopp.dd2 * 1924849663 1953521663 14336000 7 HPFS/NTFS
Partition 2 has different physical/logical endings
phys=(1023, 254, 63) logical=(119816, 89, 18)
Partition 2 has different physical/logical endings
phys=(1023, 254, 63) logical=(121601, 25, 24)
ubuntu@ubuntu~$
When i've used the 2048 "units" (of 512 bytes) as an offset in order to mount the "dd1" partition (offset was 2048*512 obviously) that's the output i've got
ubuntu@ubuntu~$ sudo mount -t ntfs-3g -o loop,offset=$((512*2048)) /media/sdc1/laptopp.dd /mnt/investigation
Failed to read last sector (1924847615) Invalid argument
Perhaps the volume is a RAID/LDM but it wasn't setup yet, or the
wrong device was used, or the partition table is incorrect.
Failed to mount '/dev/loop1' Invalid argument
The device '/dev/loop1' doesn't have a valid NTFS.
Maybe you selected the wrong device? Or the whole disk instead of a
partition (e.g. /dev/hda, not /dev/hda1)? Or the other way around?
ubuntu@ubuntu~$
The funny part is that this .dd is perfectly mountable via OSFMount or any other raw image mounting tool. I just don't understand why won't it mount via the mount command in the CLI and why won't mmls/fls/fsstat produce a partition table.
Any help would be appreciated! D
Is it MBR or GPT?
Try reading directly the MBR, dump it *like*
dd if=/media/sdc1/laptopp.dd of=mbr.bin bs=512 count=1
hexdump -C -s 446 mbr.bin
What do you get?
jaclaz
As Jaclaz says, go to the raw data.
View the sector in a Hex viewer and then work out what the bits mean.
It is possible the data is not what you were expecting (ie not a boot sector of any kind) which is why all tools you tried failed.
There are many references on boot sectors, partition table etc - assuming this file has one.
If the boot sectors is wrong, search for the start of the file system.
NB, as far I know, heads, sectors/track etc are not actually used. They are very historical
Is it MBR or GPT?
Try reading directly the MBR, dump it *like*
dd if=/media/sdc1/laptopp.dd of=mbr.bin bs=512 count=1
hexdump -C -s 446 mbr.binWhat do you get?
jaclaz
It's MBR.
that's what i've got via the hexdump
ubuntu@ubuntu~$ hexdump -C -s 448 mbr.bin
000001be 00 20 21 00 07 fe ff ff 00 08 00 00 00 d8 ba 72 |. !…………r|
000001ce 80 fe ff ff 07 fe ff ff 00 c0 ba 72 00 80 b5 01 |………..r….|
000001de 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |…………….|
*
000001fe 55 aa |U.|
00000200
ubuntu@ubuntu~$
that's what i've got via the hexdump
ubuntu@ubuntu~$ hexdump -C -s 448 mbr.bin
448?
Where the 01ee line has gone?
Anyway, that's two partitions, both NTFS (or however 0x07) that seemingly have an overlapping issue.
First partition starts at LBA 2048 and extends for 1924847616 sectors.
Hence the first LBA address after it will be 2048+1924847616=1924849664
BUT second partition starts at LBA 1924841472.
There is an overlap of 1924849664-1924841472=8192 sectors.
Most probably a tool (like OFSMount, which is IMDISK based) that ONLY accesses the single volume has no issues with mounting the first volume whilst *anything* that sees the image as a "whole, multipartitioned" device has issues with the overlapping.
Check the BPB in the boot sector (or $boot) of the first partition to check if the data in the MBR is accurate (and/or check as well the PBR of the second partition).
jaclaz
that's what i've got via the hexdump
ubuntu@ubuntu~$ hexdump -C -s 448 mbr.bin
448?
Where the 01ee line has gone?
Anyway, that's two partitions, both NTFS (or however 0x07) that seemingly have an overlapping issue.First partition starts at LBA 2048 and extends for 1924847616 sectors.
Hence the first LBA address after it will be 2048+1924847616=1924849664
BUT second partition starts at LBA 1924841472.
There is an overlap of 1924849664-1924841472=8192 sectors.Most probably a tool (like OFSMount, which is IMDISK based) that ONLY accesses the single volume has no issues with mounting the first volume whilst *anything* that sees the image as a "whole, multipartitioned" device has issues with the overlapping.
Check the BPB in the boot sector (or $boot) of the first partition to check if the data in the MBR is accurate (and/or check as well the PBR of the second partition).
jaclaz
My bad jaclaz, it was 446, i typoed it for some reason (i work on a stand-alone pc and i manually copied everything from the console…)
Regardless - I've got good news!
I was able to mount the partition using losetup & the offset you've mentioned (2048 sectors)
It's still very odd i wasn't able to mount it the "usual" way… I'd look into the MBR later on & try to figure out what went wrong.
Thanks for your help! wink
that's what i've got via the hexdump
ubuntu@ubuntu~$ hexdump -C -s 448 mbr.bin
448?
Where the 01ee line has gone?
Anyway, that's two partitions, both NTFS (or however 0x07) that seemingly have an overlapping issue.First partition starts at LBA 2048 and extends for 1924847616 sectors.
Hence the first LBA address after it will be 2048+1924847616=1924849664
BUT second partition starts at LBA 1924841472.
There is an overlap of 1924849664-1924841472=8192 sectors.Most probably a tool (like OFSMount, which is IMDISK based) that ONLY accesses the single volume has no issues with mounting the first volume whilst *anything* that sees the image as a "whole, multipartitioned" device has issues with the overlapping.
Check the BPB in the boot sector (or $boot) of the first partition to check if the data in the MBR is accurate (and/or check as well the PBR of the second partition).
jaclaz
Interestingly enough, now, for some reason, it mounted perfectly well with the 2048 sector offset, via the same mount command…
I'm absolutely dumbfounded as to what just happened.
Interestingly enough, now, for some reason, it mounted perfectly well with the 2048 sector offset, via the same mount command…
I'm absolutely dumbfounded as to what just happened.
AND the laptopp.dd has not been modified (i.e. it still hashes as before)? ?
jaclaz
Interestingly enough, now, for some reason, it mounted perfectly well with the 2048 sector offset, via the same mount command…
I'm absolutely dumbfounded as to what just happened.AND the laptopp.dd has not been modified (i.e. it still hashes as before)? ?
jaclaz
Yup!
Exactly the same md5sum as before.
I was rubbing my eyes for a couple of minutes when that happened.
Even double-checked and everything… mounts perfectly every time.
Any idea as to what happened?
Any idea as to what happened?
Naaah, maybe a typo in the first attmpt, something *like* wink
ubuntu@ubuntu~$ sudo mount -t ntfs-3g -o loop,offset=$((512*2046)) /media/sdc1/laptopp.dd /mnt/investigation
jaclaz