Hey, just found this forum and it seems great.

I've just started out to learn myself some basic cracking of application. From beeing an application developer I'm now intrested in the opposite, to reverse engineer them

So I got this application I want to remove a time trial nag from (for practice as well for usage), which popups during a button click event. The program is made in VB 6.0 according to the hexadecimal output as it loads the VB6.0 dll file. I've used win32dasm to dissassemble the exe file and also used SoftICE runtime debugger, but I have a hard time to really find the exact jump, as It must be a conditional jump in there somewhere as it prolly is something like this; If valid -> go offset else openTrialDialog. Problem is that I'm not to found with Intel ASM.
I've tested to put NOP (90 hexa) directly into the exe file at a place where I thought the dialog appeared (at the button click), which made the program return an error (200) and stopped the execution.

Questions:
1. Is there any way to patch the exe file directly?
2. If so, can it be done with NOP's or do I have to know the branch location for the non-trial continue.
3. The offset or exact address could be seen if I find the exact conditional jump, right?
4. IF I find the exact location in the dissassembled code, is the address of this jump at the same address as the hexadecimal output gives?

Tools I've used:
*DriverStudio (SoftICE for realtime debugging)
*win32dasm (to dissassemble and realtime debugging)
*ultraedit (for hexa and patching)

I've spend about 20hours myself on this project and as it is the first time I try to crack an application I need some help on the way.

Best Regards,
Nergal

ps. Sorry for the bad english, I'm too tired to write correct or even see my spelling misstakes .ds

Update:
I found a place in the asm code where there is a "DENY_EXPIRED" set, If I could remove that set perhaps it would fool the program to continue. But where in the exe file is this place that I find in the dissassembled file?

Sugestion 1.

You can modify the code in memory using the A (Assemble) command of Sice (See the manual for use), or modify the data in memory by locating it the data window (wd) then clicking on it and editing directly during Sice debugging session. Taht way you can test 'on the fly' if your modification indeed byapasses the protection and allow the app to run.

Once you know that your patch works, you can find the location in the Disk file using a variety of methods:
Learn the inner workings of the PE file structure RVA, base address versus virtual adress

or

Write down the pattern of bytes (10 to 15 should be enough, bytes not the opcodes ) around the area you want to modify and do a byte search in Ultraedit.

To see the bytes that encode the instructions you have to type the CODE ON command and option in Sice.

If it's a time-trial, you should attack the timing mechanism instead of the nag. If you manage to remove the nag but leave the timing code intact, you'll have an app that doesn't show the nag when the trial period is over, but otherwise is still "expired". This is like amputating an infected arm of someone who has cancer, but leaving the cancer alone to spread and eventually kill the person.

I thought of that as well and have tried to find some different timer mechanisms. I have dissassambled VB 6.0 DLL file to get the exported calls that it provides and tried to break the attacked program at the places where date/time functions has been used. But it doesnt break at the point where the nag appears. I actually managed to remove the nag (for practice) as I found out the place where the program calls a new instance of a window, but then I get an error, so it seems that I ruin an ActiveX component call by patching at that place.

Any tips for what I should look for when it comes to timers, else then what I've tried?

Thanks for helping me!

You're best off trying to locate the point(s) where the target works out how many days you have left in your trial. If you can then patch the appropriate conditional jump so that execution continues regardless of the current date & install time then you'll have done all the important work. You're then left (possibly) with the cosmetic work of removing any nag screens, string resources telling you that you're 'UNREGISTERED' etc.

Chances are that any such checks will be done following a call to GetLocalTime, GetSystemTime or GetSystemTimeAsFileTime (although there are many other ways to do this). You may think that since you're reversing a VB app that you should be hooking MSVBVM's time & date functions. This may be the case but it's worth noting that these functions merely wrap the three User32 functions I listed, and that VB apps have the capability of (more or less) directly calling API functions.

I find that NuMega SmartCheck is an excellent tool for reversing VB targets, since they are so heavily API-driven. If you can afford it or if you are the type to go out and get a cracked copy then SmartCheck comes highly recommended (by me as well as many others) and will prove invaluable if you go on to do much more VB reversing.

Regarding your queries about patching the target: Reversing is already a tedious enough activity. Having to disk-patch any changes you wish to make would take just about all the remaning fun out of it. Rather, we reversers prefer to patch the code in memory when testing, and commit the changes to disk only when we're sure we've made progress. This way, any mistakes can be wiped by merely restarting the target.

