Hi all,
I am struggling to view the contents of an image I took using DD.
From the following output, can you tell if this is a major problem or not?
The image should be of a partition only rather than a full disk.
It's just a learning exercise so no big issue if it is inaccessible.
[root@localhost ~]# fdisk -l /media/SmallExt/250Gig.001
last_lba() I don't know how to handle files with mode 81ff
Disk /media/SmallExt/250Gig.001 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk /media/SmallExt/250Gig.001 doesn't contain a valid partition table
[root@localhost ~]#
Is it a lost cause or is there a way to access it?
Thanks
seabro
What type of disk were you expecting, Linux, FAT, NTFS, MAC etc
Hi all,
I am struggling to view the contents of an image I took using DD.
From the following output, can you tell if this is a major problem or not?
The image should be of a partition only rather than a full disk.
It's just a learning exercise so no big issue if it is inaccessible.
[root@localhost ~]# fdisk -l /media/SmallExt/250Gig.001
last_lba() I don't know how to handle files with mode 81ffDisk /media/SmallExt/250Gig.001 0 MB, 0 bytes
255 heads, 63 sectors/track, 0 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytesDisk /media/SmallExt/250Gig.001 doesn't contain a valid partition table
[root@localhost ~]#Is it a lost cause or is there a way to access it?
Thanks
seabro
If it's just an exercise, trying using a hex editor. Then search for individual file signatures, as the partition table header info may have been intentionally damaged as part of the exercise.
The image should be of a partition only rather than a full disk.
If the image is of a partition, why are you trying to invoke a partition editor on it?
That won't work, … unless the partition contains a hard disk image with partitions.
(Best way to get a rough idea of what you're dealing with is often to get
'disktype' from sourceforge, and then run it on the image. The 'file' command can also
useful, but is more targeted towards 'normal' files.
Is it a lost cause or is there a way to access it?
You have to identify the volume structure inside that partition. If there is one, disktype will probably do it for you – with some exceptions. Last time I checked it didn't do too well on other-endian data.
Once you know what volume is in the image, you may be able to mount it or something like that.
If you have a deliberately obscured volume, you have to use your brain and your knowledge of file systems.
Added the last_lba() error message is produced when the file examined is found to be something not allowed. However, the fdisk source I examined outputs the actual mode in octal notation, while the error message you cite clearly is hexadecimal, which suggests you're using an older fdisk implementation.
Anyway, mode 0x81FF should be 0100777. On a fairly modern fedora, that is the mode of a regular file. Check your fdisk man page – does it say that fdisk works on regular files? Mine says it only works on devices, but old sources of fdisk (v. 2.16, for example) appears to allow also regular files.
But read the fdisk man page closely it's said to be buggy, and that you should use something else instead … -)
Thank you for your kind replies.
When I say exercise, I don't mean someone set it for me, I just took the image myself for experience.
The file system should be NTFS as it was taken from a Windows 7 PC.
I used a linux live CD then used 'dd' to take the image of a partition so the source was /dev/sdb1
When I run 'file' against the image, the result is 'data'. I will try running 'disktype' and let you know how I get on.
Thanks again!
Seabro
what was the dd command line when you created the image?
I used a linux live CD then used 'dd' to take the image of a partition so the source was /dev/sdb1
Seabro
If all you have taken is the image of a partition (as you seem to suggest here and elsewhere) then fdisk -l is useless. Try using fsstat instead.
In any case 'xxd -l 512 [file]' should give you some clues.
Paul