Yansky

Untitled

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