1. Targets that utilize the Macromedia Flash Projector (Shockwave).

2. Targets that have encrypted resources.

3. Targets that originated on CD Rom or DVD (as is the case with this target).

Also, this latest version of ActiveMark utilizes some additional anti-debugging techniques to thwart reverse engineering. You will need to do a couple things here.

1. Hide Ollydbg or your debugger of choice from process memory so that ActiveMark cannot see it. There are threads in the forum.accessroot.com board that address this issue. There is also a Tutorial there as well There are also different flavors of Ollydbg circulating which have this capability built-in.

2. Use the hide debugger plug-in referenced at the top of this Tutorial. This plug-in can be obtained by searching the Ollydbg forum or forum.accessroot.com.

The debugging options used in Olly will look like below:

Figure 1.

We will also do one more thing with the Events tab and select Break on new module (DLL) as shown below:

Figure 2.

This step will allow for us to set a HWBPE (Hardware Break Point on Execution) that will not be bypassed by the anti-debugging protection of ActiveMark.

Note: I will use PEID to find the generic OEP (Entry point) of the second layer (license layer). We fire up PEID, browse for our executable and then select the bottom -> arrow Plugins > Generic OEP Finder and select with the left mouse button as shown below:

Figure 3.

PEID is kind enough to return the following messagebox:

Figure 4.

So we close this messagebox (press OK) and close PEID making sure we took note of the EP address: 006DB737 because we will set our HWBPE on this address in Olly.

In Olly, go to the [Memory map] window as shown below:

Figure 5.

Yes there are a lot of sections, but we're only interested in the highlighted section above which contains the protector's license layer and protection scheme. The code is very obfuscated once we get there. For now we will select the highlighted layer (right click) and dump as follows:

Figure 6.

And do the following (note: the code is all '0's at this point) Select Breakpoint and Hardware, on execution for just the one byte EP address: 006DB737 in our dump shown below:

Figure 7.

Okay. We are now ready to Run (F9) our target in Olly. You should be here at the program's EP:

Figure 8.

As we continue to press F9 (Run) we can view the DLL modules being loaded in Olly's [Executable Modules] window. Right after module WS2_32.DLL is loaded we break on our HWBPE shown below:

Figure 9.

This code looks better than before. We are at our 2nd layer EP.

From my previous advanced Tutorial, I showed you how to dump and fix the IAT.

Don't close our target in Olly!!

Open LordPE or similar now and note the options below:

Figure 10.

These options are relatively basic and allow for us to do a full dump of our target. Find the running process in LordPE as shown below:

Figure 11.

Right click on the main module ....\fear.exe in the bottom pane and select dump full as shown below:

Figure 12.

Take the default name dumped.exe and save the dumped file to your target program's directory. We now need to edit our newly dumped file for the new EP and BaseOfCode sections. Remember that our new Entry Point is the result of calculating the new 2nd layer EP - the Base Module's load address which can all be obtained from Olly. The result is: 006DB737 - 00400000 = 002DB737. The new BaseOfCode is simply the start memory address of our new EP section. The result is: 005940000 - 00400000 = 001940000.

To do this we can press the PE Editor button and open our newly dumped file and make the changes as shown below:

Figure 13.

Press Save and we are done with LordPE.

Keeping our target open in Olly, but not yet running the target, we are now ready to open ImportREC. Find our process in ImportREC as shown below:

Figure 14.

Note: The process ID (PID 00000E34) above may be different on your machine. Select the process and ImportREC will find and load all the associated modules it can find in our halted process. The log window will show the results. We now need to change the OEP to our 2nd layer EP as shown below:

Figure 15.

Press IAT AutoSearch. We get the following confirmation dialog box:

Figure 16.

Good it found something. Press OK and ImportREC will update the RVA and Size text boxes with the new IAT information. From previous experience, I have found it to be a good practice to increase the Size value because sometimes, ImportREC will not correctly calculate this value due to 00000000 dword blocks (gaps) in the import memory block. So what I do is add a fudge factor to compensate for any missed imports. In this case, I am changing the Size value from 9A8 to FFF. This new size is much larger, but I am reasonably sure it will take care of any missing gaps. Make the change in the Size TextBox to FFF and Press Get Imports as shown below:

Figure 17.

We are presented with both a lot of valid and invalid Thunks of data in the Imported Functions Found window. No problem here. Simply select the Show Invalid button as shown below:

Figure 18.

A bunch of highlighted Thunks are displayed. We can simply right click on a highlighted area as shown below and press Cut thunk(s) (NOT Delete) for all the invalid Thunks:

Figure 19.

ImportREC records our progress with a congratulatory message as follows in the log window:

Figure 20.

We can now press Fix Dump and select our unpacked file "dumped.exe" and save it with the default name which registers as "dumped_.exe". We are done with ImportREC.

We return back to Olly. We need to close the original target.

We can now rename our newly dumped and fixed file to something like "FEAX.exe" as this name will allow us to make a one byte change to point back to the original filename "FEAR.exe" which we shall see later.

Open our new dumped and fixed file "FEAX.exe" now in Olly. Be sure to let Olly Analyze our target before we begin analyzing and modifying the target. Also, we can remove the HWBPE we set earlier.

There are 5 sections (routines) of interest that we want to modify and a TEST AL,AL condition which we also want to modify which is related to an expiry condition check.

The areas of interest are presented in the order of code addresses in the target:

1. Bypass the Browser Functionality - We don't want to see the Nag window

2. Bypass the Dialog Functionality - We don't care about any communications with Trymedia's servers

3. Bypass the Timeout Functionality - We don't want the application to Time Out after the Trial limit is reached.

4. Bypass the Timer Functionality - During the course of running the application, we don't want the timer running which updates the Trymedia data files (usually) every minute until the Time Out limit is reached.

5. Bypass the Execute Functionality - For applications that use the number of executions, we don't want this incremented for each use.

6. The last condition, expiry condition check, will be noted at the bottom of this section.

Step 1. Bypass Browser Functionality

We know in advance which routines we need to modify. If you successfully unpacked and fixed the target and open it now you should land at the 2nd layer EP address: 006DB737 as shown below:

Figure 21.

