[MPlayer-dev-eng] Some info on RTSP

[Bertrand Baudet]

On Sunday 09 June 2002 07:32 pm, Felix Buenemann wrote:
> Hi,
>
> I took some time to setup realserver 8 basic and real player 8 basic on my
> laptop (of course neither of the setup routines worked, but I fixed it
> manually). I did this in order to acquire some info about the Real RTSP
> challenge, so attached is the EtherReal packet-print I created, which shows
> the whole communication (only RTSP, UDP Data skipped, SDP Data not
> displayed) between server and client from open location and play clip until
> manually stopping the clip.
> Note that I setup RTSP on the server to 5554 instead of 554 because I run
> it as user, so shown service name is misleading.
>
> I could type a description of the challenge, but it's already described
> here: http://realforum.real.com/realforum/msg07554.html (silly idea to ask
> for info on this at real.com - surely wasn't me ;)
>
> Now here are my conclusions on how to try to get the challenge reverse
> engineered:
>
> - Compare with different Real clients, probably won't help much as starting
> challenge should be random number, but who knows
>
> - Write a emulation client (eg. perl script) that can feed the server with
> bogus data, might give a clue what encryptions are used (eg. feed with all
> zeroes)
>
> - Write a emulation server (eg. perl script) to see how real clients react
> to different reply data, for same purpose
>
> - If still stuck it needs a memory-debugger like SoftICE to trace the
> actual code, this could help to find what's going on, but it's only for
> advanced hackers. (Or dissamble code and try to analyze "offline".)
>
> Do you have more ideas/corrections what could help to get this problem
> resolved?


What I have already done was to send same client/server request/ack
than the one I got with ethereal. 
I'm sure you already figure out most of the thing I will describe and
actually that stuff I have done more than a year ago, so I may not
remember everything accuratly

The client always send the first key, note the CompanyID field in the OPTIONS
request, I don't know if it's being used by the server to generate the first
challenge key in the answer but it change on every request. This field looks
like it's base64 encoded, but decoding this doesn't return another ascii
string.
Then the server acknowledge the request and join another challenge key.

The next step is done by the client on the RTSP SETUP with another key,
probably related to the previous one. Then the server acknowledge with
another challenge key.

At this point if the server is fake(not answering with proper challenge), the
client will stop and display an error saying that's an unknown protocol, or
something like this.
I don't remember well what the server will answer back on a fake client,
but it will also fail on SETUP...

I found back my notes, I have several ehtereal session in it, for several
type of connections (TCP/UDP).
I also have a some files about what I found on the RDT packet.
I don't know at what point those file are accurate or not, and how usefull
they are, but have a look. There is also a reference implemetation of RTSP
that is C & GPL. Maybe usefull to do the test application you were talking
about.

I put the tarball in mplayerhq.hu/incoming/real_RTSP.tar.gz

Bertrand