I ran fsutil command on it when it was mounted correctly and this reported 512b/sector
)
Yes/No. 😯
Meaning that fsutil command has TWO values
http//
"Bytes per sector" is 512 bytes BOTH for "real" 512 bytes/sector disk and for "AF disks".
"Bytes per Physical Sector" is the one that may make a difference
512/512 -> "normal" plain 512 bytes sector
512/4096 -> AF or "512E" disk
4096/4096 -> "native" 4k disk
jaclaz
Right….. so after downloading and installing the hotfix mentioned in the Microsoft KB article that you linked to jaclaz I have run fsutil again over the same image file once again mounted with a cache in EnCase PDE and although I now have a result for 'Bytes Per Physical Sector' it is reported as <Not Supported>.
When I run this over my C drive there is no issue and it reports 'Bytes Per Physical Sector' as 512.
So I'm afraid I am no closer to determining whether this particular drive had native 4096 sectors or not. Any other suggestions for how to check this? Please bear in mind that my workstation is not connected to the internet and cannot be connected.
Any other suggestions for how to check this?
I don't know. (
It "could be" a 4K AF drive but since the stupid fsutil does not provide info I have no ideas.
If this is the case, any "software" will probably use the 512 byte sector provided by the "internal" translation.
Check on the label of the actual disk, on the mentioned thread
http//
the firmware KC43 is 512/4096 (but has NOT the "AF logo)
http//
whilst KC44 and KC45 additionally sport the AF logo (near the bottom of the label)
http//
Do you remember the good ol'times when on the label of the hard disk there was
- geometry
- total sectors
- capacity expressed in bytes
- jumper setting illustrations
(and when the same things were on specifications sheet)?
jaclaz
Ah-ha!!! Thank you jaclaz….now we are getting somewhere. I have just checked the photo that the technician took of the drive when he imaged it and it is firmware KC65 and is indeed sporting a very fetching AF logo towards the top right of the label, next to the Serial ATA logo.
So I guess that is where the problems lie, in both Windows 7 and other third party software being unable to correctly interpret the sector mapping. Interesting that enabling caching in EnCase fixes this however. It is also interesting that the problem does not exist across all partitions on the disk….. when mounted (in FTK Imager or EnCase) this disk image has 6 partitions and some of them are readable by Windows 7 while the main system (Windows 8 ) partition is not until you have a dynamic cache, even though it's reported (fsutil) logical sectors are still 512 bytes and I can see that MFT records are indeed occupying two 512 byte sectors still.
Time to educate the others in my lab so we can work around this, the joy of the shifting goalposts in a technology industry! That's why we love it though 😉
and I can see that MFT records are indeed occupying two 512 byte sectors still.
No. (
If you are looking at the first record of the $MFT, you are seeing the first quarter of a 4096 bytes sector *somehow* emulated or "rendered" as two 512 bytes sector.
The distinctions is essentially "philosophical/thoretical", but, as seen, it may have also practical consequences, and I find important to underline how when it comes to these AF drives there is an added intermediate layer of "translation".
http//
The translation of the 4096-byte physical format to a virtual 512-byte increment is transparent to the entity accessing the hard disk drive. Read and write commands are issued to Advanced Format drives in the same format as legacy drives. However, during the read process, the Advanced Format hard drive loads the entire 4096-byte sector containing the requested 512-byte data into memory located on the drive. The emulation firmware extracts and re-formats the specific data into a 512-byte chunk before sending the data to the host. The entire process typically occurs with little or no degradation in performance.
jaclaz
Well, there you go, we can but work around these things!
Will no doubt have an effect on data recovery methodology as well……
That's very clever/sneaky of the drive twisted
Thank you all that helped for being patient in my pursuit to identify the cause and solution to this problem. I have been extremely busy lately and I apologize for the delay in my response to testing.
After consulting with Digital Intelligence (and previously Microsoft) and further testing it appears to be an issue with Windows 7 resulting from the Tableau Ultrabay 3d's interaction with the Windows 8 operating system drive connected to it.
Digital Intelligence tech support and I conducted some testing with Windows 8 MBR systems, Windows 8 GPT systems and several write blockers to identify what caused the anomaly I previously wrote about. When a drive was partitioned MBR with Windows 8 the Windows 7 system did not have an issue identifying partitions and providing logical access. When the drive was partitioned GPT through a system using EUFI, the Windows 7 system analyzing it would not provide logical access (these tests were performed using Advanced Format HDD). So this eliminated the Advanced format drive as being the cause because it could identify and examine the partitions when an MBR was enabled.
The next step was identifying if the write blocker was the root cause of the issue. The same scenarios were tested out with an Ultrabay II write blocker (a bit older than the Ultrabay 3d) and the Ultrabay II write blocker did not have an issue seeing the partitions. Also, the Windows 8 GPT OS drive was connected to the Ultrabay 3D with read/write enabled and the Windows 7 system was then able to provide logical access.
The same tests were conducted using an Ultrabay 3d write-blocker connected to a Windows 8 exam system and the error did not occur.
Due to the results of these tests it is the conclusion of the Digital Intelligence tech support staff that the error in access is caused by Windows 7 itself taking issue with the communication of the Ultrabay 3d to Windows 7 that the drive is write-protected. The earlier Tableau write-blocking devices did not communicate that information to Windows and therefore it worked using the older devices. Also, since the test worked just fine using a Windows 8 exam machine it appears to be directly related to the earlier versions of Windows not liking that they can't "touch" the write protected GPT drive.
So this appears to be a limited error only affecting Windows 7 (and likely earlier) examination systems running a Tableau Ultrabay 3D write-blocker against a Windows 8 GPT partitioned operating system drive from a EUFI enabled system. The Advanced Format HDD didn't appear to have any influence on the testing.
Thank you all for your help and I hope that this may help anyone else that encounters this issue.
…
The next step was identifying if the write blocker was the root cause of the issue. The same scenarios were tested out with an Ultrabay II write blocker (a bit older than the Ultrabay 3d) and the Ultrabay II write blocker did not have an issue seeing the partitions. Also, the Windows 8 GPT OS drive was connected to the Ultrabay 3D with read/write enabled and the Windows 7 system was then able to provide logical access.The same tests were conducted using an Ultrabay 3d write-blocker connected to a Windows 8 exam system and the error did not occur.
Due to the results of these tests it is the conclusion of the Digital Intelligence tech support staff that the error in access is caused by Windows 7 itself taking issue with the communication of the Ultrabay 3d to Windows 7 that the drive is write-protected.
….
First thing thank you for "finalizing" the thread and reporting in such great the tests performed and the end result.
Allow me however to have a slightly different opinion, if there is a culprit it is the actual Ultrabay 3D (or it's firmware).
With all due respect for the good Digital Intelligence guys ) , we are talking of Windows 7 (please read as the probably most used OS on forensics machines) and it playing not well with the specific model of write blocker when examining a UEFI/GPT Windows 8 disk (please read as soon to be among the most common piece of evidence that one might need to examine).
I mean, it's not like (say) BeOS is not compatible with the Ultrabay 3d when examining Solaris 9 disks wink .
On the other hand *something* has definitely changed between Windows 7 and Windows 8, and I suspect that the behaviour noted/noticed here
http//
about different version of WinFE behaving slightly different when it comes to setting volumes as "read only" is *somehow* connected to the issue you found with the write blocker.
So, putting anyway the blame on the good MS guys is not completely wrong. 😯
In any case, the good news are that the older thingy worked fine, so that we can use properly the "legacy" adjective for the Ultrabay II
http//homepage.ntlworld.com./jonathan.deboynepollard/FGA/legacy-is-not-a-pejorative.html
jaclaz