rtmp:// retrieval with rtmpdump and tcpdump

Some sites now use the rtmp protocol to stream videos, using primarily Flash in a web browser as a client.

rtmpdump is a utility created to save those videos on disk for later use. Since its usage is a bit obscure and the download could fail for various reasons (a missing option, a badly spelled parameter, etc.) and every site needs its own tweaks, I’m going to explain a bit how to deal with the simple cases.

Some of the parameters needed to run rtmpdump correctly could be viewed by looking at the html code of the web page: look for the strings “mp4”, “config”, “player”, “rtmp” (maybe in uppercase too); those are usually written as javascript parameters, or found in a .xml “config” file. To find this “config” file, a plugin like “live HTTP header” for Firefox may be useful.

tcpdump could be needed, unless you want to dig into disassembling a Flash application (but maybe a simple strings can be enough), since some variables are not shown in the html code of the web page.

The simplest usage for tcpdump, for our purposes is (as root, assuming eth0 is your network device):

tcpdump -w file.tcpdump -s 0 -i eth0

Then you can load the page with the video you are interested in. After some seconds, you can stop tcpdump with ctrl-C. Now you can look at what your network interface was doing by doing something like:

/usr/sbin/tcpdump -A -n -s 0 -r file.tcpdump | less

As before, you should search for “mp4”, “config”, “player”, “rtmp” and similar. If you find a string like

rtmpe://example.net/application/somepath/filename.mp4

you can go on and try immediately if this works:

rtmpdump -r rtmpe://example.net/application/somepath/filename.mp4 -o filename.mp4

If this doesn’t work, run the same command with the “-V” (verbose) option. If you see something like “Application (application) is not defined”, it means that rtmpdump didn’t parse correctly the url you gave. That’s because (as written in the rtmpdump manpage)

The url should be of the form

rtmp[t][e]://hostname[:port][/app[/playpath]]

…but since the code can correctly parse the url only if it’s quite simple, sometimes it can make a wrong guess, and that’s where the user should be explicit about every part of the path, and use the corresponding options (like --app or --playpath).

Still, this could be not enough: some streams require some kind of “autentication” (well, kind of), so more fiddling with options is needed. Some of the more useful options are:

−−pageUrl (URL of the web page in which the media was embedded)
−−swfVfy (URL of the SWF player)
−−token (Key for SecureToken response, used if the server requires SecureToken authentication)

The first, −−pageUrl, is obvious. For the second, all is needed is a look at the html source. The third is sometimes written in the .html page too, or sometimes in an .xml configuration file called either by the web page or the flash code: that’s where tcpdump or “live HTTP headers” become useful.

Another method, maybe simpler, but sometimes not perfect, involves the use of iptables and rtmpsrv, as explained in this blog post:

• Redirect the outgoing traffic on the rtmp port to localhost:
  iptables -t nat -A OUTPUT -p tcp --dport 1935 -j REDIRECT
• Start rtmpsrv on localhost
• Load the page containing media streamed over RTMP
• Now rtmpsrv should print a line on screen. You can stop it with CTRL-C, and close your browser
• Remove the traffic redirection:
  iptables -t nat -D OUTPUT -p tcp --dport 1935 -j REDIRECT

Note: if you don’t want to install anything, but just try it out just after compiling it, you’d better compile with:

make SHARED=

…then you can run everything locally:

./rtmpsrv

UPDATE:
I found out that there’s a bug somewhere, so rtmpsrv doesn’t always work: sometimes the page containing the stream won’t reload. To hack around this problem:

• Redirect the outgoing traffic on the rtmp port to localhost:
  iptables -t nat -A OUTPUT -p tcp --dport 1935 -j REDIRECT
• Start rtmpsrv on localhost
• Load the page containing media streamed over RTMP
• Now the page seems stuck loading the stream, and rtmpsrv doesn’t show anything yet: if so, reload the web page
• Now rtmpsrv should print a line on screen. You can stop it with CTRL-C, and copy this line somewhere: you have to edit it
• Start rtmpsuck on localhost
• Load the page containing media streamed over RTMP
• Now rtmpsuck should print some informations on screen. You can stop it with CTRL-C, and copy this info somewhere: you have to use it to make the line given by rtmpsrv work
• Remove the traffic redirection:
  iptables -t nat -D OUTPUT -p tcp --dport 1935 -j REDIRECT

Now you have to compare the output of rtmpsuck, like:

app: some_app
swfUrl: http://www.example.com/player.swf
tcUrl: rtmp://www.example.com/example_tc

… with the one of rtmpsrv and change the command line parameters one by one. Maybe this won’t get you much far, the download may stop before it reaches 100%, but can be useful anyway. Good luck.

Advertisements