x86new1

How to enable the recording
of Real Player audio clips

...even if the content provider has designated them as non-recordable!

by x86
(10 September 1997, slightly edited by fravia+)

Courtesy of Fravia's page of reverse engineering

Well, this kind of reverse engineering essays ("adding functionality you're NOT supposed to have") are (in my opinion) among the most interesting works... we let software do things that "it should not do"... that's the amazing "white magic" that you are learning here! And our +friend x86 has found a particularly interesting target... I have inserted this essay among the "crippledwarez" section, but, as you will see, it shows NOT the crack of a "crippled" program, it explains how to reverse engineer a whole (idiotic) software convention! Here is x86's email text:

Fravia-

Here is an essay I wrote describing how to enable the recording of

Real Player audio clips even if the content provider has designated

the clip to be non-recordable.

As I mention in the essay, I am currently working on enabling the

saving of the video-clip content as well (right now, this enhancement

will record the audio portions of video clips but not the actual video

itself) and will submit that as another tutorial when I finish.

x86

Adding Functionality You're Not Supposed To Have

(Recording restricted audio clips in Real Player Plus)

by x86, September 1997

Tools and Files needed:

Wdasm 8.9 (for code patching and debugging, but any version will do)

Your favorite hex editor

Real Player 4.0 available at:

http://www.real.com/products/player/index.html

(needs easy to crack serial # to function as the Plus version)

RealPlayer Encoder (free) available at:

http://www.real.com/products/encoder/index.html

Optional Items:

SoftIce (for you diehards :)

Borland Resource Workshop

Hello again, fellow +crackers! I have a registered copy of Real Player

Plus, and it allows you to record Real Player clips to your hard drive so

you can listen to them whenever you want. However, the content providers

can designate whether or not a clip is recordable.

As you might guess, commercial sites like Warner Bros. do not "allow" you

to record their clips. In this tutorial, I will show you how to enable

saving of Real Audio files in Real Player Plus, regardless of whether or

not THEY want you to!

Note, this is for the registered version only. This isn't a tutorial

on cracking the registration functions, but a more interesting example

of adding functionality to the program.

Serial numbers for this program are all over the web, so finding one

shouldn't be a problem, should you be too lazy to crack directly its

banale protection scheme.

I will also point out now that my goal in this project was simply

to be able to record any sound files that I wanted to.

The following lesson will allow you to record the audio portions of ANY

clip (including the audio portions of video clips), but you will not be

able to record the video.

It was only after finishing this that I thought about recording videos as

well. Since the video quality can be on the poor side, unless you have

an ISDN or better connection, this wasn't really a priority of mine to

start with.

However, in the interest of taking full advantage of our target, I am

working on that right now, and will post the results as a separate essay.

A brief introduction to Real Player clips

There are 3 types of files that can be played.

.ra files are audio files only.

.rm files are audio/video,

and

.ram files are real audio metafiles and simply contain the path of the

clip you want to play (which can either be a file on your system or an

URL type locator called a pnm, which looks like

pnm://204.34.5.455/somefile.ra or something similar).

The .ra and .rm files have a header which contains info about the clip.

Progressive Networks helps us reverse engineer their programs by giving

away copies of the RealVideo encoder so we can create our own audio and

video files to see how they work.

Included in this program is a utility which will dump the headers of .ra

and .rm files to a text file.

Progressive's website also has a developers section which gives information

about adding Real Media capabilities to your own programs.

Among other things, they tell you exactly what the header information

means and how it's laid out.

The most interesting thing is that there is a flag variable which describes

the properties of the clip as follows:

flags: 16 bits

Flags indicating characteristics of the RealMedia file. The

following flags are defined:

#define PN_SAVE_ENABLED 0x0001

Allows clients to save a copy of the RealMedia file to disk.

#define PN_PERFECT_PLAY_ENABLED 0x0002

Allows clients to use extra buffering to ensure Perfect Play.

#define PN_LIVE_BROADCAST 0x0004

The RealMedia file is being generated by a live broadcast.

Why do we care about this? Because, the flags parameter is what will

tell us if the clip is designated to be recordable or not.

This information will be particularly relevant for my next essay, saving

Real Player video clips.

We don't even really need the header dumping utility if we know how the

header is designed, but dumping a .ra or .rm file and then comparing

the text output with the binary data can help you see how the files are

arranged. The relevant byte of the flag variable will be at offset 0x43.

If you want to learn more about the Real Media file format, visit:

http://www.real.com/devzone/tools/rmsdk/guide/index.html.

As I mentioned, this info isn't absolutely necessary for this exercise,

but understanding the file format of one of our targets can't hurt you

either!

So, let's begin. We need some sample files for testing. Use the Real

Encoder to create two clips, one which is recordable and one which is not.

I simply imported a short .wav file. Make sure to use the same .wav for

both clips, that way the only difference between them will be the flag

bits. The encoder is pretty easy to use and has a help file, so I won't

explain its use here (it's easy).

The first thing I did was to see how the program reacted when trying to

record a `non-recordable' clip. You see a message saying `Can't record

clip' and a tape deck icon with an `X' through it. Ok, lets see what we

get if we try and record a "recordable" clip.

Ok, we get a `save file' dialog box. Get your dead listing of the

main executable rvplayer.exe. The `save file' dialog resides in

comdlg32.dll.

We see that it IS an imported library, but the only function from this

library imported in rvplayer.exe is GetOpenFileNameA.

Ok, so the call is in another .dll somewhere.

Let's take a look at all of the imported modules in rvplayer.exe.

Import Module 001: KERNEL32.dll

Import Module 002: USER32.dll

Import Module 003: GDI32.dll

Import Module 004: comdlg32.dll

Import Module 005: ADVAPI32.dll

Import Module 006: SHELL32.dll

Import Module 007: ole32.dll

Import Module 008: pncrt.dll

Import Module 009: pnui3240.dll

Import Module 010: VERSION.dll

Ok, you can see here that all of these dll's are basic windows libraries

with the exception of pncrt.dll and pnui3240.dll.

If you look at the imported function list for pncrt.dll you see that it

looks like some kind of C runtime library (pncrt = Progressive Networks

C Runtime Library?), but pnui3240 has got some interesting looking

functions!

Addr:0000E450 hint(002A) Name: RaguiSetupClient

Addr:0000E464 hint(000C) Name: RaguiDoPlay

Addr:0000E472 hint(0027) Name: RaguiSetSource

Could `Ragui' mean `Real Audio Graphical User Interface'? Fire up Wdasm

and load rvplayer.exe into memory. Hit F9 (run) and let it go until the

main Real Player window is fully loaded.

Now, in the lower left debugging window, scroll down the list of active

dll's until you reach pnui3240.dll. Double click on it to load it

into memory (make sure your debugger options under Debugger/Options/Debug

only this process is unchecked). Now let's have a look at the string

references here.

(You could also just get a dead listing of this file, and peruse it at

your leisure under a palm tree somewhere, but hey, I like eye strain!)

Immediately we see we are in the right location. There are many

references to `recording', but what immediately caught my eye were the

references "NO_RECORDING" and "RECORDING".

Let's look at the relevant section:

* Referenced by a Jump at Address:64064628(C)

:64064638 B934D40864 mov ecx, 6408D434 ->"NO_RECORDING"

:6406463D BF01000000 mov edi, 1

:64064642 EB0A jmp 6406464E

* Referenced by a Jump at Address:6406462D(C)

:64064644 B928D40864 mov ecx, 6408D428 ->"RECORDING"

:64064649 BF08000000 mov edi, 08

If we follow the jumps backwards, we get here:

* Referenced by a CALL at Addresses:6406330F, :640645D0

:64064609 56 push esi

:6406460A 57 push edi

:6406460B 83B90508000000 cmp dword ptr [ecx+00000805], 0

:64064612 8BF1 mov esi, ecx

:64064614 745B je 64064671

:64064616 8D865D080000 lea eax, dword ptr [esi+0000085D]

:6406461C 8B4C240C mov ecx, dword ptr [esp+0C]

:64064620 3908 cmp dword ptr [eax], ecx

:64064622 744D je 64064671

:64064624 8908 mov dword ptr [eax], ecx

:64064626 85C9 test ecx, ecx ;If ecx == 0, NO_RECORDING

:64064628 740E je 64064638 ;We are here

:6406462A 83F901 cmp ecx, 1 ;If ecx == 1, RECORDING

:6406462D 7415 je 64064644

:6406462F 33C9 xor ecx, ecx

:64064631 BF01000000 mov edi, 1

:64064636 EB16 jmp 6406464E

So, what do you say? Patch the 'je 6406438' to 'jmp 64064644'?

That was my first thought too.

Before you answer, if you have Borland Resource Workshop, fire it

up and take a look at pnui3240.dll.

Notice under the bitmap section we have NO_RECORDING and RECORDING.

So, these are just the tape deck icons which indicate

whether or not the clip is being recorded.

Changing this location will do nothing other than give you an 'always

recording' icon. Let's take another approach.

We know that if a clip is recordable, we will get the `save file'

dialog if we hit the record button.

Look at the import section of pniu3240.dll and you'll see:

Import Module 004: comdlg32.dll

Addr:0004109C hint(000B) Name: GetSaveFileNameA

Addr:00041084 hint(0004) Name: CommDlgExtendedError

Addr:000418C2 hint(0009) Name: GetOpenFileNameA

Ok, so let's see where it's called from:

* Referenced by a Jump at Address:6405CDDD(U)

:6405CDE4 50 push eax

:6405CDE5 E826090100 Call 6406D710 previous essays if you don't know how to do this).

Now, see if it works. Load up the demo clip and try and record it.

Ok, the save dialog comes up and it seems to work.

The `RECORDING' icon is on and tere is no message about `Can't record clip'.

Let's play it back.

Ok, the audio works perfectly. Get out on the net and give it a test

drive.

May I recommend http://www.hardradio.com? You'll see that you can now save

any audio clip you choose!

A summary of the patch:

At offset:

(B83D) Change 83 FB 02

to EB 07 90

Well, I hope this essay was informative.

I don't know yet why the video portion of the clip is not saved, but from

a cursory inspection it appears to be a little more complex, and will

definitley involve analyzing the file header and its subsequent use.

Should be interesting! Until next time -

x86

You are deep inside fravia's page of reverse engineering, choose your way out:

Back to project 6

links

cocktails

is reverse engineering legal?

by x86 (10 September 1997, slightly edited by fravia+)

by x86
(10 September 1997, slightly edited by fravia+)