This is part 2 of Working with Visual Basic Binaries. In this tutorial we will be using VB Decompiler which is available in the download from part 1 of this tutorial. We will also be using MapConvert and OllyVBHelper- plugins for Olly, P32Dasm and some additional crackmes, all of which are available in the download of this tutorial on the tutorials

page.

.

Investigating CrackmeVB3

Let’s begin by loading the crackme into Olly:

Here, we see our typical call into the VB runtime. You have to admit, it’s pretty amazing (bonehead?) that we can write an entire executable in two lines of code!

Now, because we don’t know much about this binary, let’s investigate it. Running the target, we see that it has a nag set to a timer of 5 seconds:

We’ll definitely want to get rid of that! After 5 seconds we see the main serial screen:

and entering a wrong serial, the badboy is displayed:

Let’s take a look at the target’s guts, shall we? This time, instead of VB Decompiler, let’s use P32Dasm.

Using P32Dasm

P32Dasm is a native and P-code decompiler. It is very similar to VB Decompiler, though it does have some added benefits (like exporting MAP files that work).

Loading CrackmeVB3.exe into P32Dasm, we see the main screen, with some data about the target:


You should notice some similarities to VB Decompiler, especially the Form1.Command2.click. This is the callback to a clicking of a button. At the top are ASCII strings used in the target (obviously not obfuscated), and at the bottom we see several timer functions. At the top of the P32Dasm window are some toolbar buttons that you should be familiar with:

Clicking on “Strings”, we see something similar to the “Search For -> Strings” in Olly:

Though, unlike Olly, double clicking on one does not take you to the disassembly of that section of code.

Next is the Constants toolbar button, but clicking on this reveals that there aren’t any. Then we come to ‘Imports’, which is similar to “All intermodular calls” in Olly:

The _vbaStrCmp should stick out like a sore thumb…

Next is the Exports, but this target doesn’t have any, so it’s blank.

“Objects” should remind you of the VB Decompiler screen:

This shows all of the VB ‘objects’ in the target, such as buttons, labels and timers. We can plainly see that the “Check” button is called “Command1″, and we can assume that this is our main check button callback.

Last up is the “Procedures” window:

This shows us all of the callbacks in the target. We can see that our check button callback is called “Command1_Click”, as Command1 is the callback of our “Check” button.

One thing I wanted to point out is that very suspicious series of five’s in the strings section:

It couldn’t really be that simple, could it?

No, please tell me it isn’t:

Oh brother. Oh well, let’s continue to examine this crackme so we can see how using P32Dasm will help us in other ways (like removing that nag). One tool we have is map files…

Making a MAP File

A MAP file is a collection of names for procedure calls that have been compiled into the VB code. Remember, VB uses actual string names to reference callbacks, so we can extrapolate these and import them into Olly. We can do this in VB Decompiler Pro (File -> Save Procedure List) but since the pro version is not free, we can also use P32Dasm. Open the target in P32Dasm again and select “File” -> “Export to MAP file”. Save the MAP file and then load CrackmeVB3.exe in Olly. Let’s take a look at our main suspicious callback before loading the map file. I chose the address of the Command1_Click callback at 4055F4:

Loading the target in Olly and jumping to that address, we see where the Check button callback begins:

We will use the MAP converter plugin for Olly (included in the download) in order to bring in the MAP file we created in P32Dasm. Save the DLL for the MapConv plugin in the plugins directory for Olly and restart Olly (if you haven’t already). Load the target and select “Plugins” -> “MapConv” -> “Replace Comments”:

Select the MAP file we created in P32Dasm. This allows us to put the MAP file info in the comments column. You can also load them into the label column, though I personally find this harder to read. Now, when we look at the callback, we see that the callback information has been added to help us out:

As you can see, we now have a comment for our callback. Now right click and select “Search for” -> “All user-defined comments”:

Now we can see all the names of our callbacks!

Scrolling down in the Command1_Click callback, we can see the goodboy, badboy, and the obvious patch that needs to be made:


Now all that’s left is…

Removing the Nag

Looking back in P32Dasm, let’s take a look at the timer calls:

From this screen, we can see that Form2 is the nag screen (because it is the one calling the timers).

***You may wonder why we call a timer 6 times; this is because obviously the person who created this crackme did not know how to properly use timers, so they call a one second timer 6 times to mimic a six-second countdown. ***

We can also see from this screen that Form2.Command1_Click is the callback for clicking the OK button after the timer has expired. A very simple solution (though probably not the most elegant) is to simply override the first timer call and make it jump to the callback for the OK button being clicked. This means that when the first callback for the timer is called (meaning we just started the target and we are starting the first one-second timer), we will instead call the code that handles the clicking of the OK button after the timer has expired. This will in effect simply fool the program into calling the ‘close nag screen’ code instead of the ‘start first timer’ code.

