Has anyone got anywhere with figuring out how Appletv-Validation and the pairing system works yet?
This is just a bunch of notes I've collected on how iTunes talks with the AppleTV
The general pairing sequence goes like this afaict
iTunes Starts up, AppleTV detects it and says
POST /ript/setpaireddeviceinfo?machine-id=0x0000000000000000 HTTP/1.1
to iTunes. Which responds, confirming the GUID.
iTunes connects to the AppleTV to synchronise fairplay certificates. At this point no Appletv-Validation headers have been issued by iTunes yet.
POST /ript/fp-setup?fairPlayID=0000000000000000.0000000000000000&fp-make-new=1 HTTP/1.1
The AppleTV seems to send back a certificate in response. They both have the FPLY header on them. The data sent by iTunes is different each session, although some (non-header) parts stay the same each time you pair they are largely different. This is probably the key to figuring out how to talk to the AppleTV. See the tables below for some details of parts which vary.
Another hit from iTunes to he AppleTV to fp-setup. This message is *always* different despite the contents of the first fp-setup hit. I think this is probably the part responsible for the Appletv-Validation header.
POST /ript/fp-setup?fairPlayID=0000000000000000.00000000000000000 HTTP/1.1
iTunes get device information from the AppleTV. iTunes sends the first Appletv-Validation header here. The AppleTV sends back whatever iTunes set it's configuration to.
GET /ript/getdeviceprefs?fairPlayID=0000000000000000.00000000000000000 HTTP/1.1
I'm guessing if we can get getdeviceprefs to return then everything else will follow on from there pretty easily, unfortunately I can't figure out how the Appletv-Validation headers are calculated. I know at least the first 31 bytes are always the same. And that 64-72 are always 00000010. It doesn't appear to be a hash of the message content since it always changes, and every session seems to be different. Perhaps the data sent in the first fp-setup hit initialises a PRNG which is then used by the AppleTV and iTunes to validate requests?
Despite running on the same port as DAAP the similarity seems to end there, most communication is done using XML plist files. The fairplay exchange however does seem somewhat similar though since the FPLY header looks like a DAAP message tag.
Poking around in the output of strings on the iTunes 7.1.1 binary reveals that some of the content in the fp-setup hits is hardcoded to be one of 10 different values.
FP.3333AF060823AF0001AF0000100 FP.3333AF060823AF0001AF0000090 FP.3333AF060823AF0001AF0000080 FP.3333AF060823AF0001AF0000070 FP.3333AF060823AF0001AF0000060 FP.3333AF060823AF0001AF0000050 FP.3333AF060823AF0001AF0000040 FP.3333AF060823AF0001AF0000030 FP.3333AF060823AF0001AF0000020 FP.3333AF060823AF0001AF0000010
From AppleTVs Finder
"AppleTV.3333AF070124AF0001AF0000100 "AppleTV.3333AF070124AF0001AF0000090 "AppleTV.3333AF070124AF0001AF0000080 "AppleTV.3333AF070124AF0001AF0000070 "AppleTV.3333AF070124AF0001AF0000060 "AppleTV.3333AF070124AF0001AF0000050 "AppleTV.3333AF070124AF0001AF0000040 "AppleTV.3333AF070124AF0001AF0000030 "AppleTV.3333AF070124AF0001AF0000020 "AppleTV.3333AF070124AF0001AF0000010
I've been running a packet dump and restarting iTunes every 20 seconds for the past half hour or so and it looks like iTunes will send 1 of 10 different messages based on the above table, however the AppleTV sends a unique response every time.
Remark: I started syncing with via AppleTV's wireless interface. Was successful. Then I changed my AppleTV setup to wired. Syncing did not work anymore. I canceled the AppleTV in my iTunes preferences and recreated on the AppleTV the connection to my iTunes. Had to enter the passcode again. Afterwards syncing was successful again. --> Conclusion: The interface ID (MAC address) seems to be included in the validation algorithm.