You say you're using SoftICE. I won't give my usual rant about SoftICE, but if you don't like the interface (which I certainly don't) then I'd suggest, unless you need a kernel debugger (which you certainly don't for this target), upgrading to OllyDbg. In this reverser's humble opinion, OllyDbg is smoother, cleaner, prettier and far easier to use. Not to mention the fact that it's fast becoming the standard for tutorials.
Anyways, I'll go along with SoftICE for the moment despite my limited experience. You can patch code in memory using SoftICE's built-in assembler - I believe the command is 'E' (you'll find details in the manual). Other common ways to branch-test on-the-fly are to modify the values of registers, patch data in memory and to invert CPU flags. I won't explain how to make SoftICE do these things (mainly because I can't remember) but you can find out quite easily.

As I said, you'll probably spend most (90%-99%) of your time tracing the program and making such temporary modifications. Only once you've succeeded in doing this should you need to worry about patching the file on disk.

A note for when you do need to change the disk image: The addresses of instructions in memory and on disk are not the same, in general. They are related by a piecewise-linear mapping as prescribed in the PE header's section table. If you want to do things properly, you should invest a little time in learning the basics of the PE structure. You should then, with a little help from a hex calculator be able to convert between raw and virtual addresses in seconds. If you are in a hurry then you may prefer to write down a 10-15 byte string of bytes at or near your virtual address and use a hex editor (HexWorkshop, HIEW, LordPE, UltraEdit) to perform a binary search for this string. If the result is unique, then you've found the right spot to patch.

Regards
Admiral

Your answer made it much more clear to me. I've tried to find this "SmartCheck" program but haven't found it, guess I have to search a bit more.
I used SoftICE first but as you describe it's pretty much to learn as it's console based (VisualICE didn't work out with this VB app, perhaps something I had forgot to configure). I've just installed Ollydbg and going to learn how to test changes during runtime in memory.

Now to the problem or what shall I say, the issue, with this target application is that I've tried to understand how the trial check is performed. The thing is that the customer/serial number has allready been removed by some "cracking team" but they forgot to remove protection for the important feature of the program, which is the reason I'm trying to break this application (and because it's really fun to learn howto).
I found out that it connects to a server on port 80 to propably check if the license is "OK". But it should be possible to get around this check by jumping to another location, to the part where the check was "OK". Seems possible right? So I think that the "trial" isn't really timerbased.

win32dasm gives some information about words beeing found, for example "DENY_EXPIRED", "ROGER_THAT", which I ofcourse think has something to do with the trial check. Perhaps its dangerous to get fooled by these? I traced the jumps to these parts in the code but I can't make anything out of it.

Perhaps this was a heavy project to start out with, but I still got it as my goal

I could send the program, which is small and consist of one exe file, if someone would have time to give me some hints. Just send a pm and I'll send it to you.

Thanks again for having patience with a nub like me....

nergal,

It's good to hear that you've read my post carefully and taken the advice. I'll do what I can to help you through this challenge. By all means, send your target over. It's easier to help someone do something if you know the answer .

A few general pointers about cracking VB apps:

Unless the author knows what they are doing (which they usually don't), everything will be done using VB's intrinsic types. This means that just about everything down to an integer comparison will work using calls to MSVBVMxx.dll. So make sure you know what all the conversion and comparison functions do.
This also means that you should keep a close eye on which module your current thread is running in (It's in the title bar of the disassembly window). If you find yourself in MSVBVM or any of the Win32 APIs (Kernel32, User32, GDI32, ADVAPI32 in particular), make liberal use of ctrl-F9 (run to return) to get back into the main module. You may find it useful to set 'After executing RET, step over RET' in OllyDbg's options.

Indeed, those two strings you've found may be worth investigating, but bear in mind that it's slightly unusual (and very amateur) to manage a binary state using strings, so this may be a diversion.
Another idea may be to get hold of a network packet sniffer (such as Ethereal) and try to work out just what's going on behind your back on port 80?

If you PM me your target I'll be more helpful.

Regards
Admiral

I'm not sure if you're already using one but you didn't mention it, so:
I would recommend a VB decompiler. VB is apparently really hard to decompile so they are usually called half or semi decompilers and their disassembly is usually worse off than IDA's or olly's. Their strength lies in showing you all the form structures and form event handlers. That way you can see what functions are called when a particular form is loaded or what objects are in a form. My favorite is Visual Basic Decompiler Lite because of its clean interface, but all the free ones I found do the same thing.

Other VB decompilers: VB ReFormer (wouldnt open a native VB6 for me?), VB ResQ, P32Dasm, race (does P-Code VB only), vbde

There is also an OllyDbg plugin called VBHelper that identifies VB function calls. Just remember that VB is extremely redundant and alot of function arguments are passed in the registers instead of the stack.

Maybe the strings are commands sent/received between the internet server?

You can send me the program too if you want, I could always use the practice with VB.

Hey, just found this forum and it seems great.

I've just started out to learn myself some basic cracking of application. From beeing an application developer I'm now intrested in the opposite, to reverse engineer them

So I got this application I want to remove a time trial nag from (for practice as well for usage), which popups during a button click event. The program is made in VB 6.0 according to the hexadecimal output as it loads the VB6.0 dll file. I've used win32dasm to dissassemble the exe file and also used SoftICE runtime debugger, but I have a hard time to really find the exact jump, as It must be a conditional jump in there somewhere as it prolly is something like this; If valid -> go offset else openTrialDialog. Problem is that I'm not to found with Intel ASM.
I've tested to put NOP (90 hexa) directly into the exe file at a place where I thought the dialog appeared (at the button click), which made the program return an error (200) and stopped the execution.

Questions:
1. Is there any way to patch the exe file directly?
2. If so, can it be done with NOP's or do I have to know the branch location for the non-trial continue.
3. The offset or exact address could be seen if I find the exact conditional jump, right?
4. IF I find the exact location in the dissassembled code, is the address of this jump at the same address as the hexadecimal output gives?

Tools I've used:
*DriverStudio (SoftICE for realtime debugging)
*win32dasm (to dissassemble and realtime debugging)
*ultraedit (for hexa and patching)

I've spend about 20hours myself on this project and as it is the first time I try to crack an application I need some help on the way.

Best Regards,
Nergal

ps. Sorry for the bad english, I'm too tired to write correct or even see my spelling misstakes .ds
__________________
Regards,
Nergal

--------------------------------------------------------------------------------
Last edited by nergal : 01-28-2006 at 09:12 AM. Reason: bad english