Comments on: Implications of rtmpdump takedown http://ossguy.com/?p=398 Ideas on how we can make the world a better place, with a technical bent Mon, 06 Sep 2010 18:33:20 -0700 http://wordpress.org/?v=2.9-rare hourly 1 By: BRuc http://ossguy.com/?p=398&cpage=1#comment-50276 BRuc Sun, 05 Sep 2010 23:39:35 +0000 http://ossguy.com/?p=398#comment-50276 Just a rant, I like RTMPDump - quite a lot actually. I believe it is the only way to download music from MySpace. I've seen other RTMP downloaders, some completely broken, and some that only download a specific flavor- but not MySpace, you need the rtmp:// link and rtmpdump to do that. I created a *.bat file to aid with the process of supplying an rtmp stream to download from, a front-end, but it's still cmd-based and not that good, a much better front-end is required. also, it should also be combined with in network traffic-logging interface with no requirement for a rtmp stream resource, and which will log the connection, download the stream and display info and whatnot.. that'd be a dream. it's sad we live in such a horrible world where information is withheld, and the general public swallows it without question, they don't 'need' all the technical do-what, or all the premium features on their HDTV set, they just want cable. Just a rant, I like RTMPDump - quite a lot actually. I believe it is the only way to download music from MySpace. I've seen other RTMP downloaders, some completely broken, and some that only download a specific flavor- but not MySpace, you need the rtmp:// link and rtmpdump to do that. I created a *.bat file to aid with the process of supplying an rtmp stream to download from, a front-end, but it's still cmd-based and not that good, a much better front-end is required. also, it should also be combined with in network traffic-logging interface with no requirement for a rtmp stream resource, and which will log the connection, download the stream and display info and whatnot.. that'd be a dream. it's sad we live in such a horrible world where information is withheld, and the general public swallows it without question, they don't 'need' all the technical do-what, or all the premium features on their HDTV set, they just want cable.

]]> By: hyc http://ossguy.com/?p=398&cpage=1#comment-21447 hyc Sat, 26 Dec 2009 01:46:38 +0000 http://ossguy.com/?p=398#comment-21447 And to answer the earlier question, yes, rtmpdump is now being hosted by the mplayer team. http://rtmpdump.mplayerhq.hu The rtmpdump code has been completely rewritten in C, resulting in 1/2 the memory and CPU use of the original C++ code, fixing all the portability issues of the original code, and also cutting the load time down by more than half. It now runs well even on limited-resource systems like Android G1 phones. The code has been restructured to make it easily usable as a standalone library, and support for server-side functionality is also available now in the SVN trunk. And to answer the earlier question, yes, rtmpdump is now being hosted by the mplayer team. http://rtmpdump.mplayerhq.hu

The rtmpdump code has been completely rewritten in C, resulting in 1/2 the memory and CPU use of the original C++ code, fixing all the portability issues of the original code, and also cutting the load time down by more than half. It now runs well even on limited-resource systems like Android G1 phones. The code has been restructured to make it easily usable as a standalone library, and support for server-side functionality is also available now in the SVN trunk.

]]> By: hyc http://ossguy.com/?p=398&cpage=1#comment-6232 hyc Tue, 02 Jun 2009 05:24:57 +0000 http://ossguy.com/?p=398#comment-6232 Eh. We've known Adobe is evil for a long time, and Flash sucks. But the mindless drones will still keep on using it, even despite this blatant dishonesty. Not enough people are left who are awake enough to care. Eh. We've known Adobe is evil for a long time, and Flash sucks. But the mindless drones will still keep on using it, even despite this blatant dishonesty. Not enough people are left who are awake enough to care.

]]> By: luke kenneth casson leighton http://ossguy.com/?p=398&cpage=1#comment-5899 luke kenneth casson leighton Mon, 25 May 2009 13:12:33 +0000 http://ossguy.com/?p=398#comment-5899 > a) provide end-to-end secrecy, just like SSL ... except without the man-in-the-middle protection. > a) provide end-to-end secrecy, just like SSL

