|
ARTeam Tutorial Removing Nag from CaptureNPrint 6.6.6.17 |
| Information | RCE on a Delphi program with Olly or with Dede |
| Target | CaptureNPrint 6.6.6.17 |
| Available | http://www.geocities.com/blue_dragon_1964/main.html |
| Tools | OllyDbg 1.10, CommandBar, MapConv Olly plugin by godfather+, DeDe 3.50 or above. |
| Protection | Nag screen called at the beginning of the app |
| level | Low of made with DeDe, Intermediate if only with Olly |
| Category | Patching |
| Author | &8~) Shub-Nigurrath May 2004 |
|
1. Introduction
|
|
Hi all, today's target is CaptureNPrint. Its protection
is quite simple, a simple Nag, but it's a Delphi program
so, loading it into Olly shows you a lot of apparently
unesplicable ASM. Well I'll explain how I solved it the false steps and the correct solution both using Olly in two different ways and also using DeDe and Olly together.... The characteristics of this crack is that the program is written in Delphi (the assembly is a little different than with MFC programs). Moreover Delphi's program ASM is generally built in a way that doesn't allow to Olly to trace stack calls, so whenver you stop at a specific handler the call stack is generally empty and you don't exactly know from where you're coming. The only informations are the return addresses from the application stack. There are three sections in the
remaining of this tutorial: |
|
2.
Let first look at the program
|
|
The first Step is to look how the program acts. It creates a complex dialog with a timer that remains on top with a disabled button that would allow you to start the application.
|
|
3. Longest way
using Olly and a lot of stack
|
|
Well, the first idea is to set a BP on Settimer, which is obviouslly involved in the dialog, but BP on SetTimer (using the CommandBar plugin) do not gives the expected results, because the call stack is empty. Anyway changing it I saw that this timer is the timer that determine the elapsed time between two intervals of the 30 that are observed by the Nag: 30 intervals of 1000 ms gives a 30 seconds elapsed time that's how the nag obblige you to stop. Realized this you can search using Olly through all the program for all constants in the code for 30dec, 1Eh and placed a BP on each MOV that copies the value to some variable. One demonstrated to be useful: 0052A2A0
C780 30030000>MOV DWORD PTR DS:[EAX+330],1E ; it's the
point where the 30 cycles of 1000 ms is set.
If I modify this the nag get's longer or shorter,
excellent but not what I need to patch the application. 0044DADC .
/0F85 B5000000 JNZ snapit.0044DB97 Ho, let's go on with a second way!! Well no worry, try another way: let's start using a SPY API tool, like Auto.Debug or the free http://www.rohitab.com/apimonitor/ and see which APIs are called (I'll not teach how to use these tools). The question is: what happens to a window when it's called? It get's in
foreground and it's activated! So if you spy through all the users32.dll
exported APIs
you would see that soon the program calls a GetActiveWindow at this point: |
|
4. Short way using
Olly and some knowledge on window handles
|
|
Well, after having learnt the longest way try to use this one. Using the first steps of the above methos we still be able to reach the call which builds the window. Do you remember the call at 0052AEAA? The one that creates the Nag screen? Well, place a Breakpoint on it (to discover it follow the early steps of the previos part of this tutorial). 0052AEAA E8 E5F1F1FF CALL snapit.0044A094 Execute the program from the beginning and once at the breakpoint press F8 to execute the call. No go to the Windows window of Olly and see which is the handle of the just created window (title is frmAds, remember). In my case is 0052AEAA, but each time is different, of course. To obtain the Windows handle use Olly as in the picture below  Well, now set a preakpoint on EAX whenever it has the value of the handle BP EAX=E0039012C and press F9 to continue. We land here 004030D0 /$ 85C0 TEST EAX,EAX but it's not impoartant, the important thing is the application stack. We cannot use the Olly Call Stack window because it doesn't survives to Delphi ASM calls and thus isn't of help for us (in this case doesn't give anything at all). The call stack taken from the application stack window in the lower right of Olly's assembly view, reports these things 0012FF90 0044C7D5 RETURN to snapit.0044C7D5
from snapit.004030D0 well, quite interesting, the first place where the program has been executed is at 0052AEC6, directly called from user32.77D444A8 and at the same level of the call at the address 0052AEAA. Excellent, go on that line in the application stack window and press enter. We land here in the CaptureNPrint application 0052AEC6 . 8B06 MOV EAX,DWORD PTR DS:[ESI] This is the return address, of the call, so the call which interests us is above 0052AEC0 FF92 CC000000 CALL DWORD PTR DS:[EDX+CC] Do you already know this line? It's the same line we patched with the other approach. NOP it and you're gone!
|
|
5. Very simple way
using DeDe and Olly together
|
|
Well, now it's time to usa another tool that works
better on Delphi programs than Olly. Deplhi program's
assembler is quite different from MFC highly compact ASM
and most of the language calls are directly placed
inside the executable, so the resulting program is
difficult to understand. Well, fortunately exists DeDe, a disassembler specifically thought for Delphi and Borland programs (I'll do not explain how to use DeDe, you can find the latest copy here, http://www.wasm.ru/tools/13/DeDe.zip which has also inside some excellent generic tutorials). Little theory for continuing. Delphi deals with global and locals variables references it on the following way: [ebp+xy] means that is pointer on global variable, [ebp-xy] means that it is pointer on local variable. Also be before pressing process that you loaded all the dsf files, from Option->Configuration->Symbols menu), them are very important to let DeDe correctly resolve the Delphi calls inside the call. Now, simply run Dede and select the CaptureNPrint program and press Process. After a while Dede finishes to elaborate the program and what you will get is a list of form, classes and variables with thei relative handlers. Dede takes you where the important code is. Well, after the processing are finished you should get something like below
Moreover there are some buttons like startme, Order and others..it's definitely our old dear Nag window! Well, see which are the events this window uses, just to underline how much different is now the asm that Olly was showing to you! Go to Procedures tag and select the FormActivate handler or the TfrmAds. You'll see a much more clear code. Let's give a short example.. in Dede isn't much clear now..Dede clearly tells to you what is Delphi and what's i program's logic! But Olly isn't out! The major drwaback of Dede is that doesn't allow live patching and the jumps are not highlighted, so long procedure aren't easy to follow. Fortunately there's an interesting plugin that allows to import .map files in the format of SoftICE or IDA into Olly: MapConv. Well, go into DeDe in the tab Exports and
select to export in MAP/SYM format for IDA/SoftIce and
save all. Now go into Olly and select to import comment
and labels with MapConv. The same portion of code
earlier not so clearly shown by Olly now becomes this
one. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Well, but take again our scope: remove the Nag of
CaptureNPrint!
TfrmAds.startmeTimer 0052A188 We really want to remove the call that activates the application and not to patch the dialog itself, so all these procedures are useless for us, because can only modify the dialog's behaviour but it remains active. The solution is to see where the TfrmAds is created or referenced from other procedures. DeDe interface doesn't allow to do this easily but offers all the instruments to make it. Go into the Project folder and select the export options as follows
"Include PAS files" is uncecked because it's useless and takes a lot of time (it recreate a .pas source with asm code inside). Remember it when you'll create keygens :-) Well Dede creates a lot of dfm files (containing exports from the program, see DeDe help to undestand what they are) and a snapit.dpr file. Open it with a notepad and make a search for TfrmAds! After some references to the object we'll find this point! * Reference
to method TfrmAds.ShowModal() Do you remenber, it's the same point where we landed
in the two previous methods and the solution is once
again to NOP the call..you now also understand what that
damn call was, a simple ShowModal! |
|
6. Making the
Target Run
|
|
Well, run the program and see that the nag has been removed, succesfully. This is the only limitation of the program. Of course if you'll like it buy it, costs very few and author needs to eat also ^__^ |
|
7. Conclusion
|
|
A BIG thanks goes to, +DaFixer, all ARTeam members and all the other from who I have learnt so much as well as the crew on exetools & other places.. This tute would not have been possible without their hard work and willingness to pass the knowledge on to others. I hope someone may find this tut useful Best Wishes &8~) Ŝħůβ¬Ňïĝµŕřāŧħ ₪ |
