ARTeam Tutorial

Visit: http://cracking.accessroot.com | http://forum.accessroot.com

DVDLabPRO 1.53
Build 050530

by




Information Reversing custom protection
Target

DVDLabPRO 1.53 Build 050530

Available http://www.mediachance.com/download.htm
Tools  OllyDbg 1.10 , PEID
Protection Trial time
Level Beginner
Category Reversing
Author(s) ThunderPwr Dec 2005
Requirements Windows XP SP1, IE 5.5 and above for best viewing


Introduction


Hi all today's lesson is about DVDLab Professional version reversing, this task is reached in interesting way by close looking at the protection scheme used in this nice application.

This tutorial will cover some basic concepts about using OllyDbg.

There are following sections in the remaining of this tutorial:


   1. What we can do (brief explanation about the patching).
   2. Proof of concepts (understand the protection)
   3. Patching.
   4. Conclusion and remark
   5. Greetz



1. What we can do


Our purpose is to show how defeat a protection which crypt the code in run time, then show also some information about how we can restore the original code and save the executable without crypting code inside. No more information about cracking will do in this tutorial because the aim is just to show how the protection work and proof the weakness of this one.



2. Proof of concepts


As usual we have to look on program behaviour after installing step and know if the target is packed or in a plain form.

To perform this test we can use classical PeID approach (and trust in your sense also because some protector is able to fool this file scanner and similar tools) then we start to scan the target application with name DVDlabPRO.exe located into the target installation folder.


Fig. 1 PeID file scannig.

program isn't packed anyway then scan about some signature (press -> button then choose Plugins and finally select the Krypto ANALyzer tools):


Fig. 2 Crypto signature.

No crypto signature is present.


Fig. 3 Crypto signature result.

There is some stuff related to CRC, but really this isn't a problem and we'll show that later.
Well now is time to launch the program and see the behaviour, we have a starting nag which show the residual trial time.


Fig. 4 Starting nag.

Now you can press the Continue button and then execute the program or Exit.

As usual, after looking the target behaviour we have to walk into the debugging stage in order to know in more deep manner the target, to do this load the target in OllyDbg, activate the IsDebuggerPresent plugin (just to avoid some simple antidebugging protection) and then press F9 in order to show if this is runnable into the debugger. The nag arise and when you press the Continue button the target take to run.

Classical approach is related to some simple string search by using the OllyDbg features, this task is useful to hook some interesting points related the registration or trial checking. To do that, with the target stopped into the Entry Point right click and select the Search for option then select All referenced text string:


Fig. 5 Target Entry Point (EP).

Into the new window scroll up until you're able to reach the top and perform the string search with right click and select the Search for text option, a new dialog box arise and here you can write the string to search.
In order to start with common reasonable sense we can refer to some text present into the starting nag screen.


Fig. 6 The search string dialog box.

Other commonly used word may be:

  • expiration
  • expired
  • trial
  • eval
  • day
  • registered
  • unregistered
  • code
  • thank
  • restart

of course you can also use some short form like expir instead the full word expiration and so on. Also unckeck the Case sensitive box, in this way we can search and find all the word in uppercase or lowercase or mixed form wich match with the searched string.


Fig. 7 Search for text feature.

if you try to search with this common keywords nothing of reallyinteresting arise, this may be for some reason:

  • the registration/trial code is into other module (external exe or into some dll file)
  • the registration/trial code is builded into the main code in crypted form
  • a mixed of the previous option may be also still present

The only search wich give some result is about eval keyword (yup, this is the message which you can see into the starting nag screen, refer to the fig. 4 for major detail about it):


Fig. 8 Some text search result.

Double click the highlighted row, we have:


Fig. 9 Referenced string.

Uhm, this code isn't really interesting because is simply a location with a pointer to the message, but we can try to stop the target execution when this message will be accessed to the first time, in order top do that restart the target and then press CTRL+G and write 0x0056156F.


Fig. 10 Going to the message address.

Then right click and select the Follow in Dump -> Constant:


Fig. 11 Dump window.

scroll up a little into the dumpinfg window, there is a more interesting things:


Fig. 12 Dump window.

we can see the %d days left string, for those C/C++ programmer %d is more familiar and is the formal argumento for the printF formatting instruction when you've to format a integer variable in a string, this means also that near this point we can found the trial time calculation code. In order to break in this code we've to place a memory breakpoint on access into the highlighted string and then wait for OllyDbg hoping it break somewhere into the code.
Then restart OllyDbg (by pressing CTRL+F2) and jump to this area (CTRL+G into the dump window and write 0x007A20C8) and place the memory breakpoint (see figure 13):


Fig. 13 Memory breakpoint on access.

now press F9 in order to start the target, OllyDbg break into our breakpoint:


Fig. 14 Code at the memory breakpoint.

now remove the memory breakpoint and press CTRL+F9 in order to skip the routine and stop into the last RETN instruction located on 0x0069A4BC.


Fig. 15 End of the routine.

Press F7 to execute the RETN 8 instruction, execution jump to the 0x0069A4D1 then press again RETN, now look at the code window this time is very interesting:


Fig. 16 Main code.

