±Forensic Focus Partners
New Today: 2
New Yesterday: 5
±Forensic Focus Partner Links
· SQLite Database Forensics – ‘Sleep Cycle’ Case Study
· Data Recovery As A Medium For Email Forensics
· Carving out the Difference between Computer Forensics and E-Discovery
· Forensic Analysis of SQLite Databases: Free Lists, Write Ahead Log, Unallocated Space and Carving
· How Secure Is Your Password? A Friendly Advice from a Company That Breaks Passwords
· Using SQL as a date/time conversion tool
· Forensics and Bitcoin
· Investigation and Intelligence Framework (IIF) – an evidence extraction model for investigation
· Extracting data from dump of mobile devices running Android operating system
Windows 7 MBR system unable to view Windows 8 GPT HDD
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. 220.127.116.11. EnCase v. 18.104.22.168 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
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: msdn.microsoft.com/en-...63525.aspx
When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle.
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):
as this is something that - unlike the behaviour with "plain" MBR disks:
has not AFAIK been analyzed in detail (at least publicly).
And/or setting the USB device as Read Only (software write blocking).
- In theory there is no difference between theory and practice, but in practice there is. -
- Senior Member
A little digging shows that native 4k sectors are supported only by Windows 8.
I've never had this, so no promises.
- Senior Member
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.
ADF Solutions - Leaders in Digital Forensic Triage
Resources for Forensic Practitioners
- Senior Member
- Senior Member
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.