|
ARTeam Tutorial Visit:
http://forum.accessroot.com ActiveMARK Process Dumper (AMDUMPER) |
| Information | ActiveMARK Process Dumper (AMDUMPER) |
| Target | Inca Quest |
| Available | Inca Quest |
| Tools | OllyDbg 1.10, ImpRec, LordPE, Hide Debugger 1.3 |
| Protection | ActiveMARK |
| level | Beginner |
| Category | Unpacking , Dumping, Patching |
| Author(s) | CondZero May 2006 |
| Requirements | Windows XP, IE 5.5 and above for best viewing |
|
1. Introduction
|
|
This Tutorial will introduce a new tool (AMdumper) designed to automate the tasks involved in the process of dumping most ActiveMARK applications. The scope of this Tutorial will explain the tool, what its capabilities are and more importantly, discuss how to patch the so-called "Magic Call". Some of you may find the enclosed sources helpful in creating your own simple dialog box to open a file and do some processing on it. Also, the customized "About" box with an embedded hyperlink control and how to do it may be interesting. The Features: 1. Find the 2nd layer EP 2. Find the AMCLIENT_VERSION of ActiveMARK for the application (Reference purposes only). The Magic Call: 3. Discussed later in this Tutorial The tool utilizes a fairly simple dialogbox and its usage is fairly straightforward. Simply open your target by pressing the "Open ActiveMARK protected target" pushbutton and the program will load and run the program via CreateProcess in debug mode, hooking the GetVersion API in order to find the 2nd layer EP. Since we are running a process using a debugger, we also need to hide the process from ActiveMARK by utilizing a hide debugger routine. When you are finished dumping and have fixed the imports, you can press the OK button and the application (and your target) will exit. The program sets a BP (breakpoint) on the GetVersion API 6 bytes into the function in order that ActiveMARK doesn't detect the BP. Once we reach our desired 2nd layer EP, the program is in a suspended state due to our BP, and can then perform a search routine to find which version of ("AMCLIENT_VERSION") ActiveMARK is protecting the target. Once completed, the program displays a MessageBox indicating the results. At this point, DO NOT CLOSE THE DIALOG!! Dump the process using LordPE, or similar. Fix the imports using ImpRec. Append the encrypted data to the end of your newly fixed dump (After the IAT - as per the Lunar_Dust overlay method), fix the "Magic Call" (discussed later) and you are done!! Pictures: Figure 1 - The dialog box (before) Figure 2 - The results MessageBox (after) |
Figure 1.
Figure 2.
|
2. Find the 2nd layer
EP
|
|
The program initially sets a BP during the CreateProcess
Event (case CREATE_PROCESS_DEBUG_EVENT:). We save the
program's base load address during this event. The
process continues to the 1st BP (System Breakpoint) in
module NTDLL.DLL. Here, the program injects code to hide
the debugger (AMdumper) from ActiveMARK. Once reaching
the program's initial EP, a new BP is set on the
GetVersion API 6 bytes into the function in order that
ActiveMARK doesn't detect it. See Figure 3 below where
the BP would be set in the GetVersion API. Figure 4
displays Ollydbg code window where BP would occur. It is important to note that each time a BP is encountered (case EXCEPTION_BREAKPOINT:) the program restores the original byte in the process using the sequence: 1. GetThreadContext 2. WriteProcessMemory 3. SetThreadContext This is important as it not only allows the program to continue debugging, but also allows for viewing the data in the thread context, namely the register values. When the condition: COMPARE CONTEXT.ESP+4 (VALUE) == CONTEXT.EDI is met, the program reads the stack address: CONTEXT.ESP for the value in memory. The program then subtracts 44 bytes (hex 2C) from this value to determine the target's true 2nd layer EP (i.e. PUSH EBP). Since basically ALL V.5X versions of ActiveMARK have a basic structure, this methodology works. |
Figure 3.
Figure 4.
|
3. Find the AMCLIENT_VERSION
|
| Since finding the literal value "AMCLIENT_VERSION" in the process is a relatively straightforward exercise (see figure 5 below), we simply search for a binary string containing these bytes (figure 6 below) noting, that we must reverse the byte order to actually find them. Also note, that when the program searches backwards (regressively), the order of the dwords is important (figure 7 below). Note, we only use the 1st 8 bytes to search as this is all that is necessary. Also note that the actual version text (of ActiveMARK) appears just below the variable "AMCLIENT_VERSION" (figure 5 below) so the program can make this determination when searching for the actual text. Then its a simple matter of moving this text to a buffer to display later. |
Figure 5.
Figure 6.
Figure 7.
|
4. Find the Magic
Call
|
|
Perhaps some of you have heard the phrase, Find the
Magic Call, NOP it, and the application will run with no
time limitations, etc. Well, this is true. By NOP'ing
this call, the application doesn't invoke the standard
check license, setkey, setaction, etc. functions, so in
effect, the program happily runs on as if you were fully
licensed. But note, patching this call seems to only
work on "Try and Buy" applications and not "Buy Only"
applications. One other important note. Very Important. If you NOP the magic call in a debugger and run the program (F9), you may experience some undesirable results in your target due to the debugger's influence on the application. Make the change, save it, and run your new dumped app without the debugger!! We can find this CALL by using (2) different strategies. They are presented in the order of preference: 1. Find the command (highlighted) in Figure 8 below for your application using Ollydbg or similar. Note that this command almost always appears surrounded by mangled (obfuscated) code. You can set a BP on this address as I have done. Then simply step into (F7 if using Olly) the CALL command (which will be the very 1st CALL command (highlighted) you come to (Figure 9) below, again, surrounded by obfuscated code. Then simply make the change noted in Figure 10 below, NOP'ing this CALL. Copy your changes to the executable by right clicking for context as shown in Figure 11 below and save your changes. |
Figure 8.
Figure 9.
Figure 10.
Figure 11.
| 2. An alternate way to find the Magic Call is to search for the Ascii literal "SetKey" as shown in Figure 12 below. Then do a Find Command (Context help right click mouse) as shown in Figure 13 for the literal address from Figure 12. We are brought to Figure 14 where a BP is set on the actual command (highlighted). Run the target (F9) to this BP and look at the stack window. Figure 15 shows the top of the stack. Scroll down a bit until you come to something that looks like Figure 16. Right click (context help) on the address just above the FULLPATHNAME to the target as shown in Figure 17 to follow this address in the disassembler. Figure 18 shows our return address with the Magic Call just above it. This is the same call as noted in Figure 9 and the patch made in Figure 10 above. |
Figure 12.
Figure 13.
Figure 14.
Figure 15.
Figure 16.
Figure 17.
Figure 18.
|
5. Conclusion
|
|
Lesson Learnt 1. A simple dumper can be made by hooking GetVersion API to obtain 2nd layer EP 2. We can determine the version of ActiveMARK protection relatively easy. 3. The Magic Call is fairly easy to find and once patched, the application thinks it's FULLY licensed. So the procedure goes as follows: 1. Run AMDUMPER to dump your process. 2. Run LordPE (or similar) to dump your process to disk. 3. Run ImpRec to fix your imports (IAT). 4. Close the AMDUMPER dialog (press OK). 5. Append the encrypted data from the original target to your newly dumped file using the Lunar_Dust Overlay method. 6. Patch the Magic Call. 7. Enjoy your application!! |
|
6. Greetingz
|
|
Thanks to the [ARTEAM] [Nilrem]
[MaDMAn_H3rCuL3s] [Shub - Nigurrath] [ThunderPwr]
[Kruger] Thanks to all the people who take time
to write tutorials.
|