OK thanks. As you said it looks like Premiere (192.168.1.151) is communicating on port 1393 with the iPad (192.168.1.138) using TCP/IP communication. I don't see any http/https level communication between them and therefore there is no header information to look at or anything else interesting to look at. So doesn't look like network sniffing is going to be too useful...

Use the iPad to navigate around the Premiere, as if it were only a remote control, and make note of the action (used TiVo button, Right Arrow, etc). I haven't seen the app to know if what I'm asking is possible.

Who said anything about giving up? The revelation that port 1393 is being used on TiVo is a good start and made the exercise well worth while. Just don't know if anything else useful can be gleamed from the captured raw data.

Use the iPad to navigate around the Premiere, as if it were only a remote control, and make note of the action (used TiVo button, Right Arrow, etc). I haven't seen the app to know if what I'm asking is possible.

Hopefully with some methodical testing, something may come of it. And with methodical, I mean hit the TiVo button, wait about 10 seconds, hit Live TV, wait 10 seconds, hit Pause, wait 10 seconds, etc... Something that will clearly show that the action performed was actually captured. Getting to the more esoteric functions like "scrubbing" the progress bar can be done later IF the iPad protocol can be figured out.

Just don't know if anything else useful can be gleamed from the captured raw data.

Let's see... start with the visible ASCII strings in the initial response from the TiVo (which include the TSN, BTW). I can see that each string is preceded by a length byte, and the length byte is preceded by a byte that may indicate the data type -- it's always 0x13 for the ASCII strings, except for the pure numeric sequences that end in "Z"; they're 0x17. In between these may be sections beginning with 0x30 (followed by a single byte) or 0x31 (followed by eight bytes). Not sure I've parsed that right yet, but it's early. The first group of strings etc. is almost repeated after the numeric strings. (Besides the TSN, the other strings in this group are "TiVo Inc.", "IT", "Alviso", "California", and "US". Admittedly that doesn't seem useful, but it did help confirm the string format.)

Another thing I might look for would be data in HME-like formats (e.g., variable-length integers and packed dicts), which are also used in push requests, so TiVo seems to like them. But the string format doesn't fit that theme.

Anyway, there are patterns here; you just have to keep at it.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

And with methodical, I mean hit the TiVo button, wait about 10 seconds, hit Live TV, wait 10 seconds, hit Pause, wait 10 seconds, etc... Getting to the more esoteric functions like "scrubbing" the progress bar can be done later

My understanding is that the iPad app uses the known network remote interface for the basic stuff, so the "esoteric" functions are the only ones to worry about. I can't confirm that, though.

__________________

To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Here are 2 captures of a play and a pause message. When the remote is active on the iPad, the Tivo continuously sends 298 byte messages at 1 second intervals to the iPad, no doubt to update the progress bar. The iPad only sends data when a button is pressed.

It's pretty easy to filter when viewing with Wireshark. Simply right click on one of the TCP lines and choose "Follow TCP Stream". That will filter out the other network traffic. Other useful thing to note is in the middle pane click on the Data row to show actual data being communicated without the TCP related overhead.

It's pretty easy to filter when viewing with Wireshark. Simply right click on one of the TCP lines and choose "Follow TCP Stream". That will filter out the other network traffic. Other useful thing to note is in the middle pane click on the Data row to show actual data being communicated without the TCP related overhead.

Right, I know how to do that, but when I save it to a file, it includes everything that was captured. The Save As... dialog has an option to save a range of packets, but it didn't seem to work.

The hex dump that I posted earlier is from "Follow TCP Stream" and includes just the data without the overhead.

Only frame 34 of the "Play" capture contains data from the iPad to the Premiere. Frame 7 of the "Pause" capture is also the only frame with data. Nothing on port 31339.

Edit: the first 5 bytes are common between both Pause and Play: 17 03 01 00 a0

All the messages from the Tivo in those captures also start with 17030100. As I posted earlier, every message I have seen starts with 14030100, 15030100, 16030100, or 17030100. The ones starting with 16 occur when the devices initially connect, and the one starting with 15 is sent when they disconnect.

I am also seeing that signature at the beginning of messages sent from the Tivo to a server at Tivo with the IP address 208.73.181.192. The iPad app won't work unless the Tivo can be talking to a server at the mother ship.

Shucks, I was hoping it would be something obvious like XML messages. This is gonna be more work to crack. I wonder if broadcom has some "standard" communications library they sold tivo (like they sold them the flash nonsense).

Hopefully with some methodical testing, something may come of it. And with methodical, I mean hit the TiVo button, wait about 10 seconds, hit Live TV, wait 10 seconds, hit Pause, wait 10 seconds, etc... Something that will clearly show that the action performed was actually captured. Getting to the more esoteric functions like "scrubbing" the progress bar can be done later IF the iPad protocol can be figured out.

Or setup a video camera to record the iPad with timestamps turned on and compare the time of the IP packets :-).

I think you're right. I assumed it wasn't encrypted because Wireshark didn't flag it as something special and I saw the clear text in the second message, but those signatures make sense. I don't know much about SSL, but the text is probably Tivo's SSL certificate.

The traffic is in fact, encrypted with SSL. The fact that every packet above starts with the same data proves that; it is the SSL header. The TiVo uses the MRPC (MindRPC) protocol. I, being an Objective-C hacker, actually went as far as to disable SSL inside the app's binary, and although this disables the app from working, I captured the first request it sends to the TiVo, unencrypted:

Going further, I found the sweet spot in the code, I can now get all requests before they are sent out in the app (i.e. unencrypted). It seems MRPC is a very configurable protocol, you specify a request type (recordingSearch, subscriptionSearch, contentSearch, offerSearch, and collectionSearch are the common ones I see), and then specify what you want to search for, and also how you want to receive the results. All in JSON. An example request to get all your season passes:

Overall:
You send an authentication request to your TiVo on port 1413 with your MAK, encrypted with SSL. Then you send any request you want to obtain the data you want. I will probably provide a more in depth dissemination of the protocol and some sample code in perl soon. (I wrote this in a rush, sorry :P)

- SSL was created for, and is used, for the express purpose of preventing people from spying on data in between two ends of a connection. When you found the SSL certificate, you could have used it with Wireshark (if it was built with GnuTLS) to decrypt the packets, but i think the developers changed the certificate, removed the file, and integrated it into the binary, because I couldn't find a tivo.cer file anywhere. Without that certificate, packet captures are useless other than to tell which port is being used.

- It is very rare to see a TCP protocol not based on plaintext.

- The best method, in my opinion, to capture packets between the two devices, is by installing and using tcpdump on a jailbroken iPad :P

Code:

tcpdump -w ./tivo_dump.pcap -vvv -s 0 'src or dst 192.168.2.202'

- Are you guys seeing port 1393 being used? My 3 day old, recently updated TiVo Premiere was using port 1413. It may vary per TiVo?

- Random note: Looking through IDA shows that there are some classes specifically for iPhone in the code, so we should be seeing an iPhone version soon

So I get a successful authentication back just using the same sort of SSL connection you'd use to connect to an SSL protected mail server, etc. So it looks like things are ready to take off maybe (I can hope :-).