61 replies to this topic

[sebus]

If attached drive has NO letter assigned, how does Window calculate the GUID (highlighted)?

 

The last part is obviously MAC address of the VM, but the rest?

 

The Data column is not an issue, as it is explained well here or here

Also it is NOT the same value as displayed from mountvol (ofcourse not, disk vs volume)

Volume GUID is explained here on page 182 of

Forensic Computing by Anthony Sammes, Brian Jenkinson

with a calculator available here

 

[Wonko the Sane]

As a side note only:

Volume GUID (for those not  able to read the given link, like myself) is also explained here, it is a UUID V1:

https://www.forensic...592247/#6592247

 

and in my experience the online UUID converters have issues (cannot say about the given one on the link as I cannot reach it as well), but there is a tool that is accurate (at least in my tests) and exists in a Win32 version:

https://www.forensic...586892/#6586892

http://soft.rubypdf....idgen-ossp-uuid

 

Wonko

[erwan.l]

Nice thread 

It has been a while i have been wondering about this matter.

 

Just tried uuid -d my_guid : it does give me the date/time of my volume creation along with my computer mac address.

Good to know !

 

Is not the volume guid stored in the ntfs volume header?

See here some interesting work from Joachim Metz (part of libyal tools). 

 

edit:

-mounting/dismounting/mouting : volume guid is not changing (expected)

-mounting/changing disk id/dismounting/mounting : volume guid is changing

 

theory:

"reusing" the disk id of another (original) disk onto a new disk will make it so that the disk "inherits" the volume guid of the original disk?

[Wonko the Sane]

theory:

"reusing" the disk id of another (original) disk onto a new disk will make it so that the disk "inherits" the volume guid of the original disk?

There is no such thing as "disk id".

 

There is Disk Signature (at least on MBR, no idea if GPT style disks still have it) and offset to the Volume (which is the "data" in Registry), so I believe that yes, if you replicate the Disk Signature AND the Volume offset (and do not connect EVER two disks with the same signature at the same time) the Volume will get the same GUID.

 

The UUID's Sebus posted resolve to:

 

 

uuid -d eec3053c-1e26-11e9-80c1-00155d0b7f03
encode: STR: eec3053c-1e26-11e9-80c1-00155d0b7f03
SIV: 317368867059292612316266885207605083907
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 1 (time and node based)
content: time: 2019-01-22 09:20:17.485958.0 UTC
clock: 193 (usually random)
node: 00:15:5d:0b:7f:03 (global unicast)

and:

 

 

uuid -d 0661d25d-1301-4763-aadd-c6a242ff6ad4
encode: STR: 0661d25d-1301-4763-aadd-c6a242ff6ad4
SIV: 8483287450105015433748058961487030996
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 4 (random data based)
content: 06:61:D2:5D:13:01:07:63:2A:DD:C6:A2:42:FF:6A:D4
(no semantics: random data only)

So it seems more that the "valid" UUID (version 1) is the one in the Registry and not the one in the Mountvol command (version 4).

It would be interesting to see what happens if mountvol is actually used to mount the volume.

 

Wonko

[erwan.l]

There is no such thing as "disk id".

 

There is Disk Signature (at least on MBR, no idea if GPT style disks still have it) and offset to the Volume (which is the "data" in Registry), so I believe that yes, if you replicate the Disk Signature AND the Volume offset (and do not connect EVER two disks with the same signature at the same time) the Volume will get the same GUID.

 

 

My bad, wrong wording, yes I meant disk signature.

 

I confronted my theory against reality.

 

Setup

 

->disk 2 (f): signature : 100E67FD guid : \\?\Volume{91d802f6-1cdf-11e9-8341-94de80c2a41e}\

->disk 3 (g:) signature: 4F7847DB guid: \\?\Volume{9ea1daa2-1e78-11e9-8341-94de80c2a41e}\

 

Test

 

1-Unmount disk 2

2-Change disk signature on disk 3 to 100E67FD 

3-Unmount disk 3

4-Mount disk 3

 

Result

 

Disk 3 (f:) signature : 100E67FD  guid : \\?\Volume{91d802f6-1cdf-11e9-8341-94de80c2a41e}\

 

Not only did windows use guid from volume on disk 2 but it also assigned the drive letter previously used by the volume on disk 2.

 