Looking at the first timer callback code at address 405AC5:

Let’s just change the beginning to point directly to the code that handles the closing of the nag screen. From P32Dasm, we can see that this callback is at address 4059C2 (the Command1_Click callback code):

Now, let’s patch it:

Now, if you re-start the target, you will see the nag show up for just a quick second, then disappear. Like I said, not the most elegant, but this tutorial is not about “elegantly removing nags” :)

OllyVBHelper Plugin

Another helpful tool in the battle with Visual Basic is the OllyVBHelper plugin. The purpose of this plugin is to find and re-label natively compiled VB imports (DLLs). It also finds and renames DLL function call stubs. As an example, I loaded one of the crackmes in Olly (doesn’t matter which one) and chose “Search for” -> “All user labels”. Before running the plugin, his window is empty:

Now, running the plugin:

and we can see that we now have all of our method calls displayed, similar to if we imported a MAP file.

A nice little time-saver.

Using the ‘Point-H’ Technique

Point-H is a technique introduced by Ricardo Narvaja in his cracking tutorials (in Spanish). The ‘H’ stands for Hmemcopy, a very old Windows 95 API call. This call was run directly by the OS for copying ASCII strings, and could be used to find points of interest in cracking. The Point-H is a more modern way of achieving this.

In ntdll32.dll, there is an API that Windows calls when it wants to copy a string. This function is used often, from copying names of imported DLLs, to comparing Windows messages, to API functions like GetDlgItemTextA and SetDlgItemTextA. In the later case, we can use this API to trap when a username or password is initially copied from the window and returned to our program. For example, in our crackme there may be a section that, after clicking the “Sign in” button, our program get’s the entered password from the password field by calling GetDlgItemTextA. When we call this function, kernel32 calls it’s own internal API that copies this value from the window into a temporary variable. Kernel32 then returns this value to our program as a return value of GetDlgItemTextA.

If we know the location of this internal string copying API, we can pause at it, check what string is being copied, and if it is one we’re interested in (like a password) we can then follow execution until it returns back to our target program’s code and we will see where the target receives the password.

The Point-H location will be the same on my computer no matter which target I am running, but will be a different location from another computer’s address, therefore, when we find the address of Point-H on my system, you will have to substitute your own address on your system.

This method is especially useful on targets that are heavily obfuscated, encrypted, or just too hard to find the right code section to start with (like Visual Basic executables). It gives you at least a starting point to begin at…

I have included a crackme with the files of this tutorial called “Point-H Crackme.exe”. It is not a VB target, as we will just use this to find the actual address of this point-h API call.

Finding ‘Point-H’

First, I would suggest doing these steps with a clean install of Olly (just move the ‘plugins’ folder in the Olly install directory temporarily to your desktop) as I have had problems with certain plugins and false breaks in the past. Load the Point-H Crackme into Olly:

*** Make sure you are paused at 401000 and not at the raw entry to the file. If you are not paused at the real OEP (401000) try pressing F9 once- Olly should then pause at the real entry point. If that doesn’t work, just open the ‘Memory’ window (“Me” icon in the toolbar), highlight the Point-H Crackme ‘CODE’ section and hit enter. This will take you to the entry point of the actual binary. ***

Now right click in the diassembly window and select “Search for” -> “Name (label) in current modile”, or hit Ctrl-N. This will bring up the names window:

Toward the bottom will be the TranslateMessage API. Right-click on this and select “Conditional log breakpoint on import”:

This will bring up the conditional breakpoint screen:

Set up the screen as shown. We will use this conditional breakpoint to weed out all of the calls to translate message until we hit the message with the ID of 201. Looking at our old cheat sheet for Windows message IDs (provided in tutorial 16A), we see that this ID corresponds to the left mouse button down message. This is to trap the TranslateMessage function when processing the click of the “OK” button in the crackme.

When you click OK in the conditional breakpoint window, you should see the breakpoint in the ‘Breakpoints’ window:

You may notice that it says “Log” under the Active column, letting us know that this is in fact a log BP.

Go ahead and run the crackme. select “Edit” -> “Register”, and put in a name and serial. Make sure you use TAB to move among the fields or our left mouse click message will fire our breakpoint prematurely. I entered “R4ndom” for the name and “12121212″ for the serial:

Now click OK and Olly should break at our conditional breakpoint:

Now we want to search for our serial in memory. Open the Memory window by clicking the “Me” icon or typing Alt-M. Right-click in this window and choose “Search”:

In the ASCII field, enter 12121212:

Olly should show us where in memory our serial resides:

We want to tell Olly to pause when this memory address is accessed. Highlight the first byte of the serial and right-click on it. select “Breakpoint” -> “Memory, On access”:

Now hit F9 to run the target. Olly will then break on our memory breakpoint (you may break at our previous conditional BP first, in which case just hit F9 again):