... except without the man-in-the-middle protection.

]]> By: luke kenneth casson leighton http://ossguy.com/?p=398&cpage=1#comment-5898 luke kenneth casson leighton Mon, 25 May 2009 11:59:08 +0000 http://ossguy.com/?p=398#comment-5898 There are several problems with adobe's approach: 1) there is no "encryption key". there is, however, a magic constant (actually, three). the first is "Genuine Adobe Flash Player 001"; the second is "Genuine Adobe Flash Media Server 001" and the third is some unpronounceable random crud which you can get by looking at http://lkcl.net/rtmp/RTMPE.txt 2) there is no "protection". RTMPE is an algorithm that uses industry-standard crypto primitives, magic constants and publicly-available information (the SWF file) to do two things: a) provide end-to-end secrecy, just like SSL b) link knowledge of the size and a hash of the SWF file to the connection. adobe claim [translation: lie to their customers, thus exposing themselves to lawsuits] that this "validation" process _guarantees_ that only someone with the SWF file (that was publicly accessible and publicly downloadable from a web site) can download the content. what they imply from that is that only someone who _executes_ the SWF file can download the content, which is blatantly false. from the algorithm: if anyone knows the SWF file's hash and its size, they can use the algorithm to access the content. executing the SWF file or even having it _at all_ is irrelevant. 3) if you want to get arsey about it, and say that the words "Genuine Adobe Flash Player 001" are an "encryption key", then you have a problem, because there is further input into the "validation" algorithm: the SWF file itself. that makes the SWF file also an "encryption key". ... whoops. you can immediately work out the implications, here, for yourself, but here's some of the more hilarious ones: * how can you claim that a key is secret, yet make it publicly available on the internet? * if you want to keep this "key" secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they "protect" - remove - SWF files from caches. this latter is quite easily achieved. you just block *.swf files. There are several problems with adobe's approach:

1) there is no "encryption key". there is, however, a magic constant (actually, three). the first is "Genuine Adobe Flash Player 001"; the second is "Genuine Adobe Flash Media Server 001" and the third is some unpronounceable random crud which you can get by looking at http://lkcl.net/rtmp/RTMPE.txt

2) there is no "protection". RTMPE is an algorithm that uses industry-standard crypto primitives, magic constants and publicly-available information (the SWF file) to do two things:

a) provide end-to-end secrecy, just like SSL

b) link knowledge of the size and a hash of the SWF file to the connection.

adobe claim [translation: lie to their customers, thus exposing themselves to lawsuits] that this "validation" process _guarantees_ that only someone with the SWF file (that was publicly accessible and publicly downloadable from a web site) can download the content. what they imply from that is that only someone who _executes_ the SWF file can download the content, which is blatantly false.

from the algorithm: if anyone knows the SWF file's hash and its size, they can use the algorithm to access the content. executing the SWF file or even having it _at all_ is irrelevant.

3) if you want to get arsey about it, and say that the words "Genuine Adobe Flash Player 001" are an "encryption key", then you have a problem, because there is further input into the "validation" algorithm: the SWF file itself.

that makes the SWF file also an "encryption key".

... whoops.

you can immediately work out the implications, here, for yourself, but here's some of the more hilarious ones:

* how can you claim that a key is secret, yet make it publicly available on the internet?

* if you want to keep this "key" secret, surely you should go after all web browser distributors, and everyone who has HTTP cacheing technology, DEMANDING that they "protect" - remove - SWF files from caches.

this latter is quite easily achieved. you just block *.swf files.

]]> By: singpolyma http://ossguy.com/?p=398&cpage=1#comment-5871 singpolyma Sun, 24 May 2009 18:53:50 +0000 http://ossguy.com/?p=398#comment-5871 Are the rtmpdump guys finding alternate hosting (outside the US)? Are the rtmpdump guys finding alternate hosting (outside the US)?

]]>