Originally Posted by rtmpdump

You can also use "make rtmpsrv" to build a stub server. Note that this is very incomplete code, and I haven't yet decided whether or not to finish it. In its current form it is useful for obtaining all the parameters that a real Flash client would send to an RTMP server, so that they can be used with rtmpdump.

You can also use "make rtmpsuck" to build a proxy server. See below...

All you need to do is redirect your Flash clients to the machine running this server and it will dump out all the connect / play parameters that the Flash client sent. The simplest way to cause the redirect is by editing /etc/hosts when you know the hostname of the RTMP server, and point it to localhost while running rtmpsrv on your machine. (This approach should work on any OS; on Windows you would edit %SystemRoot%\system32\drivers\etc\hosts.)

On Linux you can also use iptables to redirect all outbound RTMP traffic.
You can do this as root:
In my original plan I would have the transparent proxy running as a special user (e.g. user "proxy"), and regular Flash clients running as any other user. In that case the proxy would make the connection to the real RTMP server. The
iptables rule would look like this:
A rule like the above will be needed to use rtmpsuck.

Using it in this mode takes advantage of the Linux support for IP redirects; in particular it uses a special getsockopt() call to retrieve the original
destination address of the connection. That way the proxy can create the real outbound connection without any other help from the user. I'm not aware of equivalent functionality on BSD, Windows, or any other platform; if you know how to handle this I'd be interested in hearing about it.

The rtmpsuck command has only one option: "-z" to turn on debug logging. It listens on port 1935 for RTMP sessions, but you can also redirect other ports to it as needed (read the iptables docs). It first performs an RTMP handshake with the client, then waits for the client to send a connect request. It parses and prints the connect parameters, then makes an outbound connection to the real RTMP server. It performs an RTMP handshake with that server, forwards the connect request, and from that point on it just relays packets back and forth between the two endpoints.

It also checks for a few packets that it treats specially: a play packet from the client will get parsed so that the playpath can be displayed. It
also handles SWF Verification requests from the server, without forwarding them to the client. (There would be no point, since the response is tied to each session's handshake.)

Once the play command is processed, all subsequent audio/video data received from the server will be written to a file, as well as being delivered back to the client.

The point of all this, instead of just using a sniffer, is that since rtmpsuck has performed real handshakes with both the client and the server, it can negotiate whatever encryption keys are needed and so record the unencrypted
data.