Join Us!

Windows 7 MBR syste...
 
Notifications
Clear all

Windows 7 MBR system unable to view Windows 8 GPT HDD  

Page 1 / 2
  RSS
acarr31
(@acarr31)
Junior Member

Good afternoon,

I have searched high and low for a reason as to why this is occurring including talking to Microsoft, reviewing their forums and every other forum I can find and I simply cannot find a satisfactory answer to why this is happening so let me know explain my situation.

At our lab we will conduct a live virus scan of a suspect's hard drive after the imaging process while it is still behind a write-blocker. This aids us in determining what sort of malware may be on the suspect's system and if that malware may have contributed to the current state of the items we are reviewing while still leaving the suspect hard drive in an unaltered state.

Unfortunately as soon as I started trying to hook up suspect hard drives that were partitioned GPT from Windows 8 machines my forensic workstation could not view the contents of the hard drive. I was able to hash the drive using WinHex v. 16.9 and I was able to make an image of the drive using FTK Imager v. 3.1.2.0. EnCase v. 6.19.4.11 can process the drive just like any other drive.

Here is some information on my workstation that may help you.

Digital Intelligence FRED
Tableau 3d write blocker (this is what the suspect drive is connected to) with a USB connection to the motherboard
Windows 7 Ultimate 64 bit Service Pack 1
2x Intel Xeon E5-2670 processors
32Gb RAM
Operating System hard drive partitioned with a Master Boot Record and BIOS
Motherboard does not support UEFI booting

Now, everything I have read seems to claim that Windows 7 64 bit should be able to recognize and review the GPT partitioned hard drive connected as "an external drive" even though my workstation wouldn't natively be able to run a GPT partitioned OS drive.

When I connect the hard drive through the write blocker it identifies two partitions out of the five that are actually on the device (other three are support utility partitions) but I cannot enter them through windows explorer. Also when I try to use Microsoft Security Essentials v. 4.4.304.0 to scan those two partitions it immediately errors out with an error code that would appear if the partition didn't contain any data.

Other programs like Gargoyle Investigator Pro v. 5.2 don't even see the partitions at all. Programs that can access the drive on a physical level like WinHex, EnCase and FTK Imager have no problem identifying the drive and all of its partitions.

Basically my question is why is it that my Windows 7 machine can't deal with this Windows 8 hard drive. Microsoft says an MBR partitioned OS should be able to treat a GPT partitioned hard drive as an external data drive just fine.

Is the fact that there is an OS on the attached drive causing the problem? If so, what specifically is the hang up that would make it interact so differently than if it were just a data drive?

Thank you ahead of time for any assistance you can provide. You can review the Windows and GPT FAQ that Microsoft even claims it should work, as that is where I am getting my assumption that this should not be happening http//msdn.microsoft.com/en-us/windows/hardware/gg463525.aspx

Regards,

acarr31

Quote
Posted : 06/02/2014 12:24 am
jaclaz
(@jaclaz)
Community Legend

There is no known reason, to the best of my knowledge (and of course given the data in your post) why this should happen.

You don't mention make/model (and size) of hard disk.

At first sight, I find more probable some kind of incompatibility of *some* kind between the specific write blocker and the specific disk, and/or *some* other more wide incompatibility (write blocker with GPT disks or with GPT disks of a given size or GPT disks of a given sector size, for example).

If I were you I would try contacting Tableau to understand if they are aware of something similar and/or try with the same setup with another write blocker.

If you have the possibility to make a "clone" of the disk, it would be IMHO interesting to see the behaviour of a WinFE build on the clone (with and without the WinFE Read Only Registry settings and with and wiithout the write blocker)
http//winfe.wordpress.com/

as this is something that - unlike the behaviour with "plain" MBR disks
http//reboot.pro/topic/18953-is-winfe-forensically-sound/
http//mistype.reboot.pro/documents/WinFE/winfe.htm
has not AFAIK been analyzed in detail (at least publicly).

And/or setting the USB device as Read Only (software write blocking).

jaclaz

ReplyQuote
Posted : 06/02/2014 1:18 am
acarr31
(@acarr31)
Junior Member

