Sky+, DNLA, UPnP, the iPad app and the IP control protocol

Sky launched an update to the iPad Sky+ app this week, which enables the ability to remotely control your Sky box over IP, if you’re updated to the new picasso interface. Obviously, I needed to figure out how it all works, and how I could write my own code to control it. Here are my inital findings.

The service is a DNLA/UPnP type thing, that runs on http://[sky-box-ip]:49153/

Authentication is provided simply by User-Agent. SKY_skyplus works.

More information is after the break.

It returns the following information:

[codebox 1]

The new Sky control protocol used in the iPad Sky+ app uses this webservice. I believe the description0 file is to do with the remote control service (hence references to RC2). The description0 file exposes the first 3 services provided by the Sky box’s server.

The example flow works like this with the iPad App:

iPad broadcasts to subnet request for Sky boxes. Sky box replies with its IP and a link to description0.xml via the SSDP service discovery protocol of UPnP. The iPad grabs this description0.xml file and then gets description2.xml. This file contains a very similar set of information, but for the SkyBrowse service – I suspect this is the planner editing bits, rather than a listings search.. I suspect the listings stuff still actually comes from sky’s webservices, rather than the local skybox. But I suppose it could contain information about the series link, and the “Watch on TV” command.

Then the iPad app sends a subscribe and a callback URL. This runs on port 51000 on your iPad and uses a SOAP urn of nds-com:serviceID:SkyPlay2. Not sure if this will ever be useful for us geeks, I doubt we’d ever want to send our own replies to the app?

The Sky Box then sends a SOAP wrapped HTTP packet with contains a SID which is a uuid – I think this is probably the session ID used for authentication on further requests, but i’m struggling to see where that is sent back in future requests at the moment.

A bunch of nonsense looking (from a ascii point of view) packets are sent throughout this, I don’t know that much about SOAP, so hopefully they might be standard things we don’t need to worry about. These seem to be basic syn/acks. I assume it’s proactive about keeping connections alive.

The fun stuff starts when you want to pause or so something like that. These are just simple SOAPACTIONs with urns like: “urn:schemas-nds-com:service:SkyPlay:2#Pause”. Once one of those has been ACK’d by the Sky Box, the iPad app sends another packet, but this time containing XML data with just seems to repeat the command, but in XML form.

The good news is, there doesn’t look like there is any encryption here. The next step is to try and make the Sky Box pause and play on demand using my own code, which I think means needing to reverse engineer the wsdl. I’ll write another post with more information once I get round to it.

Update 1:Just to clarify, there is 5 services exposed by this code: SkyPlay2, SkyCM2, SkyRC2, SkyBook2, SkyBrowse2.
Also, there is no description1.xml file (No idea why not…) 

Just a quick note to Sky or NDS, if they read this: I’m hoping this kind of playing isn’t a problem for you guys. If it is, just drop me an email ( and i’ll remove the blog posts and stop trying to figure out more. I’m not trying to do anything evil. If i discover anything that could be used for piracy (such as serving content over DNLA from the device) i’ll obviously not post about it. Just been a geek here.