The above little "experiment" was done on MBR disks.

Note that GPT disks also has a disk signature in the form of "{3F83A1FF-6EF0-4212-B5A3-ECDBF12B79DC}".

 

Regards,

Erwan

[Wonko the Sane]

Not only did windows use guid from volume on disk 2 but it also assigned the drive letter previously used by the volume on disk 2.

 

The above little "experiment" was done on MBR disks.

Note that GPT disks also have a disk signature in the form of "{3F83A1FF-6EF0-4212-B5A3-ECDBF12B79DC}".

Yep.

It is "normal" since you didn't delete the data in the Registry, for all that matters a disk and volume that was already mounted (and removed) was re-connected, thus having the same UUID (as it was a "known" volume) and the same drive letter (as it was, again a volume already mounted AND that particular drive letter was "free").

 

I am not familiar with the disk signature on GPT, where is it (on disk) on sector LBA1?

 

Wonko

[erwan.l]

I am not familiar with the disk signature on GPT, where is it (on disk) on sector LBA1?

 

 

sector 1, offset 0x38

 

https://en.wikipedia...Partition_Table or http://www.ntfs.com/...-part-table.htm

 

[sebus]

For GPT disks Volume offset is in 490 .

 

Thanks guys, I was just being completely stupid & was trying it all wrong.

The GUID bit in registry is just UUID time based & it depends on Disk ID (I think...)

 

And it is really simple.

Clonedisk disk-to-disk (select disc, not drive letter below it!)

Once copy is finished the destination disk is not visible, as it is EXACT copy (with signature etc)

 

So disconnect source (I work on VM, so easy), reboot & ... that is it if you do not need to work with open files.

 

I will test later, but expect that if one needs to work with open files then "shadow volume"-to-volume clone & :

 

- disconnect source

- copy Volume offset of destination & paste it to source in registry

- change Disk ID of destination to source's with diskpart (or hex as per above screenshot)

 

sebus

[erwan.l]

For GPT disks Volume offset is in 490 .

 

Thanks guys, I was just being completely stupid & was trying it all wrong.

The GUID bit in registry is just UUID time based & it depends on Disk ID (In think)

 

And it is really simple.

Clonedisk disk-to-disk (select disc, not drive letter below it!)

Once copy is finished the destination disk is not visible, as it is EXACT copy (with signature etc)

 

So disconnect source (I work on VM, so easy), reboot & ... that is it if you do not need to work with open files.

 

I will test later, but expect that if one needs to work with open files then "shadow volume"-to-volume clone & :

 

- disconnect source

- copy Volume offset of destination & paste it to source in registry

- change Disk ID of destination to source's with diskpart (or hex as per above screenshot)

 

sebus

 

Hot disk-to-disk works but you are "playing with matches" and before you know it could be the entire house burning

CloneDisk does lock/dismount your drive(s) while reading/writing but a process could pass by and mess it up.

 

I strongly recommend to create a snapshot (i use vscsc but vscopy or vshadow would do as well) with vscsc -wait x: and then do a (shadow) volume to volume in CloneDisk (available in latest version).

Con here is that you would be working at the volume level, not the disk level, hence ending with a different signature and possibly then have to take care of this matter as discussed in previous posts.

 

If your destination disk has the same partition table and original ID, i believe you can even skip the registry part : it may just be "plug and play".

[Wonko the Sane]

With MBR disks at least it is not possible to have two disks with the same signature connected at the same time, NT automatically changes the disk signature of one.

In newer Windows this possibly can be workaround setting disks offline but it is still risky business.

 

For real disks, in my simplicity and personally I backup the MBR in grub4dos (and take note of its Disk Signature, just in case), set to 00 the Magic Bytes and then image the disk and then restore the MBR and/or write back the 55AA).

 

See also:

http://reboot.pro/to...nsically-sound/

 

 

Wonko

[sebus]

Lets forget MBR disks, as everything (that I do work with) is GPT!

I do not know earlier versions, but in W7/Server 2012 R2 you can (at least straight after hot copy) have 2 disks with same signature, just one is offline (the later one, destination)

 

Again, this question was about live environment, not  doing this process offline (as that is not an issue)

 

Is that version 2.3.7 32-bit that has volume to volume option?

Or 3.2.6 64-bit also have it?

 

sebus

[erwan.l]

