Registry Mechanic is the trusted industry leader and the world's most popular registry cleaner with more than 15 million downloads! I have found this tool to be both reliable and accurate at doing its job. This is a VB application that is packed / encrypted with Armadillo. The target runs as a single process Armadillo application with a form of code splicing (run time decryption of just in time routines). Since most of the notorious Armadillo debugging tricks are not used, this should be an easy lesson for novices. We are going to do something really interesting after we dump and fix our target. We are going to patch the ArmAccess.dll which is sometimes surreptiously copied to the C:\WINDOWS\system32 folder when some Armadillo based applications are installed. Not so here, so we include the ArmAccess.dll in the Tutorial package, if needed. In doing so, we will turn the Armadillo protection against itself and use it to allow our target to be registered and remove all restrictions / limitations. We are going to do the following:

1. Open the utility PEID and browse for our target to see the protection scheme used.
2. Load and run our target application in Ollydbg v1.10.
3. Dump our target application using LordPE.
4. Fix our Import table (add new IAT) using ImpRec.
5. Run our new upacked target and patch the Armadillo ArmAccess.dll to allow us to register our software.

Figure 1.

While PEID is not always accurate in determining the version of the protector, it gives us some indication of what we are up against. We can close PEID and move on to the really fun stuff. So let us begin.

Figure 2.

Please also note the following plugin which will allow us to hide our debugger from the protection:

Figure 3.

We are now ready to open and load our target into Ollydbg. You will be at the EP of the packer / encryptor code here:

Figure 4.

Before you start to run the target, you may be asking yourself, where's the bleeping OEP? Well since this target utilizes none of the debugging tricks for which Armadillo is known for we can skip most of the usual stuff and set a BP on CreateThread as follows using the command line plugin:

Figure 5.

Run (F9) the target in Olly. We will break here:

Figure 6.

Note: Your dll address above may be different dependent on your OS and version!! Keep that in mind.

Now do the following:

Ctrl+F9 to the end of the function (address: 7C81084E).
F7 step into the RETN at address: 7C81084E.

You should now be here:

Figure 7.

We are now in the Virtual ArmAccess.dll code that resides in memory. Special Note: The memory location of the ArmAccess code may be different on your computer. This is dependent on your OS and version.

F8 step over the code until you reach the RETN at address: 00391104 above.

F7 step into this RETN. You should now be here:

Figure 8.

This is the classic last step in tracing through Armadillo code to reach our OEP. Scroll down the code page until you see the following code and set a BP on the highlighted address in red, below:

Figure 9.

The BP on address: 003ABF62 will CALL the program's OEP.

Run F9 our target to the BP above. The code pane will show the following:

EDI=00401364 (RegMech.00401364), ASCII "hl @"

So, 00401364 is our OEP.

Step into (F7) the CALL above (our BP) and we should be here:

Figure 10.
 

The code you see above is Classic VB (Visual Basic). The version is denoted by the DLL name MSVBVM60, so this is a VB 6.0 application. Since we are at the OEP we can now dump the application using LordPE or similar.

DO NOT CLOSE OLLY AT THIS POINT!!

Figure 11.

Find our process in LordPE and do the following:

Figure 12.

Note: We are performing a full dump of the target, so go ahead and select dump full as shown above and save the file. (i.e. dumped.exe).

Using LordPE, we will now open our dumped/saved file (i.e. dumped.exe) using PE Editor and make the following changes to EntryPoint and BaseOfCode as shown below:

Figure 13.

The new EntryPoint is our OEP from Olly address 00401364 - the program's base address: 00400000. The new BaseOfCode is simply the number of bytes to skip (our Header Section) to where the new code section begins. Save our changes and we can now exit LordPE.

Remember, We still have our target open in Olly.

Open and run ImpRec and look for and select our process as shown below:

Figure 14.

Make sure you have Create New IAT selected in your Options as shown below:

Figure 15.

Change our OEP in ImpRec as shown below and Select IAT AutoSearch:

Figure 16.

You will get the following confirmation messagebox:

Figure 17.

Press OK.

Press Get Imports. You will see the following:

Figure 18.

Note: There is only 1 invalid (unresolved pointer). In general, there is only 1 import that we need to concern ourselves with in VB apps protected by Armadillo. The missing import is vbaEnd as we shall see.

Press Show Invalid. You will see the following:

Figure 19.

Double click on the highlighted invalid entry. You will get the Import Editor dialog as shown below:

Figure 20.

Select Function vbaEnd as shown above and press OK. You will get the Congratulations message as shown below:

Figure 21.

Select Fix Dump and open your unpacked dumped exe and Save with the default name: dumped_.exe.

The log window will show you the results below:

Figure 22.

We can now close ImpRec.