This is the Point-H on your system. On mine, as we can see, it’s 774E23BE. Write this down. If you look in the registers window, you will see our serial in ESI:

Let’s now experiment a little with this magical breakpoint. Delete the log breakpoint as well as the memory BPs set earlier. Add a hardware BP on execute on the Point-H address (so it won’t be lost on a re-start) and restart the target. We should then break before we see the main crackme window:

And looking in the registers window, we see that the string we are copying is “OpenProcessToken”:

Hitting F9 repeatedly, you will see various strings in the ESI register, each time ntdll32 calls this internal API. Besides API names, you will see various number sequences flash by as well as other things- basically anything the ntdll32 copies as a string.

Using ‘Point-H’ to Crack the Target

Now, you may be asking yourself, “Great. I did all this work. What’s the point?” (pun intended :) ) Let’s try it out. Temporarily disable the BP on the Point-H address and re-start the target. Select “Register” again from the menu and enter a name and serial. Before hitting OK, set the BP on Point-H again, then click OK in the target.

*** If you need to find the address of Point-H to set the BP, open the memory window, click once on ntdll’s .text section (toward the bottom) and click Enter. This will bring up ntdll in the disassembly window. Now you can goto (Ctrl-G) the address of Point-H. ***

Olly breaks at our breakpoint, and looking in the registers window, we can see that this time through is with our username:

Hitting F9 again, we see that we are now at the copying of the serial:

Now for the magic. Open the memory window, right-click on our target’s CODE section and choose “Set break on access”. This way we will break as soon as ntdll32 returns to our target’s code. Hitting F9, Olly pauses in our code section:

As you can see, we paused right after a call to GetDlgItemTextA. Deep inside ntdll32, this function eventually called our code containing the Point-H address. It then returned to our target’s code at address 4012E9. We now have a starting point to try and crack this crackme. The crackme has just gotten the entered serial number, and will soon do something with it. Of course, because this crackme is not very hard, it’s not really that impressive, but in a commercial app, with encryption and protection routines, being able to zero in on this code is a life-saver.

In the case of this specific crackme, continuing to step through the code, and placing access breakpoints on the code section of the crackme, it doesn’t take long before we get to the relevant code for patching (I leave this up to you…).

Another Target Using Point-H

Let’s try another crackme using this technique. Load “CrackmeVB4.exe” into Olly. First, let’s find our Point-H address; open the Memory window, scroll to the bottom, and highlight whatever section your point-h address is in. For me, that would be address 774E23BE in ntdll.dll’s .text section:

Click Enter while this line is highlighted, which opens this module in the disassembler. Now, hit Ctrl-G and enter the address of the point-h on your system to make Olly jump to that location:

and we land at point-h:

Now, keeping this location available in the disassembly window (but without placing a breakpoint yet), and run the target. First, a nag comes up (for what seems like 3 hours), and then we see the main entry screen:

Enter a name and serial, as I’ve done here, and then set your breakpoint (F2) on the point-h in Olly, before clicking OK in the target. After setting the breakpoint, click OK in the target and Olly will break at our point-h:

As we can see in the registers window, this isn’t the stop we want to investigate, so click F9 again. You will need to press F9 a couple more times until a string comes up that we are interested in. In this case, the “You Get Wrong…” string looks pretty promising:

Now what we want to do is trap execution as soon as we get back to our target’s code. Because of the nature of Visual Basic, we can’t just set an access memory breakpoint on the code section of our target (as we would in a native application). So what we want to do is single step (over) until we get back to our target’s code. We will first go into user32.dll (setting the cursor etc) and back through the VB runtime. The badboy will be displayed, after which we will step quite a ways further, but eventually, we will land here:

Here we can clearly see that we are returning after a call to rtcMsgBox which displayed our badboy message window. Above this we see our badboy being created, and more importantly, above that we see our goodboy. Now, finding the patch (at address 408677) is extremely easy. Of course, in this specific crackme, using P32Dasm or VB Decompiler would have been far simpler, but when we run into a devilish VB target where these simple tricks won’t work, the Point-H method can be invaluable.

What About Smartcheck?

This may come as quite a shock to you, but I am not going over Smartcheck. This set of tutorials is meant as a *current* guide to reverse engineering. Because Numega’s Smartcheck is not compatible with operating systems beyond Windows Vista (though it is possible with a lot of work in compatibility modes, running in a virtual machine, installing old VB runtimes etc) I believe it shouldn’t be a part of a current reverser’s toolkit. I have shown how, using tools that work with all versions of Windows like VB Decompiler and P32Dasm, any target can be examined and cracked using just these tools. By all means, if you are using Windows XP and can get Smartcheck to work, it is a valuable tool and should be used. But until someone takes up the charge and makes Smartcheck compatible with newer operating systems, I feel it’s just too old to be relevant.

-Till next time

R4ndom