{"id":48,"date":"2008-08-08T16:50:52","date_gmt":"2008-08-08T23:50:52","guid":{"rendered":"http:\/\/www.dreness.com\/blog\/?p=48"},"modified":"2019-12-07T17:10:16","modified_gmt":"2019-12-08T00:10:16","slug":"hacking-time-machine","status":"publish","type":"post","link":"https:\/\/dreness.com\/blog\/archives\/48","title":{"rendered":"Hacking Time Machine"},"content":{"rendered":"

It’s “hack some shit up” Friday. Everybody ready?<\/p>\n

Have a Time Capsule or Mac OS X Server configured to provide network time machine backups? Of course you do! Let’s examine the client \/ server interaction.<\/p>\n

The Time Machine preference pane provides a list of available backup volumes. This list includes local volumes as well as network volumes. Mac OS X makes extensive use of multicast dns for service discovery, so let’s check there first. Get yourself a copy of Bonjour Browser<\/a>, then fire it up and look under ‘local’ for things that seem interesting. Ooo there’s one called “adisk”, let’s check in there…<\/p>\n

\"\"<\/a><\/p>\n

From http:\/\/www.dns-sd.org\/ServiceTypes.html<\/a> we see:<\/p>\n

adisk<\/strong>          Automatic Disk Discovery\r\n                Bob Bradley <bradley\u00c2\u00a0at\u00c2\u00a0apple.com>\r\n                Defined TXT keys: sys, dkX<\/pre>\n
We could read a bit more<\/a> about service discovery via multicast dns to learn that:<\/p>\n
DNS-SD uses DNS TXT records to store arbitrary name\/value pairs\r\nconveying additional information about the named service. Each\r\nname\/value pair is encoded as its own constituent string within the\r\nDNS TXT record, in the form \"name=value\".\r\n...\r\nThe intention of DNS-SD TXT records is to convey a small amount of\r\nuseful additional information about a service. Ideally it SHOULD NOT\r\nbe necessary for a client to retrieve this additional information\r\nbefore it can usefully establish a connection to the service. For a\r\nwell-designed TCP-based application protocol, it should be possible,\r\nknowing only the host name and port number, to open a connection\r\nto that listening process, and then perform version- or feature-\r\nnegotiation to determine the capabilities of the service instance.\r\nFor example, when connecting to an AppleShare server over TCP, the\r\nclient enters into a protocol exchange with the server to determine\r\nwhich version of the AppleShare protocol the server implements, and\r\nwhich optional features or capabilities (if any) are available.<\/pre>\n
Ok, so there’s a record there, and along with the standard parts of the record, there are two additional key \/ value pairs in the text record portion. The meaning of the keys and values is probably only known for sure by Time Machine and friends, but certainly some of that data looks familiar.<\/p>\n
First there’s the IPv4 address… that’s probably provided automatically when the record is published, based on the machine’s current IP address. IPv6 address follows, again we needn’t worry about that. The port number is listed at 9, which is ‘discard’, so this is probably not used. What port *is* used, then? Well, we know that Time Machine over the network supports either AFP or SMB, so it’s going to be one of those two. Seems like AFP would be most common, just since it is the APPLE file protocol and whatnot…<\/p>\n
Then we have the sys and dk0 items… well I dunno what waMA means (something something mac address?), but what follows certainly looks like a MAC address… and sure enough, it matches the MAC address on my Time Capsule.<\/p>\n
Note also that the second key in the shown record is dk0, whereas the spec says the defined TXT keys are “sys, dkX”. The “X” here suggests that there might be more than one of these keys, and they are numbered starting from 0 and counting up. Let’s pick appart the dk0 entry.<\/p>\n
dk0=adVF=0xa1,adVN=backupz,adVU=AF9AC8F1-BCF5-3E63-9EBD-CD171CF5061B<\/pre>\n