It is not unusual for many Armadillo applications to ship with the ArmAccess.dll. You will normally find this in your C:\WINDOWS\system32 directory, but on some operating systems this may be different. If you don't have this dll in your system32 directory or anywhere else, you can use the provided ArmAccess.dll from this package. Please copy the ArmAccess.dll to your target's directory in the same location as your new unpacked exe. Why you ask are we doing this? As the theory goes, the packed / protected target makes calls to the virtual ArmAccess.dll in memory. This code could be loaded in many different places in virtual memory. Hard to control and fix. The dumped target bypasses this virtual code and instead, relies on loading and calling the external ArmAccess.dll to handle specific functions. In this case, verifying / installing a key for the registry process. This, we can control. Read on....

Open your new target in Ollydbg and let Olly analyze the program.

Run your new target to you get to the main menu screen as shown below:

Figure 23.

Note that this application is not registered as indicated by the register now button in the top right hand corner of the screen. Click on the register now button and enter the information below: (note: you can also enter any License Name and License Code of your choosing). DO NOT PRESS the Register button just yet!!

Things are going to get really interesting...

Figure 24.

You are still in Olly. Go to Olly's [Memory Map] "M" toolbar button and find the ArmAccess.dll in memory as shown below:

Figure 25.

Note: The location in memory on your machine may be different!!

Right click on the .text section and select Set memory breakpoint on access as shown above.

Go back to the register now dialog in our target and press the Register Now button. You should land here in the ArmAccess.dll code:

Figure 26.

Note: The memory address on your machine may be different, but the code should still be the same. Step into the CALL at address: 027B1358. We are in the "InstallKey" function within Armadillo as noted by the information in register EAX as shown below:

Figure 27.

We should land here after stepping into the CALL:

Figure 28.

Keep pressing F8 to step over the code. You should take the JE instruction at address: 027B1266 and land here:

Figure 29.

Continue to press F8 to step over the code until you reach the code at address: 027B1349 above. Make the following change to the code as shown below:

Figure 30.

At this point, Olly is paused. Remove the memory breakpoint.

VERY IMPORTANT. We want to save the change in the code, above, to be our new ArmAccess.dll. So do the following. Right click on the line of code we changed and select Copy to executable > Selection as shown below:

Figure 31.

You will get an intermediate dialog screen. Just click the red X in the top right corner. You should get the following screen:

Figure 32.

Press Yes. Save the new file as ex: ArmAccess_new.DLL.

We can now remove the memory breakpoint we set earlier, so do that now.

Now press F9 to run our target. You should see the following dialog MessageBox:

Figure 33.

Press OK. Notice that the top right of our screen has changed to the following:

Figure 34.

Press the Help button and select About. You should see the following:

Figure 35.

Hooray, we are registered, or are we? Well the short answer is yes, for the moment, but as soon as we end our session and exit the application, we will be unregistered again.

We have one more step to do.

Close the target and exit Ollydbg.

Go into the Window's directory for our target, find and rename the original ArmAcces.dll to ex: ArmAccess_old.dll or you can simply delete it. Now, rename our new patched Armadillo dll ex: ArmAccess_new.dll to the original name ex: ArmAccess.dll.

Run your new target (without the debugger attached). Congratulations! You are the registered owner. You will need to keep the new ArmAccess.dll in your program's directory to remain registered!!

A COUPLE OF POINTS:

1. "Smart Update" will not work with the new unpacked / fixed target application due to CRC limitation and/or other possible reasons which we don't delve into right now.

2. The virtual Armadillo code that is processed for the Verify / Install key functions in the normal packed / encrypted target is different than our new unpacked / fixed target which uses the external ArmAccess.dll. You could, patch "On the fly" the following code in memory to accomplish the patch we made to the external dll and get the same result, albeit, only active for the session, when running the original target. After your BP on CreateThread, when you entered into the Armadillo code (noted above in this Tutorial) you could find the code below:

Figure 36.

And patch the code at address: 0039B399 (or the address on your machine) to the following:

Figure 37.

And be registered for the duration of your session.

3. Set a HWBP on WORD write for address [00933168]. The application moves 'FFFF' to this address when you are registered.

In the final analysis, it is up to you, the Reverse Engineer, to decide which method is best for you.

This Tutorial is for "Educational Purposes" Only.

Thanks to the [ARTEAM]

[Nilrem] [MaDMAn_H3rCuL3s] [Shub - Nigurrath] [ThunderPwr] [Kruger]
[Gabri3l] [Teerayoot] [R@dier] [Eggi] [EJ12N] [Stickman 373] [Cl0ud]
[Potassium] [Deroko] [Nacho_dj] [Anorganix] [Sigint33] [JohnWho]

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.