3 replies to this topic

[steve6375]

It seems if you set a drive volume to Readonly status using Diskpart (only works for 'Fixed' disks) then Diskpart just overwrites a sector of your disk and completely destroys any code you may have had in LBA2  (third sector of the disk). This includes overwriting a sector of the grub4dos boot code if it was present!

See my blog for more details.

[Wonko the Sane]

It seems if you set a drive volume to Readonly status using Diskpart (only works for 'Fixed' disks) then Diskpart just overwrites a sector of your disk and completely destroys any code you may have had in LBA2  (third sector of the disk). This includes overwriting a sector of the grub4dos boot code if it was present!
See my blog for more details.

Interesting (I would dare to say fascinating) 
 
That's a nice confirmation of the validity of my usual approach - long before this particular "feature" was "invented" - to NOT use grub4dos grldr.mbr (or anything bigger than 512bytes) installed to MBR +hidden sectors. as these latter may be used by any kind of "other things" that may create a conflict.
 
Some ideas/tools/tests not entirely unconnected, were made here (JFYI):
http://reboot.pro/to...nsically-sound/
 
As a side note, the grub4dos grldr.mbr has a set of NOP's (0x90's) as values in LBA2, so it is possible that this behaviour was previewed or "considered" by Chenall .
 
Another thing that might need some further tests/confirmations is that the bytes sequence you found (which are not 16 as there is a 0x10 in second row):

A2 A0 D0 EB E5 B9 33 44 - 87 C0 68 B6 B7 26 99 C7
00 00 00 00 00 00 00 10 - 00 00 00 00 00 00 00 00

are actually a Linux GPT "data" partiton entry incipit
http://petio.org/boo...king_page3.html
 
 

a2 a0 d0 eb e5 b9 33 44 87 c0 68 b6 b7 26 99 c7
ba 65 a2 3e 01 ba 70 47 b9 da e1 ff 1d 69 9d 26

.....

The value EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 is the GUID which defines a "data partition" for linux.
Because of the nasty endian thing, we have to descramble the bytes. Looking at the structure, we see that GUIDs are grouped in byte sizes according to this pattern: 4+2+2+1+1+1+1+1+1+1+1. In other words, the first four bytes will be in reverse order, the next two are swapped, the following two are swapped, and the last eight are in the appropriate position. So, what we see as A2A0D0EB-E5B9-3344-87C068B6B72699C7 is really just a weird way to write EBD0A0A2-B9E5-4433-87C068B6B72699C7


To make it clear, my first disk has a type of EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, and a GUID of 3EA265BA-BA01-4770-B9DAE1FF1D699D26

seemingly with a GUID of 00000000-0000-1000-0000000000000000  

 

Wonko

[steve6375]

I missed that 10h byte! well spotted! I wonder if the volume is also WP in linux?

[Wonko the Sane]

I missed that 10h byte! well spotted! I wonder if the volume is also WP in linux?

Naaah.

The reference given talks of "Linux data partition", but that GUID is actually that of a "Basic Data Partition":

http://en.wikipedia....Partition_Table

http://en.wikipedia...._data_partition

and Linux uses it only because there are (possibly "were") NO alternatives.

 

AFAICU, the good MS guys had to invent *something* for XP 64 bit booting with a GPT disk, and - not surprisingly in their good ol' tradition of re-using code for other scopes (thus breaking "standards" they themselves set earlier) - are re-using it to "confuse" their own Mount Manager that probably, not understanding if the disk is MBR or GPT decides - to be on the safe side - to mount all volumes on the disk as "Read Only".

 

Now if you call something "globally unique identifier" you would expect (at least lexically) that it is something similar to a volume (or device) serial , i.e. something that is unique to that particular volume (or device) why what they were able to express with one single byte (the partition ID) is now represented for - ALL volumes of a same kind - by a senseless 16 bytes sequence of bytes.

 

As a matter of fact, besides using 16 times the data, they also loose (definitely) some "resolution".

Till now (though not "certain" you could know that if a partition ID of 06 was in the MBR, then probably you had a FAT16 volume (and that should have been addressed through CHS) or if you had a 07 one it would have been probably a NTFS volume (HPFS are relatively rare), but recently they had already undermined this with exFAT using senselessly the same 07 ID, see:

http://www.forensicf...570136/#6570136

with GUID's they loose even the last remains of this probability to know in advance (without parsing the bootsector) the actual filesystem used on the volume.

We have now 16 bytes of data (that is 256^16 - i.e. zillions  different possible values ) used to represent (currently) less than 100 (one hundred) different partition types.

 

Wonko