How does one change the UUID of a Volume on Mac OS X to a SPECIFIED value?

Question

This is similar to the question asked here:

How does one change the UUID of a Volume on Mac OS X 10.6?

Only difference is I want to change it to a specific value, not a random one. The hfs.util only seems to do random.

I considered modifying the hfs.util source to allow me to specify values. As I was poking around the code looking for where to begin making changes I remembered why C is not my favorite language. Several compile errors and segfaults later, I lost enthusiasm for trying to modify this tool. I'm willing to have a go at it again after I get some rest, but I figure there has got to be an easier way to change a volume's UUID that I just don't know of.

So before I waste anymore time, does anyone know of an easy way to do this? Or would any C experts like to join my endeavor in making hfs.util change the UUID to a specified value?

Here are the changes I made to be able to compile the tool from source OS X 10.6.8:

hfsutil_jnl.c:

47: #include <hfs_fsctl.h>

hfsutil_main.c:

80: #include <uuid/uuid.h>
81: /* REMOVED */

And, as hinted in this article, added the following from line 166 in fs.c to hfsutil_main.c (since namespace.h isn't anywhere on the system):

static unsigned char kFSUUIDNamespaceSHA1[] = {0xB3,0xE2,0x0F,0x39,0xF2,0x92,0x11,0xD6,0x97,0xA4,0x00,0x30,0x65,0x43,0xEC,0xAC};

Lastly, I grabbed this file and added it to the working dir http://www.opensource.apple.com/source/xnu/xnu-1456.1.26/bsd/hfs/hfs_fsctl.h

Answer 1

I tackled this. I downloaded the source for hfs.util, made the changes you mentioned (so that it could compile), re-enabled the UUID functionality (like -s which is disabled in the current source), and added a new command (-S which is used to specify a UUID).

The format for the new command is this:

    sudo hfs.util -S disk0s2 xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

You have to use sudo or run as root, but you DO NOT have to dismount the volume (even if it is your current system volume).

However, I'm still debugging it (I'm terrible with C). I can run it error-free, but it is still effectively randomizing the new UUID with -S. Regardless of the UUID I specify, I'm still getting a different one.

If I get it working, I'll either post a diff here, or I'll find someplace to upload the modified source, and link to it from here.

If I fail, I'll probably still post the diff, and maybe someone else (who is better with C) can fix it. ;-)

EDIT: OK. I found what appears to be a major bug with functions that handle UUID string <--> binary functions in the Apple source code for hfs.util. As a binary value, it takes 4 (unsigned) 32-bit words to store a 128-bit UUID. The Apple source only appears to only process 16 hexadecimal characters (it should be 16 octets of 2 hexadecimal characters each). It also appears to use a defective structure to hold the UUID (it appears to only store a "high" 32-bit word and a "low" 32-bit word, but 4 (unsigned) 32-bit words would be needed). I can think I can fix it, but I have to change the structure and all the functions that use the structure (so it may take me a while).

EDIT #2: After spending way too much time debugging the Apple source for hfs.util (I'm really not a C programmer) it appears that Apple INTENTIONALLY only handles 64-bits when handling a UUID. The rest is generated from a hash of a 64-bit constant, computer component values, the current time, and so on. So if you used the same 64-bit "key" twice, you would still end up with two different UUIDs (even if you used the same computer, the time has still changed). As long as the actual write to the volume header sends the actual UUID (and not just a key), and as long as the volume header stores the actual UUID (and not just a key and/or values that can be used to compute the UUID), then there is hope. My debugging hasn't made it that far yet. I'll post again when I know more.