Hopefully, you renamed your unpacked target similar to FEAX.exe or similar (I'll explain why later). Also, hopefully you changed the Base of Code to address: 00194000 so we can properly analyze the code, see all referenced text strings and save our BP's in the desired section. We can now open (right click) in Olly's code window and do the following:

Figure 22.

In the Enter text to search for dialog box enter the following:

Figure 23.

Press OK. Continue to press Ctrl + L (next search) until you land here:

Figure 24.

Note: Double click the highlighted line above and we land here:

Figure 25.

I have purposely scrolled up a few lines to the top of this routine at address: 0060289A. This is where we will make our first change. Set a BP on line address: 0060289A and now we will scroll to the bottom of this routine to the following line highlighted below:

Figure 26.

Okay. The end of our routine at the red highlighted address: 0060294F is a RETN 4 instruction. Take note of this instruction and scroll back to our first line in the routine and make the following change:

BEFORE:

Figure 27.

AFTER:

Figure 28.

The purpose of this change is quite simple. We don't wish to execute any portion of this routine, but simply return back to the caller with the proper number of return bytes. The effect will be that we simply return without doing anything. In this case, we will bypass the browser dialog which presents to us the Nag (Trial) Browser Continue screen.

For Steps 2 thru 5, I will present the lines of code containing the ASCII strings referenced in the routines that need to be bypassed using the same approach outlined above. Simply change the 1st line in the routine to the proper RETN XX value based on the last RETN in the routine.

Most Important: Keep Track (write down) your changes in Notepad or elsewhere so you can retain for your loader!!

Step 2. Bypass Dialog Function:

Figure 29.

Step 3. Bypass Timeout Function:

Figure 30.

Step 4. Bypass Timer Function:

Figure 31.

Step 5. Bypass Execute Function:

Figure 32.

The last step and perhaps most important, is to find and modify the check expiry condition which is usually a simple TEST AL,AL instruction. The best way to find this check is to set a BP on RegOpenKeyExA. Right click in Olly's code window and do the following:

Figure 33.

You can presort the [Found intermodular calls] window by pressing the destination tab at the top. Then select all occurrences of RegOpenKeyExA as shown below:

Figure 34.

We also need to perform one more step so our target doesn't exit prematurely due to a bad CRC check. We need to set a BP on GetFullPathNameA as shown below:

Figure 35.

Okay. We can now Run (F9) our target in Olly. Continue to press F9 to run our target skipping any BP's until we land on this:

Figure 36.

The stack window shows the following (if your exe is named FEAX.exe):

Figure 37.

The trick here is to right click on the stack window for the first line above. Do the following:

Figure 38.

We want to follow the FileName in the dump window so we can make the following change which will make our application think it is reading the correct (original) version of itself and not our unpacked / fixed version. Select Binary > Edit in our dump as shown below:

Figure 39.

We are going to edit (change) the ASCII "X" value in memory back to the original byte "R" as in FEAR.exe. Note: if your exe is named differently, then make any required change in memory to point the FileName to its original value FEAR.exe. We change the ASCII "X" to "R" as shown below in the Edit data dialog:

Figure 40.

Note: The address specified in the above dialog box maybe different on your machine, but the concept of changing the memory address containing FileName in the dump window will be the same. Press OK. Press F9 to run our target. Continue running our target until we reach the following BP:

Figure 41.

This BP represents the 1st registry key of a total of 4 main registry keys that ActiveMark uses to record our trial usage. The stack window should look as follows:

Figure 42.

Note: The registry key on your machine may look different, but the information should look similar to the above. If not, then you are not at the right BP. We need to run our target and stop at this BP 3 more times. On the fourth time we land on this BP, we need to right click on the code window and do the following:

Figure 43.

Select Search for > All commands and press the left mouse button to continue. In the Find all commands dialog box enter the command TEST al,al as shown below and press Find:

Figure 44.

You will get back a whole bunch of found commands for TEST al,al. Right click on the 1st one and select Set log breakpoint on every command as shown below:

Figure 45.

Enter the Condition EAX==00000001 and check the On condition radio buttons as shown below and Press OK:

Figure 46.

All found commands should be highlighted as shown below to indicate a conditional log BP:

Figure 47.

Due to the obfuscated code of our target, Olly cannot always find all commands that may be present. You may see something similar to the following where a command is not picked up like address: 00686247 below:

Figure 48.

If you were to double click address line 00686247 and be taken to Olly's code window you would see this:

Figure 49.

However, if you were to scroll up just one line of code, you would see the following:

Figure 50.

Quite a big difference. You need to keep this in mind when looking for commands in obfuscated code.

Back to Olly's code window, we can now run F9 our target. You will eventually, if not the first time, land at this conditional BP:

Figure 51.

This is the BP we are searching for. Besides the value of register EAX==00000001, there is one other indication we are at the right one. The stack window will usually show the following:

Figure 52.

The Return from ReleaseMutex is a reliable indicator that we are at the right TEST al,al condition. We can also prove this point by purposely expiring our target. We need now make the following change to the code highlighted in Figure 51 above:

Figure 53.

This simple change will restore our Trial usage back to the original limits each and every time we execute our target. Why is this important? ActiveMark records our usage every time we launch the application and when we exit the application, even with our previous changes, we still need this one change.

We press F9 to continue running our target and eventually land at this BP which we have modified the code:

Figure 54.

We can prove the success of our previous change for XOR al,al by looking at Olly's stack window. We will see a html like confirmation that our target hasn't expired:

Figure 55.

Note: ..../open.html?........ above. If we were expired, this message would say ...../expiration.html?.... or similar.

Hopefully up to this point, you have been keeping track of all your changes because Olly isn't doing so. We are ready to code our simple loader.

I have borrowed some of the logic to this simple loader (special greetz to Magic_h2001) because of its simplicity and is clever and perfect for our purposes. The loader should run on any machine. No debug or special api's are used. The amount of code is relatively small and written in C using native API's for ease of conversion to another language if necessary. I have ignored some conditions, namely file size (version) of the target. You should know what you are doing. It is anticipated that you will run the loader from the same directory as the target, so no path information is included.

At the top of our loader source is our main function, declared data variables and memory specific addresses and memory patch arrays for our target as seen below:

Figure 56.

Notice a couple things. The AddressOfCheck refers to our 2nd layer EP address. This is a PUSH EBP instruction with a hex equivalent of 0x55. The AddressOfPatch array refers to the addresses we noted earlier where we are modifying memory. So to is the corresponding replbyte array which contains each byte of memory we are going to change TO. The scanbyte array is for informational purposes and contains the original bytes. The entries of each array are important because they are ordered (synchronized) so that we may execute a simple for loop to make the required changes varying integer i.

The next section of our loader pertains to initializing some memory and launching the Target via the CreateProcess api in Create_Suspended mode. This allows for a simple while loop which checks process memory to see if we have  our 2nd layer EP code byte (0x55) in memory. If no, we continue the cycle of suspending the thread, reading process memory and resuming the thread. If yes, we suspend the thread, apply the memory changes to the process with a simple for loop which processes each entry in our arrays, resume the thread, then close our handles and exit. See below:

Figure 57.

The last part of our loader is the main entry point. Here we simply execute the function using the name of our target as a parameter:

Figure 58.

As I stated, very simple. Perhaps not very elegant, but nonetheless, effective. For more info on Magic_h2001 and some of his work with loaders, you can go to the following post on ExeTools forum:

EXETOOLS FORUM - ByPassing AsProtect with Simple Loader

In particular would be problems related to: ...for bypassing RDTSC check on low speed systems u can use a High-Precision ( High-resolution) Timer for calling ReadProccessMemory Loop.

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.