Thanks for the quick reply. It seemed out of the ordinary to me and will likely require further testing. I am going to create some GPT partitioned disks without an operating system to see if that has an impact for whatever reason. I am going to follow up on your advice to speak with Tableau. If anyone else has experienced a similar problem please let me know.

ReplyQuote
Posted : 07/02/2014 12:06 am
twjolson
(@twjolson)
Active Member

I am just spitballing here, and I may be way off, but is the hard drive a 4k sector size drive?

A little digging shows that native 4k sectors are supported only by Windows 8.

I've never had this, so no promises.

Terry

ReplyQuote
Posted : 07/02/2014 2:48 am
harryparsonage
(@harryparsonage)
Active Member

I know little about GPT disks but did come across an issue once which is something you could consider.

I set up bootcamp on a Mac and then changed the size of the Windows partition from Windows. When I imaged this drive and put it into Encase 6 it would only see the Windows partition as a lump of unallocated.

When I looked at the protective MBR I found that it had the Windows partition in the correct location but looking at the GPT it had it in the wrong place.

It may be worth checking the partitions in the MBR and comparing them to the GPT just in case something is in conflict. Looking at the MS GPT FAQ the MBR contains one type 0xEE partition that spans the disk. Just check this is the case I had someone tell me of an instance where they also found a difference between MBR and GPT.

H

ReplyQuote
Posted : 07/02/2014 1:29 pm
kbertens
(@kbertens)
Member

You said Encase is able to process the drive. What filesystem is available on the partitions?

ReplyQuote
Posted : 07/02/2014 2:05 pm
sgware
(@sgware)
Junior Member

Have you examined the image to determine if the PMBR and GPT header are where they are supposed to be and have the correct structure/data?

For example, the PMBR should be in physical sector 0 and have one partition table entry with a partition type of EE for a GPT partition. The GPT Header will point to the LBA of the first partition entry. The GPT header maybe in LBA 1.

If the device is mounted and not being read correctly the next step, for me, would be to look at it in a hex editor to see if it has somehow been corrupted.

Hope this helps.

ReplyQuote
Posted : 07/02/2014 8:38 pm
jaclaz
(@jaclaz)
Community Legend

@twjolson
You don't seem like spitballing to me, that's one of the thoughts I also had, hence the request for the disk model. )

@sgware
But if there is some corruption in "vital" areas, how come Encase and FTK imager are working fine? ?
It sounds more like the data being OK, but different ways of accessing/parsing/interpreting it making a difference, like through some OS API/filesystem recognizer/volume mounter (or *whatever*) vs. "direct" access. ?

jaclaz

ReplyQuote
Posted : 07/02/2014 10:51 pm
acarr31
(@acarr31)
Junior Member

During my initial examination I reviewed the PMBR and the following sectors in order to manually bookmark the GUID's for each partition from hex view. All five partition GUID's were located and were showed basic data partition which matches what EnCase was showing me.

Using EnCase's built in report functionality with the partitions selected the following information is available for each partition

Partition 1
Basic Data Partition
File system NTFS
Volume Name System

Partition 2
Basic Data Partition
File System FAT32
Volume Name NO NAME

Partition 3
Basic Data Partition
File System NTFS
Volume Name

Partition 4
Basic Data Partition
File System
Volume Name TI10649600F

Partition 5
Basic Data Partition
File System NTFS
Volume Name Recovery

Partition 4 is the OS partition, and the suspect's computer was functioning properly as of the day it was seized as far as I have been made aware by the case agent.

In addition, I tried using the Mount as Emulated Disk function of EnCase during my initial exam and it froze up and crashed it and did not successfully mount it.

ReplyQuote
Posted : 07/02/2014 10:52 pm
acarr31
(@acarr31)
Junior Member

The information for the HDD is as follows

Make Toshiba, Model MK6475GSX

ReplyQuote
Posted : 07/02/2014 10:54 pm
acarr31
(@acarr31)
Junior Member

The same issue has happened on another Windows 8 based hard drive and the drive information for that HDD is as follows

Make Toshiba, Model MQ01ABD032

ReplyQuote
Posted : 07/02/2014 10:55 pm
jaclaz
(@jaclaz)
Community Legend

