codeblog code is freedom — patching my itch

2/25/2005

.tivo file format

Filed under: Multimedia,Reverse Engineering — kees @ 1:35 am

After I found some details on the .tivo file format, and cooked up some code to produce the same output. So far, there isn’t a lot of detail. It’s mostly just strange stuff. mpegcat finds the MPEG2 stream right where it should be, but supposedly the non-I-frames appear to be encoded.

All the files I’ve downloaded from my TiVo have the same “fingerprint” listed in the XML header, and a different “salt”. The interface for downloading recordings is very simple. Connect to https://[tivo IP]/ and it’ll prompt you for your username and password, which is “tivo” and your “Media Access Key”. After that, you’re all set; browse away. Download speed is rather slow: 500kB/s. Better than 2400 baud. :)

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

2/16/2005

Hitchhiker’s Guide to Reverse Engineering

Filed under: Networking,Reverse Engineering — kees @ 7:53 pm

Well, I got annoyed that I couldn’t watch the SWF-based HitchHiker’s trailer on the Amazon.com main page. swf_play failed miserably. Most of the crap Apple pulls for their movie trailer stream-hiding is simple enough to work around. Generally I just keep downloading the MOVs, running strings on them until I find the actual MOV with the movie trailer in it, but Amazon’s wasn’t so easy. I found the base URL to the video easily enough in the XML parameters file. The hard part was figuring out what the hell “rtmp” is. mplayer didn’t recognize it, and after a quick nmap of the media server, I just got more confused. nmap listed a port 1935 called “rmtp”. Digging around a little it became very obvious that nmap’s services entry was just a typo. So I sent in a quick patch, and Fyodor accepted it within minutes. Pretty cool.

Anyway, on to the protocol dissection. I set up tcpdump to record everything sent to fcs.amazon.speedera.net, and took a look at it in Ethereal. Seeing that it was mostly binary, I looked around for something that would dump the data portion of a packet stream, but ended up empty handed. I’ve repeatedly wanted this, so I finally broke down and read up on coding with libpcap. It’s easy enough to use, but I floundered with the packet headers for a while. Eventually I managed to find the data portion of the packets, and was able to dump the client stream and the server stream separately. I wish there was a button on Ethereal’s “Follow TCP Stream” window that would just let me save the data. My tool doesn’t at all track sequence numbers or retransmissions, etc, so I worry that in some situations I won’t get a “true” stream dump. I suspect Ethereal handles that correctly, but I couldn’t tell you for sure.

After looking at this protocol dump, it seems like it ends up turning into some kind of SOAP-like communication, with function call literals like getStreamLength, createStream, play, and closeStream. There’s even a _result variable mentioned. The Flash coding docs I’ve found that talk about stream display don’t seem to mention this stuff at all, but maybe I didn’t dig far enough.

Since RTMP appears to be capable of streams, etc, I think the next step is to figure out how it reacts to things like “Pause” and “Stop” during playback. Clearly there is a stream-identification system in the headers, and there must be stream length indicators. I’m so annoyed that there is absolutely no discussion of RTMP anyway. I should go look at the swf_play source before I go much further.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

2/9/2005

Inkscape released

Filed under: Inkscape — kees @ 1:01 pm

Ah, it’s so satisfying to get a release out the door. Inkscape version 0.41 has finally been released. This time around, I was made a “Freeze Warden”, which means I have some input in the release process. (Are all the critical bugs fixed? Are the translations updated? Are the builds correct?)

Another task I kind of gave myself was packaging the Win32 binaries. That’s pretty cool, and I’m quite impressed with the NSIS package that does the bundling. I didn’t write the bundling scripts Inkscape uses, but I got to play with the NSIS compiler itself. It’s very slick, and I recommend it for anyone doing Windows installs. (And I should note that hundreds of other software packages are already using NSIS.)

One thing that Bryce Harrington has helped keep in my head during the Inkscape hard freeze was that any given release isn’t supposed to be Bug Free(tm). It’s just supposed to be a release. This is very hard for me to keep in my head, so hearing a few times during Freeze is a good thing. Bugs in the release that we know about are just “Known Problems”. They’re in the tracker, and we’ll get to them some day, but not today. It greatly relaxes me to think about it that way. The pressure to produce is relaxed, letting me actually enjoy the release process instead of worrying needlessly about all the people that will hate us because it crashes when they click like this.

© 2005, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Creative Commons License

Powered by WordPress