the code itself seems have no sense but really this is a true execution code and this code isn't analyzed by OllyDbg when the target was loaded, this means that this code isn't still present at the target start-up, hence was decrypted at run-time by the target itself. To proof this sentence simply force OllyDbg to perform the code analysis by pressing CTRL+A.


Fig. 17 Main code decrypted.

well, this code isn't really present at the start-up and to proof this restart the target and the jump to some address inside the code shown into fig. 17, for example the address 0x00561694.


Fig. 18 Same code when the target is stopped into the Entry Point.

this code is quite different from the one shown into the figure 17, also if you perform the code analisys nothing apper simply because this code isn't valid and then before to be executed it must be decrypted. Now our goal is find the decryption code and this task is easy to do by using again the memory breakpoint on access, for example, at the address 0x00561694 then press F9 to run the target. OllyDbg now break into another address 0x00561597, now right click and the select the Analysis option (see figure 19 for the detail):


Fig. 19 Decryption of the code.

then press CTRL+A to force the analysis, now we can see the code in a more readable way:


Fig. 20 Decryption loop.

from 0x00561597 to 0x005615B4 we have one decryption loop, to skip the loop and then force the decrypting of all the code simply place a memory breakpoint on execution on 0x005615B6 and press F9.


Fig. 21 End of the decryption loop.

again we have to analyse the code by using CTRL+A:


Fig. 22 Code decrypted.

If you continue into the code stepping by using F8, another loop start from 0x00561799 to 0x005617B6, again to skip all the loop place a breakpoint on execution at the loop end (just after the LOOP instruction) and the press F9. This loop is a encryption loop and the purpose of this one is encrypt back the previous code in order to keep it hidden after the execution, then now we have to avoid this loop and then place a series of NOP from 0x00561799 to 0x005617B6.
After this first look we can suppose the existence of other similar loop then we can try to perform a search about this by using the start instruction SUB BYTE PTR DS:[EBX],AL as our key search, this give us this entries:


Fig. 23 Search for some code to found all the loop.


Fig. 24 Other crypt/decrypt place.

place a breakpoint inside every entry (right click and select Set breakpoint on every command) and then restart the target. If you press F9 the first breakpoint was in 0x005092BE:


Fig. 25 First breakpoint (decrypting loop).

place a breakpoint on execution to 0x5092DD:


Fig. 29 Hardware breakpoint window.

remove the memory breakpoint on 0x005092BE and press F9, when OllyDbg stop the code below the loop must be fully decrypted. Now we can remove the loop code by place a series of NOP between 0x005092BE and 0x005092DB and save all the target to the disk (scroll up to the bottom of the code window area you must see the 0x00401000 address and press Shift+End in order to select all the target code, then right click and choose the Copy to executable option then choose Selection, finally Save file to dump the target on disk).

At this point we've defeat the first loop and keep the code in a plain form (try to execute the target, this work fine), now we have to start our analysis just after the code decryption then run the target and wait for the breakpoint on 0x005092DD. Step trough the code by using F8:


Fig. 30 Stepping trough the code.

we can look interesting label like RegName and RegCode, step until you reach 0x0050934E and jump into the call procedure.


Fig. 31 Registration checking routine.

now we've another loop, following the same method show for the first loop we have to place one hardware breakpoint on 0x00501761 and press F9 to decrypt all the code, NOP-ing it from 0x00501742 and 0x0050175F and dump again the file on the disk. If you start to step with F8 from this point, at the end of the routine there is another loop, this one restore the code into the crypted form to hide the checking step, then we can avoid this by NOP-ing all the instruction between 0x00501A8B and 0x00501AA9 and dump all to the disk.

Now step and return to the main code at 0x00509603 there is another loop which crypt all the previous code to keep this hidden after execution, again place a series of NOP between 0x00509603 and 0x00509620 in order to avoid this encryption stage and dump the file on the disk.

This is enough for reversing this application, now if you like, is possible also defeat the starting nag and keep the program behaviour like as registered one.



3. Patching


In this chapter we cover the simple patching stage (just for phun) about trial time limit.
All the analysis will be made by using the dumped file obtained with the step shown into the previous chapter.

Patching is very simple:


Fig. 32 patching code for nag defeating.

Another think is when we look the about window, there is one unregistered string, to skip it perform a string search for Unregistered.


Fig. 33 About unregistered message.

double click on the highlighted row to see the code:


Fig. 34 About code.

to skip the unregisterd message simply patch the JE at 0x0048112C with a NOP instructions:


Fig. 35 About patching.

That's all.



4. Conclusions and remarks


I hope this tutorial can be useful to learn somethings about memory breakpoint usage in OllyDbg and some things about nice but weakness custom protection techniques.

Remember, if you plan to use this good software you should purchase the product to support the authors to develop other good and best protected ;-P software.

Any suggest, correction or criticism is welcome, if you need help about this tutorial or other stuff you can reach me on ARTeam forum.



5. Greetingz


Thanks to all the ARTeam members and ARTeam forum members.
Thanks to all the people who take time to write tutorials.
Thanks to all the people who continue to develop better tools.
Thanks to all the people at Exetools and Woodmann for providing great places of learning.
Thanks also to The Codebreakers Journal, and the Anticrack forum.
Thanks to all the great teams: SND, TSRH, MP2K, ICU, REA, and all the others. .