![]() ![]() The remote does however continue after this by passing a session id along when asking for information, so it could be I have to return a session id on login, after which the session id can be used to identify connected remotes. Nice for security, but for now I'll guess that part will be happy with another '200 ok'. So far I know the remote sends a login request with a paring-guid or something, at least it's a magic number that should identify the remote to iTunes so iTunes can check if it's really paired. The next step is to send some server info (and see what the remote likes and doesn't like) and then figure out the login process. It should be valid http traffic, actually it also starts with '200 ok', so I know I succeeded in pairing. Wireshark seems to be able to decompress most of it, but the response the remote sends to complete pairing seems to be compressed too and I haven't succeeded in decompressing it yet. It's easy to get this from iTunes (just forward the request), the real issue is that almost everything that iTunes and the Remote pass to eachother is gzip or zlib compressed. So what's next? Well now that it's paired the remote will connect to the port listed for the touch-able service and request server info ('GET /server-info HTTP/1.1'). Not that I really care that much about it being legal (just applies to this case), if someone else would solve the issue I'd be happy to use it. This pairing process is currently quite complicated, but I don't think I'm able to solve the hashing riddle without reverse engineering iTunes or the remote application, but I'm not sure I would actually manage to do that and also I'm not sure if it would be legal to do so. Now you should have paired your iTunes remote with your computer. When forwarding the request, be sure to replace the database id iTunes passes along for the id you entered as name in rvice. You can do this by just copying/pasting the request iTunes made into telnet or netcat connected to the real remote app. #Itunes remote no libraries found code#Because we used the service pairing code from the real remote for our fake remote, and typed the correct pincode, the remote will be happy if we forward the request. Now if I click on 'Test remote' and enter my pin, iTunes sends a nice pairing-code. ![]() In the case with our fake remote, we can run netcat on port 50508 (port I chose/used), to do this, run 'nc -l -p 50508' in a terminal. ![]() I have not even tried to figure out how it's calculated, except for the fact that it's just as long as a md5 sum. The pairing code seems to be a hash of the pairing code the _touch-remote._tcp service lists combined with the pin code. The request will feature a pairing-code and a database id, both as GET vars. Actually it probably should be seen as a DAAP request, but since DAAP is just special http it won't really matter. As soon as you enter the code iTunes will make a http request to the port the _touch-remote._tcp service is running on (changes everytime on ipod touch, always seems to be port 505xx). When you click on a remote in iTunes it asks you to enter a pincode. CtlN is the name the remote app will list as the library name, it actually works. I changed both numbers (but kept the difference the same) because I would otherwise immediately get an error that the remote was not paired, seems it was connecting to iTunes (duplicate IDs). DbId is almost the same as name, in my case it happened to be 3 more than DbId. Name is obviously an identifier, this is how the remote will find the server after the server application has requested pairing. This file has some magic strings in it too, but these are less interesting. Now on my laptop with iTunes (in Windows) I immediately see 'Test remote' appear at the remotes list, isn't that great? I always first click 'Add library' (I assume that's what it is, I've got mine set to Dutch.), then copy the id, then save the file (make sure to keep the pincode screen open, new pincode means new pairing code). Because ultimately my goal is to have the remote app talk to my own application, I will need to copy this from the ipod as well. The next bold string is to be replaced with the paircode. The first bold string is to be replaced with your iPod's id exported in _touch-remote._tcp on your ipod (it actually is the service name, as the xml shows). You need to set up two services for your zeroconf implementation, I'm using avahi so I made two files in /etc/avahi/services: You need a working installation of a zeroconf implementation, the implementation of choice is avahi in my case. I got a bit further today, but first I'll start with information you would need to try this yourself. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |