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 reverser+)


Courtesy of Reverser'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:
Reverser-
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 <- pncrt.strcpy :6405CDEA 83C408 add esp, 00000008 :6405CDED 8D45A0 lea eax, dword ptr [ebp-60] :6405CDF0 50 push eax :6405CDF1 E8E4EB0000 Call 6406B9DA <- comdlg32.GetSaveFileNameA :6405CDF6 85C0 test eax, eax :6405CDF8 7412 je 6405CE0C :6405CDFA 56 push esi :6405CDFB 8B4D08 mov ecx, dword ptr [ebp+08] :6405CDFE E82DEE0000 call 6406BC30 :6405CE03 C745F400000000 mov [ebp-0C], 00000000 :6405CE0A EB0E jmp 6405CE1A If we trace back through the calls and jumps, we eventually get here: (Most of what you trace back through is stuff dealing with parameters for the 'save file' dialog box) * Referenced by a Jump at Address:6405C42C(C) | :6405C43D 83FB02 cmp ebx, 02 ? RECORD Flag, 02 if recordable :6405C440 0F85B2000000 jne 6405C4F8 ? 01 if not. :6405C446 33DB xor ebx, ebx :6405C448 395E3C cmp dword ptr [esi+3C], ebx :6405C44B 740C je 6405C459 :6405C44D 8BCE mov ecx, esi :6405C44F BB01000000 mov ebx, 1 :6405C454 E889EEFFFF call 6405B2E2 * Referenced by a Jump at Address:6405C44B(C) | :6405C459 8B4508 mov eax, dword ptr [ebp+08] :6405C45C 85C0 test eax, eax :6405C45E 740B je 6405C46B :6405C460 50 push eax :6405C461 8D4DEC lea ecx, dword ptr [ebp-14] :6405C464 E8C7F70000 call 6406BC30 :6405C469 EB1C jmp 6405C487 Initially, I wasn't sure which place was the record flag check, either at 6405C45C or at 6405C43D, so I set breakpoints at each, and noticed that if the clip was recordable, at 6405C43D ebx was 02 otherwise it was 01 if not recordable. Note that this flag is not (as far as I can tell) related to the file header flags in the .rm or .ra files I mentioned at the top of this essay. Regardless of if the clip is a video or audio clip, ebx will either be 02 if recordable, 01 if not. So, what do we do here? Well, we want the target to think every clip is recordable, so when we get to the cmp ebx, 02 we expect that the jump at the next instruction 'jne 6405C4F8' will NOT be taken. We could nop the 6 bytes at 6405C440, but a cleaner way might be to replace the comparison altogether with a jump to the instruction we want to go to, like the following patch: :6405C43D EB07 jmp 6405C446 :6405C43F 90 nop Now, we simply go directly to where we would go anyway if the clip was recordable. Try this out using the code "patch.class" utility in Wdasm (see my 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
(c) x86, 1997. All rights reversed.
You are deep inside reverser's page of reverse engineering, choose your way out:

Back to project 6
homepage links red anonymity +ORC students' essays tools cocktails
academy database antismut search_forms mail_reverser
is reverse engineering legal?