Cannot access H partition to image

Is this by any chance a Windows 8 Machine?
These installs do have a lot of different partitions, some of them are used for recovery etc.
Have you tried looking at the disk through X-Ways (or winhex if you need a free version)?
Good chance X-Ways will show you the file system, if there is one.
If not, this might be effectively a swap partition. In this case you may be able to carve files/items of interest from it but might be hard to prove exactly where they came from.

Hi all,

I have a laptop drive that is 500G with several partitions on it. The H partition is where I need to access files and look at the data in question. I cannot seem to access this partition with Sleuth Kit or FTK Imager to grab an image of it. I can access the files and pull some back using TestDisk and PhotoRec however this will take a long time.

When I try to mount the drive with Windows the OS cannot see the H partition. Any one run into this before? How can I access the partition and pull an image of it?

Thanks,

Rob

I think we need more information. What does 'cannot seem to access' mean? You can't view the file system? You can't even see the hex? Do you know what file system the partition is formatted as? What OS is it?

Unfortunately "the H partition" doesn't really mean *anything*, H is the drive letter that (a letter is assigned to a volume, which may or may not be also a partition) a Windows OS assigns when a volume is mounted either through automated mounting/drive lettering or because it is explicited in the Registry under HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices.

It doesn't really help to identify what it might be.

You need to be more explicit, is it a primary partition or a volume inside extended (if it is a MBR style disk, or is it a GPT?), which partition ID it has?
Which filesystem it has (or should have)?

What are the (LBA) address and extent?
Hint If you can find these data you can use a normal dd to make an image of the volume.

A "normal" fdisk in Linux should be able to provide you with these data, there are several tools capable of doing the same under Windows, if you get gdisk
http//www.rodsbooks.com/gdisk/
it will give you info on the partitioning of both a MBR and a GPT disk.

Any hex/disk editor (or viewer) should be able to access the MBR (and/or the EPBR) or the EFI partition table on GPT disks), however.

If the partition/volume is not indexed in any of the partitioning structures (which doesn't sound like the case since Windows doea assign a latter to it) you can try using dmde
http//dmde.com/
which can usually find partially invalid partition/volumes by scanning the disk.

jaclaz

I am obviously making some assumptions here, but, take a physical image of the hd using dd, dcfld, or FTK Imager Lite (free). Then open the image file in WinHex or X-Ways, or, Autopsy (any number of tools). You should be able to see the logical view of the file system. If you are using Most tools will let you export or carve out what you need from the file system.

Not accessing a logical drive implies the OS will not let you. Taking a physical image will remedy that issue providing the hd isn't somehow damaged or the data has been overwritten.

Good luck!

The H partition is where I need to access files […]

It's unfortunate that there is no reasonably standard way to identify a) partition scheme, and b) elements inside those partitions. As already remarked, 'H' does not mean anything. (It might mean something in the context of some particular tool, but you have to identify that tool first.)

The partition type (if any) may be more useful.

For example, Intel Rapid Start Technology (I think it is) requires a special partition (type 84) where a hibernation image can be saved. This is not a 'volume', so identifying files would probably be futile. However, any decent forensic tool should identify the partition as such.

And perhaps also if it is bootable – if it's a UEFI partition, Windows is unlikely to mount it.

I cannot seem to access this partition with Sleuth Kit or FTK Imager to grab an image of it.

Are you using those tools correctly? (I assume you have a reason why you want to image partitions individually, and not the entire disk at once.)

When I try to mount the drive with Windows the OS cannot see the H partition. Any one run into this before?

In many cases that is because the partition doesn't contain a file system that Windows supports. Mac (HFS+) and various Unix file systems are good examples.

It may also be because the partition is flagged as 'invisible', which only means that Windows should not try to mount it automatically. System restore partitions can be of this type. Special boot systems (like UEFI) are other examples.

In those cases, however, the partition will be visible in the Disk Manager, even if Windows won't mount it.

The partition table could also be damaged, though in those cases I would expect an error message in the system log. (I assume you have looked there for any indications of problems?)

How can I access the partition and pull an image of it?

I would have recommended FTK imager. But as you say it doesn't work (which is odd), I can only assume you're not using it correctly, or you are looking at a badly damaged disk

In either of those cases, I would guess that you most likely can't, and that you may need to hand the job over to someone else.

But then I don't have all the facts available, so I may be mistaken.

Thanks everyone for your replies. I was to get Kali to see the partitions. The partition that I would like to image is

Start End Blocks ID System
/dev/sdb4 951525376 952232175 358400 7 HPFS/NTFS/exFAT

The format -l results report a GPT partition on this drive.

I have tried FTK Imager but Windows will not mount the partition and FTK hangs. I think the suggestion of using dd to image may work especially since I can get Kali to see the drive. I cannot see the file system on this partition. I believe the OS was Windows 8.

Given this information, what would be my best choice here to get an image of the above?

Thanks for your help.

The partition that I would like to image is

Start End Blocks ID System
/dev/sdb4 951525376 952232175 358400 7 HPFS/NTFS/exFAT

No. (

Some of that data is incorrect.

This equation must be true
End-Start+1=Blocks

jaclaz

That is what is being reported by Linux.

That is what is being reported by Linux.

I understand ) and that may also be the reason why there are problems accessing that volume/partition.

Try inspecting the disk with the other tools suggested, since it is seen as sdb4 in Linux, it should mean that it is a primary partition (in last slot of the MBR), of course IF it is a MBR disk.

Somehow I have the impression that you are not familiar with disk partitioning, a disk (whole thing) is normally either MBR or GPT the "The format -l results report a GPT partition on this drive." makes no sense 😯 , either ALL partitions are GPT or they are ALL MBR, there is the possibility that it is a hybrid partitioning scheme but they are very rare.

In any case both gdisk and dmde will be able to provide you with more details.

The fact that the difference between end and start does not equal the number of blocks could mean that there is some form of corruption in either the partition table or in the volume bootsector (or in both), you need to check both (and - if it is a NTFS also the "backup" bootsector at the end of the volume).

If you do (which would be logical if you trust the number of blocks)
dd if=/dev/sdb4 of=/mynice.img bs=512 count=358400
you might have an incomplete image, on the other hand, if you trust the Start/End you should do
dd if=/dev/sdb of=/mynice.img bs=512 count=706800 skip=951525376
which is almost twice in size, the 354800*512=183500800, roughly 180 Mb, the 706800*512=361881600, roughly 355 Mb.

I am assuming that the block size is 512 bytes, if it is one of the new "large sectored" drives, they are 4096 bytes/blocks and I would not be surprised if a (possibly outdated) fdisk would have issues, though the factor involved in the miscalculation would obviously be 8 and not "almost 2", I still suspect that you there is a typo in what you posted
952232175+1=952232176
952232176-951525376=706800

If - by any chance - the 952232175 is actually 952242175, the difference would become 716800, i.e. exactly 2 times the 358400, which might mean that somehow the blocksize is 1024 bytes instead of 512, but that would make anyway more sense than the current 1,9720982142857142857142857142857 ratio.

jaclaz