The information for the HDD is as follows

Make Toshiba, Model MK6475GSX

Which is a 4Kb sector disk.
http//storage.toshiba.eu/cms/en/hdd/multimedia/product_detail.jsp?productid=415

The same issue has happened on another Windows 8 based hard drive and the drive information for that HDD is as follows

Make Toshiba, Model MQ01ABD032

Which is also 4Kb
http//storage.toshiba.eu/cms/en/hdd/computing/product_detail.jsp?productid=412

I would say that twjolson is the winner right now ) (though he may optionally wish to share part of the 1st prize with yours truly wink )

jaclaz

ReplyQuote
Posted : 07/02/2014 11:42 pm
athulin
(@athulin)
Community Legend

I would say that twjolson is the winner right now ) (though he may optionally wish to share part of the 1st prize with yours truly wink )

Well, … not until you can explain the reasoning behind it. Correlation is not necessarily causation.

I mean … the cited drives are still ATA drives. And that means 512byte sectors/logical blocks by default. ATA-7 or later allows large logical/physical sectors but the disk is still required to preserve the 'old' 'short' sector LB model 'in parallel' with the large-sector model.

That is, while Windows 8 may recognize the support for long sectors, and utilize it, by writing a physical sector 0 (4kbyte long), Windows 7 would (presumably) ignore the long sector support, and request LBA 0. And that has to correspond to the first 512bytes of the (long) physical sector 0 (assuming default block size).

Thus, if the drive is OK, there should not be a problem to write with one method and read with the other.

If some software got confused over if the wanted sector was a short one or a long one, things would not work out. Or if it recorded a long sector address when an LBA was expected. Or if some intermediate hardware translated incorrectly between the two modes of addressing.

But large sectors by itself …. no, there's got to be more to it than just that, doesn't it?

ReplyQuote
Posted : 08/02/2014 1:46 am
jaclaz
(@jaclaz)
Community Legend

Well, … not until you can explain the reasoning behind it. Correlation is not necessarily causation.

Sure ) , hence the "right now".

However the reference that twjolson used is likely to be this one
http//support.microsoft.com/kb/2510009/en-us

Like most of MS original documents, it is very likely to only contain partial truths, but, strangely enough, it seems almost clear.
Additionally there is this blog post (supposedly by Steven Sinofsky)
http//blogs.msdn.com/b/b8/archive/2011/11/29/enabling-large-disks-and-large-sectors-in-windows-8.aspx

Now the Toshiba disks are both 4kb sectored and "Advanced Format" (or 512e)
http//storage.toshiba.eu/cms/en/support_services/advanced_format.html
but it is still possible that under Windows 8 they are considered "Native 4Kb" and as such *somehow* differently partitioned/formatted/whatever.

As well the issue with an incompatibility with the actual Tableau thingy remains a possibility, and again this is the reason why I suggested inquiring with the manufacturer and making a few tests with Winfe's, Windows 7 and Windows 8 based.

Being a GPT disk the LBA0 (even if sized 512 bytes and read correctly) contains just a protective MBR, and how the "rest" is managed is one of those things for which AFAIK there is not much shared experience (and also scarce literature) as with anything connected with UEFI and GPT.

jaclaz

ReplyQuote
Posted : 08/02/2014 5:43 pm
sgware
(@sgware)
Junior Member

I think this discussion is heading in the right direction. Having read the MS docs and Toshiba specs 4K/AF compatibility with Win 7, the write blocker, or others such as drivers etc could be part of the issue.

I think it would be interesting to to see what happens without that hardware write blocker in line. Restoring the image to a test disk (same Toshiba drive) to a Win7 system. If you get to the point where a clone of the disk is mounted to a Win7 machine (SP1 or greater) please run the Fsutil fsinfo ntfsinfo x (where x represents the drive that you are checking) command and post the results? I would be interested in seeing how this is resolved.

I can see that a platform to acquire/investigate 4K/AF drives will become a necessity. Thank you for posting this and I hope the group/I can help you to a resolution.

ReplyQuote
Posted : 08/02/2014 7:07 pm
Page 1 / 2
Share: