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 4.0 License.
I know that quite a few people would be interested in getting the specs to RTMP. The server is prohibitively expensive; I know that some people have offered themselves in writing a server for it if the protocol would be specified.
The messages themselves probably are encoded in AMF, which does have a SOAP-like structure. Here is a trace of of a typical AMF message:
00FB 00 00 00 01 00 10 61 6D 66 5F 73 65 72 76 65 72 ……amf_server
010B 5F 64 65 62 75 67 01 00 00 00 60 03 00 0A 63 6F _debug….`…co
011B 6C 64 66 75 73 69 6F 6E 01 01 00 0A 61 6D 66 68 ldfusion….amfh
012B 65 61 64 65 72 73 01 00 00 03 61 6D 66 01 00 00 eaders….amf…
013B 0B 68 74 74 70 68 65 61 64 65 72 73 01 00 00 09 .httpheaders….
014B 72 65 63 6F 72 64 73 65 74 01 01 00 05 65 72 72 recordset….err
015B 6F 72 01 01 00 05 74 72 61 63 65 01 01 00 07 6D or….trace….m
016B 5F 64 65 62 75 67 01 01 00 00 09 00 01 00 15 4D _debug………M
017B 75 6C 74 69 70 6C 65 43 61 6C 6C 73 2E 6D 65 74 ultipleCalls.met
018B 68 6F 64 31 00 02 2F 31 00 00 00 0E 0A 00 00 00 hod1../1……..
019B 01 00 00 00 00 00 00 00 00 00 ……….
It’s 2 bytes version, 2 bytes number of headers, then headers, then bodies. If that looks somewhat like your trace then this would make it relatively easy. AMFPHP runs on AMF. You can downlaod the latest beta of AMFPHP here:
http://www.5etdemi.com/uploads/amfphpbeta.zip
Look at everything under the io folder, that should make things clear.
Comment by Patrick Mineault — March 26, 2005 @ 5:49 pm
More rtmp fun. This one actually produces an MP3 stream (though is seems lightly garbled).
http://www.myspace.com/ninofficial
Comment by kees — April 27, 2005 @ 10:33 am
Hi Guys,
We are working on a open source implmentation of RTMP over at osflash.
Come check it out for more info http://www.osflash.org/red5
— luke
Comment by luke — September 19, 2005 @ 2:03 pm
You can dump the data portion of a TCP stream easily with tcpick, http://tcpick.sourceforge.net/
Works either using libpcap dumps or from live network.
Comment by Timo Lindfors — April 9, 2006 @ 4:54 pm
I’ve recently been playing around with RTMP streamed mp3s, and saving them into a file using a little libpcap program I wrote. However, I am having the same issue where they are slightly garbled, and it’s really irritating me. My only guess is that the Flash Plugin is making some modification to the mp3 data before playing it… and trying to reverse engineer the plugin (tried OS X) has so far been a headache. Unfortunately, my gdb skills are quite a bit better than my IDA-Pro skills. Has anyone figured out how to fix the “garbling” effect?
I got my hands on the mpg123 source code and have been playing around quite a bit… comparing my recorded copy of a streamed mp3 with another mp3 not streamed but in the same format (no ID3 tag, encoded with same bitrate, frame size, etc). I’ve found that about every 4 frames there is an extra 6-15 bytes at the end of the frame that is not part of the mp3 data, but looking thoroughly at the mpg123 source shows that these bytes aren’t even being included in the frame data, so they shouldn’t account for the garbling (plus 6-15 bytes every 4 frames is really probably too small to have a noticeable effect). I’m puzzled. I emailed the Red5-dev mailing list seeking advice but they refused to answer :-\.
If anyone has had more luck with this, I’d be interested to hear. It’s become a bit of an obsession. :)
Comment by Braden — May 4, 2006 @ 5:05 pm
you can find Braden’s libpcap program at
http://home.twmi.rr.com/compn/rtmp.cpp
if anyone wants to look at it and find the problem :)
Comment by Compn — July 4, 2006 @ 10:26 am
I tried to sum up all efforts around rtmp in this post.
Comment by Zen — October 23, 2008 @ 9:02 am