CDProW v2.3-by Kathras

Target: CDProW v2.3
   
Purpose: To educate my peers on VB patching techniques without modifying dll's.
   
Approach: Pure Logic Mr Spock. Hopefully after reading this essay you will discover that VB is very logical in naming its api's. A little bit of common sence is all that is really
                   needed to kill nearly any VB nag screen.
   
Tools: Softice, Hiew
   
Difficulty: Beginner, with sufficent knowledge of Softice and its internls.

 
Introduction
   
After several years of avoiding VB programs because of its different structure, I finally decided to sit down and try to learn something. After many hours of purely random Trial and Error, I stumbled upon a few tricks that will allow me to reverse close to 90% of my targets.
 
After pondering what I had learned for a while, I noticed a strange logic in what I had discoverd as far as api naming. Now after sitting on this a while I am going to share this approach.
 
 
Procedure
   
To begin we must run our target to find out what we are up against. So after running CDProW.exe we discover that instead of running the program  as we intended, we are presented with a nag screen that we must click OK to close. Also, we notice that it appears we have a time limit to deal with.
 
First thing is first, we must remove the nag. The first thing we must do is to figure out where to set a breakpoint in softice.To save hours of speculation I will tell you exactly where to break. __vbanew2 is the magic api. Which makes sense because the nag screen is a New object. So we set a breakpoint in Softice:
 
bpx msvbvm50!__vbanew2
 
Now we run our program and we find ourself landing inside of msvbvm50.dll. We don't want to mess with slopy dll editing today so lets F11 out of there. Now we are inside of CDProW.exe and find ourself here
   
:00441AD1 A118814700               mov eax, dword ptr [00478118]   <----- We break here
 00441AD6 68B8C24100              push 0041C2B8
:00441ADB 56                               push esi
:00441ADC 898560FFFFFF          mov dword ptr [ebp+FFFFFF60], eax
     
Now to me this bit of code doesn't look very interesting so les step down through with F10 until we hit this line:
 
:00441B59 E86298FFFF              call 0043B3C0
   
When we try to step over this call, we get kicked out of Softice and that annoying nag screen comes up. So we hit OK on the nag and poof, we are back into softice on the line right below the call. We have found the call that is exclusivly used for creating the nag screen! We could simply hex out this call and that nag will be forever gone. But assuming that your reason for reading this essay is to actually learn something, we are going to trace a bit more. Lets clear our breakpoint in Softice on __vbanew2 and set a new breakpoint on that call. So in Softice type:
 
bc *
bpx 441b59
   
Now lets exit Softice and restart our target program. And here we find ourself breaking on that call. This time we will trace into the call with F8 nothing really looks horribly interesting so lets continue to step down with F10 until we reach this line:
 
:0043B42E FF93B0020000            call dword ptr [ebx+000002B0]
 
This is 90% of the time the magic call for every nag screen. You will always be able to recognize it by the call to the dword length code at (some register+000002B0). In fact in most nag screen cases you can find this magic line by simply searching for the string +000002B0 inside of w32dasm. You might find two or three other locations where this type of structure is used but it shouldn't take you long to find the one you are looking for. Now to remove the nag, you are probably thing that we can simply hex out this call. Well if you do that, you are gonna get a nasty little crash when you start the program. Why? you ask... the reason is simple we need to fix the stack (so the program thinks that function was executed) there is a nice big fat ret instruction a few lines down from that call. When that ret is steped into with an incorrect number in ESP, then your code returns to some strange memory address that causes a not so pretty crash. This is easy to fix using the six bytes of code that make up that magic call. The opcodes for that call are
 
FF93B0020000
 
We need to replace that with:
   
83C424EB0190
 
This will give us three seperate instructions:
 
:0043B42E 83C424              add esp, 24
:0043B431 EB01                   jmp 0043B434
:0043B433 90                        nop
   
As you can see we are fixing the value in ESP by adding 24h to it. You can easilly obtain this value by subtracting the value of ESP after that call is executed from the value of ESP before that call is executed.. The jmp and the nop are simply there to avoid executing several nop instructions in a row (not always a good idea and a pet peve of mine). Now we fix everything nice and pretty in Hiew. And the nag is Nevermore said the raven. We, however, aren't finished yet. We still have that aggrivating 30 day time limit to defeat.
 
I am not going to go into a whole lot of detail on how to crack this time limit,  as it is not the primary focus of this essay. We notice after setting our system date ahead by 31 days that our almost cracked program ceases to function. It gives you a messagebox giving you the option to register with a code or to cancel (since this essay is not about how to reg a vb program we will ignore the registration part of this, this essay is about patching pure and simple). The first thing we need to do is to set a breakpoint on VB's messagebox function. This api is rtcmsgbox. So in Softice type:
 
bpx msvbvm50!rtcmsgbox
 
Now lets exit softice and start the program. Poof, back into Softice..Hitting F11 to get out of the dll's code we find ourselves looking at our target messagebox.  So we hit cancel to get back to our programs code. After we get back into Sotice inside of CDProW.exe we find ourself here:
 
:00441A74 FF1588134800            Call dword ptr [00481388] <------ the call to rtcmsgbox
:00441A7A 8BC8                           mov ecx, eax <--- We break here
 
Simply removing the messagebox will not fix our problem. So we have to think for a minute. Speculation leads you to the idea that there must be a check above this piece of code that checks if the program is expired or not.. Lets scroll up the code window in softice to see what we can find. A few pages up we find what we are looking for:
 
:00441995 6681FEF401                cmp si, 01F4
:0044199A 0F8518010000            jne 00441AB8
 
Simply change that jne to a jmp and no more experation.
 
 
Summary
 
 Sure we could have avoided everything explained in this essay just by patching the jne just 5 lines above the jne we just edited, but tht is not the point of this essay. The point I'm trying to explain is a generic technique on how to remove nag screens from an application coded with Visual Basic without editing the runtime dll's. This technique seems to be almost univeral among all VB coded applications, whether it be a exe or an activex control or dll. DLL patching can cause bad things to happen in unexpected places in programs that don't need to be enhanced for evaluation purposes. This is clean and straight to the point


Greets

Too many friends new and old to list. You know who you are.