Ignore requests without playpath
[rtmpdump.git] / README
1 RTMP Dump v2.4
2 (C) 2009 Andrej Stepanchuk
3 (C) 2009-2011 Howard Chu
4 (C) 2010 2a665470ced7adb7156fcef47f8199a6371c117b8a79e399a2771e0b36384090
5 (C) 2011 33ae1ce77301f4b4494faaa5f609f3c48b9dcf82
6 License: GPLv2
7 librtmp license: LGPLv2.1
8 http://rtmpdump.mplayerhq.hu/
9
10 To compile type "make" with SYS=<platform name>, e.g.
11
12   $ make SYS=posix
13
14 for Linux, Unix, etc. or
15
16   $ make SYS=darwin
17
18 for MacOSX or
19
20   $ make SYS=mingw
21
22 for Windows.
23
24 You can cross-compile for other platforms using the CROSS_COMPILE variable:
25
26   $ make CROSS_COMPILE=arm-none-linux- INC=-I/my/cross/includes
27
28 Please read the Makefile to see what other make variables are used.
29
30 This code also requires you to have OpenSSL and zlib installed. You may
31 optionally use GnuTLS or polarssl instead of OpenSSL if desired. You may
32 also build with just rtmpe support, and no rtmps/https support, by
33 specifying -DNO_SSL in the XDEF macro, e.g.
34
35   $ make XDEF=-DNO_SSL
36
37 or
38
39   $ make CRYPTO=POLARSSL XDEF=-DNO_SSL
40
41 You may also turn off all crypto support if desired
42
43   $ make CRYPTO=
44
45 A shared library is now built by default, in addition to the static
46 library. You can also turn it off if desired
47
48   $ make SHARED=
49
50 The rtmpdump programs still link to the static library, regardless.
51
52 Note that if using OpenSSL, you must have version 0.9.8 or newer.
53 For Polar SSL you must have version 1.0.0 or newer.
54
55 Credit goes to team boxee for the XBMC RTMP code originally used in RTMPDumper.
56 The current code is based on the XBMC code but rewritten in C by Howard Chu.
57
58
59 SWF Verification
60 ----------------
61
62 Note: these instructions for manually generating the SWFVerification
63 info are provided only for historical documentation. The software can now
64 generate this info automatically, so it is no longer necessary to
65 run the commands described here. Just use the -W (--swfVfy) option
66 to perform automatic SWFVerification.
67
68 Download the swf player you want to use for SWFVerification, unzip it using
69
70  $ flasm -x file.swf
71
72 It will show the decompressed filesize, use it for --swfsize
73
74 Now generate the hash
75
76  $ openssl sha -sha256 -hmac "Genuine Adobe Flash Player 001" file.swf
77
78 and use the --swfhash "01234..." option to pass it.
79
80 e.g. $ ./rtmpdump --swfhash "123456..." --swfsize 987...
81
82
83 Connect Parameters
84 ------------------
85
86 Some servers expect additional custom parameters to be attached to the
87 RTMP connect request. The "--auth" option handles a specific case, where
88 a boolean TRUE followed by the given string are added to the request.
89 Other servers may require completely different parameters, so the new
90 "--conn" option has been added. This option can be set multiple times
91 on the command line, adding one parameter each time.
92
93 The argument to the option must take the form <type> : <value> where
94 type can be B for boolean, S for string, N for number, and O for object.
95 For booleans the value must be 0 or 1. Also, for objects the value must
96 be 1 to start a new object, or 0 to end the current object.
97
98 Examples:
99   --conn B:0 --conn S:hello --conn N:3.14159
100
101 Named parameters can be specified by prefixing 'N' to the type. Then the
102 name should come next, and finally the value:
103   --conn NB:myflag:1 --conn NS:category:something --conn NN:pi:3.14159
104
105 Objects may be added sequentially:
106   -C O:1 -C NB:flag:1 -C NS:status:success -C O:0 -C O:1 -C NN:time:12.30 -C O:0
107 or nested:
108   -C O:1 -C NS:code:hello -C NO:extra:1 -C NS:data:stuff -C O:0 -C O:0
109
110
111 Building OpenSSL 0.9.8k
112 -----------------------
113 arm:
114 ./Configure -DL_ENDIAN --prefix=`pwd`/armlibs linux-generic32
115
116 Then replace gcc, cc, ar, ranlib in Makefile and crypto/Makefile by arm-linux-* variants  and use make && make install_sw
117
118 win32:
119 Try ./Configure mingw --prefix=`pwd`/win32libs -DL_ENDIAN -DOPENSSL_NO_HW
120 Replace gcc, cc, ... by mingw32-* variants in Makefile and crypto/Makefile
121 make && make install_sw
122
123 OpenSSL cross-compiling can be a difficult beast.
124
125 Precompiled OpenSSL binaries for Windows are available on
126 http://www.slproweb.com/products/Win32OpenSSL.html
127
128 If you're just running a pre-built Windows rtmpdump binary, then all you
129 need is the "Light" installer. If you want to compile rtmpdump yourself,
130 you'll need the full installer.
131
132
133 Example Servers
134 ---------------
135 Three different types of servers are also present in this distribution:
136  rtmpsrv - a stub server
137  rtmpsuck - a transparent proxy
138  rtmpgw - an RTMP to HTTP gateway
139
140 rtmpsrv - Note that this is very incomplete code, and I haven't yet decided
141 whether or not to finish it. It is useful for obtaining all the parameters
142 that a real Flash client would send to an RTMP server, so that they can be
143 used with rtmpdump. The current version now invokes rtmpdump automatically
144 after parsing a client request.
145
146 rtmpsuck - proxy server. See below...
147
148 All you need to do is redirect your Flash clients to the machine running this
149 server and it will dump out all the connect / play parameters that the Flash
150 client sent. The simplest way to cause the redirect is by editing /etc/hosts
151 when you know the hostname of the RTMP server, and point it to localhost while
152 running rtmpsrv on your machine. (This approach should work on any OS; on
153 Windows you would edit %SystemRoot%\system32\drivers\etc\hosts.)
154
155 On Linux you can also use iptables to redirect all outbound RTMP traffic. You
156 need to be running as root in order to use the iptables command.
157
158 In my original plan I would have the transparent proxy running as a special
159 user (e.g. user "proxy"), and regular Flash clients running as any other user.
160 In that case the proxy would make the connection to the real RTMP server. The
161 iptables rule would look like this:
162
163 iptables -t nat -A OUTPUT -p tcp --dport 1935 -m owner \! --uid-owner proxy \
164  -j REDIRECT
165
166 A rule like the above will be needed to use rtmpsuck. Note that you should
167 replace "proxy" in the above command with an account that actually exists
168 on your machine.
169
170 Using it in this mode takes advantage of the Linux support for IP redirects;
171 in particular it uses a special getsockopt() call to retrieve the original
172 destination address of the connection. That way the proxy can create the
173 real outbound connection without any other help from the user. The equivalent
174 functionality may exist on other OSs but needs more investigation.
175
176 (Based on reading the BSD ipfw manpage, this rule ought to work on BSD:
177
178 ipfw add 40 fwd 127.0.0.1,1935 tcp from any to any 1935 not uid proxy
179
180 Some confirmation from any BSD users would be nice.)
181
182 (We have a solution for Windows based on a TDI driver; this is known to
183 work on Win2K and WinXP but is assumed to not work on Vista or Win7 as the
184 TDI is no longer used on those OS versions. Also, none of the known
185 solutions are available as freeware.)
186
187 The rtmpsuck command has only one option: "-z" to turn on debug logging.
188 It listens on port 1935 for RTMP sessions, but you can also redirect other
189 ports to it as needed (read the iptables docs). It first performs an RTMP
190 handshake with the client, then waits for the client to send a connect
191 request. It parses and prints the connect parameters, then makes an
192 outbound connection to the real RTMP server. It performs an RTMP handshake
193 with that server, forwards the connect request, and from that point on it
194 just relays packets back and forth between the two endpoints.
195
196 It also checks for a few packets that it treats specially: a play packet
197 from the client will get parsed so that the playpath can be displayed. It
198 also handles SWF Verification requests from the server, without forwarding
199 them to the client. (There would be no point, since the response is tied to
200 each session's handshake.)
201
202 Once the play command is processed, all subsequent audio/video data received
203 from the server will be written to a file, as well as being delivered back
204 to the client.
205
206 The point of all this, instead of just using a sniffer, is that since rtmpsuck
207 has performed real handshakes with both the client and the server, it can
208 negotiate whatever encryption keys are needed and so record the unencrypted
209 data.
210
211 rtmpgw - HTTP gateway: this is an HTTP server that accepts requests that
212 consist of rtmpdump parameters. It then connects to the specified RTMP
213 server and returns the retrieved data in the HTTP response. The only valid
214 HTTP request is "GET /" but additional options can be provided in normal
215 URL-encoded fashion. E.g.
216   GET /?r=rtmp:%2f%2fserver%2fmyapp&y=somefile HTTP/1.0
217
218 is equivalent the rtmpdump parameters "-r rtmp://server/myapp -y somefile".
219
220 Note that only the shortform (single letter) rtmpdump options are supported.