Lets forget MBR disks, as everything (that I do work with) is GPT!

I do not know earlier versions, but in W7/Server 2012 R2 you can (at least straight after hot copy) have 2 disks with same signature, just one is offline (the later one, destination)

 

Again, this question was about live environment, not  doing this process offline (as that is not an issue)

 

Is that version 2.3.7 32-bit that has volume to volume option?

Or 3.2.6 64-bit also have it?

 

sebus

 

Version 2.3.7 32-bit has this "volume to volume" option.

Volume can be shadow copy volume.

I need to catch up on the x64 version.

[erwan.l]

I reproduced my little experiment from post #5 but this time with GPT.

 

And this time I am getting a different result (not the one I expected).

 

My setup

 

disk2

disk signature: {3F83A1FF-6EF0-4212-B5A3-ECDBF12B79FF}

f: (partition offset=65536)

VolumeGUID: \\?\Volume{9ea1db47-1e78-11e9-8341-94de80c2a41e}\

 

disk3

disk signature: {DF3B3A96-53BF-45C1-A5B5-4B50FA7B1B77}

g: (partition offset=65536)

->VolumeGUID: \\?\Volume{9ea1e43f-1e78-11e9-8341-94de80c2a41e}\

 

Test

 

• unmount disk2
• change disk signature on disk3 with {3F83A1FF-6EF0-4212-B5A3-ECDBF12B79FF} (i.e the one from disk2)
• unmount disk3
• mount disk3

Result

 

• volumeguid = \\?\Volume{9ea1e43f-1e78-11e9-8341-94de80c2a41e}\ (no change...)

 

This time, windows was not "fooled" and assigned the original volumeguid on disk3 rather than detecting it as volumeguid on disk2, and this despite change the disk signature on disk3 to the signature from disk2.

 

So there is something "extra" on gpt disks.

Maybe the offset 0x490 on sector 2 which Sebus mentionned.

Will do more testing...

[sebus]

Exactly the same what I tested last night.

 

I can change Disk ID perfectly fine with diskpart, I can change Volume offset @ 00000490 with hex editor, but it does not change (reboots, unmounts etc) what is being reported by mountvol.

 

Even attaching to a different machine it stays the same as original!

 

Where is that thing stored then?

 

sebus

[Wonko the Sane]

 

• change disk signature on disk3 with {3F83A1FF-6EF0-4212-B5A3-ECDBF12B79FF} (i.e the one from disk2)

 

Change disk signature WHERE and HOW EXACTLY?

 

I mean, GPT disks have backup of the GPT partition data, did you change the data in BOTH the "main" sector AND in the backup one or only in the first?

It would be entirely possible that Windows checks this kind of data and "corrects" the "main" sector with the backup one.

Additionally what (EXACTLY) is in the Registry for the mounteddevices volume?

Maybe the identification on GPT disks is more sophisticated than Disk Signature+Offset to Volume.

 

Wonko

[erwan.l]

Change disk signature WHERE and HOW EXACTLY?

 

I mean, GPT disks have backup of the GPT partition data, did you change the data in BOTH the "main" sector AND in the backup one or only in the first?

It would be entirely possible that Windows checks this kind of data and "corrects" the "main" sector with the backup one.

Additionally what (EXACTLY) is in the Registry for the mounteddevices volume?

Maybe the identification on GPT disks is more sophisticated than Disk Signature+Offset to Volume.

 

Wonko

 

I used my own tools with IOCTL_DISK_GET_DRIVE_LAYOUT_EX and diskpart.

Each time : same result.

 

My destination disk is a fresh new disk each time.

 

My source disk is always the same one.

 

 

Now, I just realise that GPT an attribute called partitionid (for each partition obviously).

Which matches the volume guid.

Something you dont have with MBR.

 

This may match offset 0x490 of sector 2 which Sebus mentionned in post #8.

 

Going to update that field as well next to the disk signature and see what I get.

[erwan.l]

ok i can confirmed !

 

When dealing with GPT disk, the volumeguid is based on BOTH the disk signature AND the partitionid.

And possibly the offset although I did not test that and therefore cannot confirm this part.

 

My setup

 

disk2

disk signature: {3F83A1FF-6EF0-4212-B5A3-ECDBF12B79FF}

f: (partition offset=65536)

VolumeGUID: \\?\Volume{9ea1db47-1e78-11e9-8341-94de80c2a41e}\

GPT partitionid: {9ea1db47-1e78-11e9-8341-94de80c2a41e}

 

disk3

disk signature: {DF3B3A96-53BF-45C1-A5B5-4B50FA7B1B77}

g: (partition offset=65536)

VolumeGUID: \\?\Volume{9ea1e43f-1e78-11e9-8341-94de80c2a41e}\

GPT partitionid: {9ea1e43f-1e78-11e9-8341-94de80c2a41e}

 

Test

 

• unmount disk2
• change disk signature on disk3 with {3F83A1FF-6EF0-4212-B5A3-ECDBF12B79FF} (i.e the one from disk2)
• change partitionid on partition 1 with {9ea1db47-1e78-11e9-8341-94de80c2a41e} (i.e the from part1 on disk2)
• unmount disk3 (going disk offline might achieve the same)
• mount disk3 (going disk online might achieve the same)

Result

 

• volumeguid = \\?\Volume{9ea1db47-1e78-11e9-8341-94de80c2a41e}\ 
• partitionid = {9EA1DB47-1E78-11E9-8341-94DE80C2A41E}

 

I did not check yet in HxD but I am pretty sure this partitionid is at offset 0x490 of sector 2.

We know already that the disk signature is at offset 0x38 of sector 1.

 

All operations were performed with latest clonedisk (x32) version.

 

 

[sebus]

But changing Disk ID (what you call signature) with diskpart AND Volume offset at 0x490 of sector 2

 

is NOT enough!

 

If you did not change in hex, then HOW did you change it?

 

On my 1Gb task vhdx the Volume offset (ID) is at 0x490 AND at 3FFFBE90 (in sector 2097119 of 2097151) - which I think is in secondary GPT header as per this

 

sebus

[erwan.l]

But changing Disk ID (what you call signature) with diskpart AND Volume offset at 0x490 of sector 2

 

is NOT enough!

 

If you did not change in hex, then HOW did you change it?

 

On my 1Gb task vhdx the Volume offset (ID) is at 0x490 AND at 3FFFBE90 (in sector 2097119 of 2097151)

 

sebus

 

 

All operations were performed in CloneDisk latest version (from today...).

Disk signature is wrongly called DiskID in CloneDisk (i will fix this).

 

Changing these 2 items did the trick for me.

My "new" volume inherited the windows volume GUID from a previous disk/partition.

 

Regards,

Erwan

[sebus]

Yes, but you changing them how (I know in CD just clicking)

 

CloneDisk latest version (from today...) - would be downloadable from where?

 

sebus

[erwan.l]

Yes, but you changing them how (I know in CD just clicking)

 

CloneDisk latest version (from today...) - would be downloadable from where?

 

sebus

 

If about "how does clonedisk perform these task?", clonedisk is all about windows API (i.e not hexa editing bytes).

I do not recommend hexa editing your disk/partition but rather use tools like diskpart or clonedisk as these use windows API which will take care of the internal mechanic.

 

If about "how one does this in clonedisk", this takes place in the partition editor (see screenshot below).

 

CloneDisk main thread here.

Direct (x32) download here.

 

Current version

clonedisk.exe 
2.3.7.0
24/01/2019 14:35 
A0B7C0877020BDD4C87684DFDC61EFDF

[sebus]

I am interested in what does the Volume GUID edit, as in my searches I did not come across any tool that can do it (only the VolumeID by Sysinternals, but that is not what would be done on GPT disk, right?)

 

sebus

[sebus]

I think it was my error (in executing CD too soon)

Done it one more time & numbering is OK, so please ignore!

[erwan.l]

I am interested in what does the Volume GUID edit, as in my searches I did not come across any tool that can do it (only the VolumeID by Sysinternals, but that is not what would be done on GPT disk, right?)

 

sebus

 

clonedisk can modify partitionid field .

it uses IOCTL_DISK_SET_DRIVE_LAYOUT_EX IOCTL ioctl.

 

partitionid (within a gpt partition header) is the counterpart of the windows volumeguid.

 

partitionid is not to be confused with disk signature (sometimes referred as disk id).

[erwan.l]

Volume-to-volume errors out with

 

could not retrieve source size

 

Where source in that case is vscsc created snapshot with add dos device letter (or not)

 

taking this one thru PM.