Unpacking ActiveMark
5.x Advanced
by: CONDZERO Visit: http://cracking.accessroot.com | http://forum.accessroot.com |
| Information | ActiveMARK is a digital distribution services and DRM technology suite. |
| Target | Rapala Pro Fishing |
| Available | Rapala Pro Fishing |
| Tools | OllyDbg 1.10 , ImportREConstructor V1.6 FINAL, LordPE, Hide Debugger 1.2, Regshot v1.7 |
| Protection | ActiveMARK[TM] R5.4.1171 |
| Level | ADVANCED |
| Category | UNPACKING / PATCHING / LOADER |
| Author(s) | CONDZERO - AUGUST 2005 |
| Requirements | Best viewed in Firefox at 1280x1024 |
Introduction |
Please see the References Section at the bottom of this Tutorial for more information. This tutorial will concentrate on dumping and fixing the target application, which is more universal in nature. The dump / fix approach described here is not deemed a 100% solution. Using a loader, however, and the methodology provided here is virtually 100% guaranteed to work. We will concentrate more on the counter measures and methods necessary to make the target run and less on the dumping / import reconstruction process which was extensively covered in Part I. |
Protection |
ActiveMARK utilizes a blend of packing / encrypting the original exe. It incorporates anti-debugging tricks (curiously is the absence of the ubiquitous “ISDEBUGGERPRESENT” API, but instead copious use of INT3 instructions), VERY obfuscated code, what they call “Asymmetric Code Blending” which virtually negates the usefulness of unpacking and dumping a target at it’s real OEP, to impede the disassembly and modification of it’s code. This is naturally all designed to frustrate all, but the most die-hard Reverser with a bit of time on their hands. The good news is that rebuilding imports is greatly simplified with this approach. |
Goal |
|
Assumptions |
Basic understanding of debugging, the tools referenced above and the knowledge obtained from Tutorial Basic Part 1. This Tutorial is aimed at the novice reverse engineering student with a modicum of intelligence and understanding. |
Declarations |
After considerable testing, there are many variables that can alter your course of action. I will list and discuss each. 1. The Basic Method of unpacking / fixing a target doesn't work. Now what do I do? Answer: Continue with this tutorial. 2. My application has expired. Now what do I do? Answer: Continue with this Tutorial. 3. My application doesn’t work. Now what do I do? Answer: Did you read, understand and follow the instructions in this Tutorial carefully? Make sure the target was dumped properly, that you corrected the PE for the new EP, that your imports (IAT) were added correctly, and that your new patches were applied correctly. If IMPREC generates a large number of Invalid Thunk(s), there may be issues with application DLL’s loading from different libraries / directories that weren’t loaded from the process. If after investigating, the app still doesn’t work, then the problem may lie with the application itself. When dealing with app’s that are configured to work with ActiveMARK, there are numerous issues to contend with. Did the app originate on CD. In some cases, ActiveMARK fudges the registry for the path to your files. You may see something like “cdpath” or “datapath” with strange references. Does the app use the “Macromedia Flash Projector”? This can possibly cause problems with creation and accessing your temp directory for Macromedia’s files. Does the app have it’s own specialized resources, helper dll’s, etc. Did the app generate an exception message? Expect the unexpected. There may be instances where ActiveMARK imbeds an INT3 instruction in the middle of a procedure. Naturally, the program will complain about this. Solution: NOP the INT3 instruction. Note: This exception wasn’t generated when the same program was run with a loader. Ultimately, it may come down to using a loader as your only option. There are (2) loaders provided as attachments. A standard loader and a debug loader. See the section on Loader vs Unpack / Fix for more information. 4. I notice that some of the indicators (status conditions) that we are patching (modifying) in section 4 have the correct values we are looking for already. Why make the change?
Answer: Due to any number of variables, unpack/fix vs using a loader, business rules used in the target, interfaces, etc.
there may be what appears to be "unnecessary" changes. While
the changes aren't required in those instances, we bring them to your
attention, as a general rule, in cases where patching may become
necessary. Many
ideas proposed here are simple, but effective workarounds to get past
many different problems that can occur. |
1. Dumping |
The first thing we are going to do is fire up OllyDbg. Notice that we take all exceptions offered by Olly below:
Figure 1. We are opening up Olly with no target at this point. We are readying it to attach to our target. Note: A suggestion was made in a forum post to Tutorial – Basic (Part I) that PeID could be used to find the 2nd layer’s EP by using the generic OEP finder. You are welcome to try that approach here. Next we will fire up our target application and let it run to the familiar “Browser” Interface screen (which we will not show here). Note: Whether the TRIAL has expired or not is of no concern with one caveat. You will have to take on faith some of what you read here as a result of not being able to press the “Start Free Trial” link on the Browser screen and see the corresponding result in the program. The “Browser Window” displays the usual 60 minute time limitation along with options to play the free trial or buy the full version. Note: the limitations imposed by the application are a direct result of the business rules used by the software vendor and are subject to change. --- Back to Olly, go to the FILE menu, find our process and select attach, see below:
Figure 2. We will select Process (PID) 7D4, above, and attach. Note: Your PID may be different. Using what you learned in Part I, we will find the instruction in code where to place our Hardware Breakpoint on Execution (HWBPE). We will once again navigate to the 2nd layer EP section of interest in Olly (highlighted below):
Figure 3. Section .bss in memory block 00E44000 for a size of 0016E000, highlighted above, is the area of interest to us. Note: this section also includes the virtual ActiveMARK dll embedded in code. Jump to this section now, we are looking for the following line of code (highlighted below):
Figure 4. Set a HWBPE for line 00F8E577 above. So go ahead and select this line, then using context help, do the following (shown below):
Figure 5. We can now close Olly (Don’t Exit) which will also close the target application (if you attached). We will now Open our target in Olly. We will make one additional change to the debugging options in Olly BEFORE we run the target. We will select the “Break on new module (DLL) checkbox (see below): Note: this step may not be mandatory for some situations!!
Figure 6. The reason we choose to do this is to slow the target down, while it runs, and avoid ActiveMARK detecting our debugger and forcing the process to terminate prematurely. The hardware breakpoint would never materialize. Why?? There are any number of reasons. Hardware (intel processor…) Software (WinXP vs Win9X), Executing Ring 0 (system code) vs (Ring 3) application code) Instruction alignment and what’s called RTDSC (Real Time Stamp Counter ) instruction, but not completely sure. You’re machine may be different. What is known is that ActiveMARK, in the later releases, has made strides in circumventing (read: bypassing) Breakpoints in memory and on access. So press OK on debugging options and F9 to run our target. You may encounter exceptions along the way. Simply shift + F9 to get past them. We will eventually land at our Hardware Breakpoint as seen below in Olly’s status bar:
Figure 7. We are now ready to dump the process. DO NOT CLOSE OLLY. Use whatever tool you are comfortable with to dump the process. I have chosen to use LordPE. Below are the options I generally use in LordPE for ActiveMARK:
Figure 8. Find and dump your process as described in Tutorial Part I Basic. After dumping, we will select the dumped.exe, again using LordPE or similar, and change the Entry Point and Base of Code. This will facilitate making changes (patches) in Olly later as well as updating the executable for the new EP. Since the original exe’s image base is at 00400000 we make the following calculations: New EP = 00F8E577 – 400000 = 00B8E577. Also, using the memory block mapping in Olly, we will change the Base of Code = 00E44000 – 400000 = 00A44000. (see changes below):
Figure 9. I have chosen, this time, not to wipe the last few sections of the exe, but you can do so. Save and exit. |
2. Rebuilding Imports |
|
Fortunately, this is one of the easier steps. Since we are rebuilding based on dumping at the 2nd layer EP and not the real OEP, we can do the following: Using Imprec, find your process as demonstrated in Tutorial –Part I Basic. Remember, we still have our session of Olly open with our target. After selecting the process (program), change the OEP to the new EP 00B8E577. Go ahead and press IAT AutoSearch. You will get something similar to following:
Figure 10. Press OK. Press Get Imports. Generally, all, but the last THUNK are valid. Go ahead and select the last Thunk (if shown as valid: NO) using context help, and select Delete Thunk(s). Note: if you find many invalid Thunk(s) with an application, check the log in IMPREC to see if all DLL’s were loaded from the process. Press Fix Dump, in Imprec, referencing the name of the dumped.exe target that you saved earlier using LordPE. You may get the following message (see below):
Figure 11. I have purposely left the dumped exe intact without wiping any sections so you can see what can happen when trying to add a new IAT. So go back to LordPE or similar and wipe the last section from the dumped file (if you haven’t done so) and save. Try “Fix Dump” again in ImpRec and you should get a message back stating that the dumped file was saved successfully with the new IAT section added (see below):
Figure 12. We can now exit Imprec.
|
3. Why an Application May Not Work Using The Basic Method |
|
Figure 13. Note: Not all applications will be so generous and generate an error message or even better generate a log file. Some may just show a blank, dark screen and nothing else. In this case, you’ll either need to make certain assumptions, based on what you learn here and from experience, or set BP’s in your code and analyze further. Fortunately, this application is nice enough to provide a debug.log file. Find this file in your application’s \bin directory and look closely. You will see the following:
Figure 14. The last line of the snapshot above is of particular interest. Find the offending file DATA.ARC in your program’s directory and open with a hex editor and you will see the following:
Figure 15. Look at the text portion above on the right pane. You see “TMSAMVOH”, which I presume might mean Trymedia Software/system ActiveMARK volume header. You will see TMSAMVOF if you scroll all the way to the bottom of the file. This file is packed / encrypted. ActiveMARK has built-in functions for encrypting / decrypting resources. When the application runs normally, it will KNOW to decrypt resources, because this is a business rule that customers can select as part of their package solution. So, some applications make use of this functionality, others don’t. For those that are interested, I present a snippet of code taken from our target. You may want to apply all the changes (patches) in this Tutorial before placing a BP on the first line of code you see below. Note: there are many interesting things you will see as you step through the code. This routine CAN be performed many times depending on the application. I believe this to be a function used in encrypting / decrypting data (resources) and the *.exe itself. Pay particular attention to the green line highlighted below: 00F6060A . 55 PUSH EBP 00F6060B . 8BEC MOV EBP,ESP 00F6060D . 83EC 34 SUB ESP,34 00F60610 . 56 PUSH ESI 00F60611 . 8BF1 MOV ESI,ECX 00F60613 . 57 PUSH EDI 00F60614 . 8D8E 1C190000 LEA ECX,DWORD PTR DS:[ESI+191C] 00F6061A . E8 891B0000 CALL Rapalx.00F621A8 00F6061F . 8B46 04 MOV EAX,DWORD PTR DS:[ESI+4] 00F60622 . 83F8 01 CMP EAX,1 00F60625 . 75 07 JNZ SHORT Rapalx.00F6062E 00F60627 . B9 044FE400 MOV ECX,Rapalx.00E44F04 ; ASCII "rb" 00F6062C . EB 0E JMP SHORT Rapalx.00F6063C 00F6062E > 83F8 06 CMP EAX,6 00F60631 . 0F85 9B000000 JNZ Rapalx.00F606D2 00F60637 . B9 708EE400 MOV ECX,Rapalx.00E48E70 ; ASCII "wb" 00F6063C > 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] 00F6063F . 33FF XOR EDI,EDI 00F60641 . 8B40 04 MOV EAX,DWORD PTR DS:[EAX+4] 00F60644 . 3BC7 CMP EAX,EDI 00F60646 . 75 05 JNZ SHORT Rapalx.00F6064D 00F60648 . B8 147BEA00 MOV EAX,Rapalx.00EA7B14 00F6064D > 51 PUSH ECX 00F6064E . 50 PUSH EAX 00F6064F . E8 B4F00200 CALL Rapalx.00F8F708 00F60654 . 59 POP ECX 00F60655 . 3BC7 CMP EAX,EDI 00F60657 . 59 POP ECX 00F60658 . 8986 18190000 MOV DWORD PTR DS:[ESI+1918],EAX 00F6065E . 75 1E JNZ SHORT Rapalx.00F6067E 00F60660 . 6A 07 PUSH 7 00F60662 . 57 PUSH EDI 00F60663 . 68 F0ADFA00 PUSH Rapalx.00FAADF0 00F60668 . 8D4D CC LEA ECX,DWORD PTR SS:[EBP-34] 00F6066B . E8 C0FBFFFF CALL Rapalx.00F60230 00F60670 . 8D45 CC LEA EAX,DWORD PTR SS:[EBP-34] 00F60673 . 68 E08AFA00 PUSH Rapalx.00FA8AE0 ; /Arg2 = 00FA8AE0 00F60678 . 50 PUSH EAX ; |Arg1 00F60679 . E8 E7E30200 CALL Rapalx.00F8EA65 ; \Rapalx.00F8EA65 00F6067E > F646 04 04 TEST BYTE PTR DS:[ESI+4],4 00F60682 . 74 25 JE SHORT Rapalx.00F606A9 00F60684 . 57 PUSH EDI ; /Arg4 00F60685 . 6A 08 PUSH 8 ; |Arg3 = 00000008 00F60687 . 68 C0B2EA00 PUSH Rapalx.00EAB2C0 ; |Arg2 = 00EAB2C0 ASCII "TMSAMVOH" 00F6068C . 50 PUSH EAX ; |Arg1 00F6068D . 89BE 10190000 MOV DWORD PTR DS:[ESI+1910],EDI ; | 00F60693 . 89BE 14190000 MOV DWORD PTR DS:[ESI+1914],EDI ; | 00F60699 . E8 DC390000 CALL Rapalx.00F6407A ; \Rapalx.00F6407A 00F6069E . 83C4 10 ADD ESP,10 00F606A1 . B0 01 MOV AL,1 00F606A3 > 5F POP EDI 00F606A4 . 5E POP ESI 00F606A5 . C9 LEAVE 00F606A6 . C2 0800 RETN 8 If we look at the pane window in Olly’s code section, we will eventually see the following when we reach the green highlighted code above:
Figure 16. I am sure that if you examined the target further with the aid of IDA, or similar tool, and examine the call chains in your debugger and perhaps set BP’s to trace into this routine, you will uncover a lot of information, including the magic jump that eludes you if you were to use ONLY method 1 Basic. We won’t have to concern ourselves with this mystery, but it is there for those who wish to explore. So what happened!? If we bypass the usual initialization steps that take place during normal processing, packed / encrypted resource(s) will never be resolved producing error message(s) and /or the application will not respond.
|
4.
Preparing the Target |
|
At this point, you may want to open the ORIGINAL exe, click on “Start Free Trial” link, and let it run to the Main Menu. Select “Options”. Scroll to and Select “Video”. Select “Windowed – ON”. This will help in running and analyzing the target using your debugger. |
5.
Patching the New Target - Section 1 |
|
Note: This section is not necessary if you use a loader. The main goal of this section is to have our new target read the ORIGINAL exe into memory and not fail the CRC and any other memory location checks and tasks. Reopen our new target application in Olly. Let Olly analyze the target if it has not already done so. We should be at our 2nd layer EP (Address 00F8E577). We can now search for our intermodular calls using the context menu (see below):
Figure 17. Sort the “Found Intermodular Calls” results window. We are going to set BreakPoints on every call for the following:
Figure 18. And...
Figure 19. And just for fun...
Figure 20. Go back to the main CPU window and Run (F9) the target. It will break here 1ST time:
Figure 21. The stack window (lower right) will show the following:
Figure 22. If we run (F9) again we reach a BP on a Readfile where it reads the PE Header. Run (F9) again and it does another readfile. Run (F9) again and we reach the following BP:
Figure 23. I have purposely scrolled up a few lines. We are going to make our first patch here. But first, take note of the stack window below:
Figure 24. If you named the target application as described previously, you see the full path to the target. Next take note of the Registers (FPU) pane below:
Figure 25. Notice the ASCII value referenced in the EBX register. Right click (context menu) the EBX register like below:
Figure 26. Go to the dump pane and scroll down just a bit to see the following:
Figure 27. What we are attempting to do is change the ASCII value ‘x’ (highlighted above) to a value ‘a’ (using code) so that our target exe reads as …\Rapala.exe in memory. We will make the following calculation. Our offset patch = [EBX + (003E5172 – 003E5129)] = [EBX + 49]. If you press the space bar now we could do the following:
Figure 28. Change the ‘x’ to ‘a’ as shown above on the ASCII line. The Hex line results in a value of ‘61’. This is the value we want represented in memory when this function executes. We will now make all necessary code changes. In the code pane, make the following change as shown below:
Figure 29. We are going to jump to our cave at the end of this section and add some code. Follow the jump above and you should land here.
Figure 30. A whole bunch of zeroes to write our code. We will make the following changes:
Figure 31. Note: this API is called more than once. We check and make sure our change only occurs once in the memory location. Notice we replaced the code above we stole preceding the API and jump back to continue. Your patches should be saved automatically by Olly. You can check this out by clicking the greenish-blue italic “I” button in Olly’s toolbar. We can copy and save our patches to an executable file later. Note: After applying the patches and running the target, note the activity that flows through your BP on CreateFileA. You will see the target app look for the existence of a license file *.lcn. The app will then do a SetStatus based on licensed / not licensed. If not licensed, the app will search for the existence of the (4) registry keys and Trymedia data files used for saving the Trial time left. The app will then determine if you have any remaining time and set the appropriate options and generate and display the respective Browser Window.
|
6.
Patching the New Target - Section
2 |
This section will concentrate on bypassing all nag screens, i.e. the "Browser" Window, which is generated when the application first starts up, and later on after the application exits, you are presented once again with a "Reminder" Window or "Expiration" Window. There is a very comprehensive Windows creation and message processing logic built into creating the HTML, java enabled Browser splash screens that ActiveMARK generates for most applications. The solution that follows may be the best approach. Note: If you can live with the annoyance of a nag screen, then proceed to Section III. If we were to restart our application and enable (apply) the patches from Section I, we would be presented with the “Browser” window. If we go into Olly and set BP’s on all Calls to PostMessageA shown below:
Figure 32. And DestroyWindow...
Figure 33. Restart the target and click on the “Start Free Trial” link on the Browser screen, we would eventually land here:
Figure 34. The Stack pane would show the following:
Figure 35. MSG(B039) is what’s generated (associated) if we click the “Start Free Trial” link on the Browser screen. Run (F9) the target again and we land here:
Figure 36. We could force this process sooner in code and the program’s message processing loop would destroy the window for us. But there is a better way! Find the code below in Olly:
Figure 37. This code (functionality) is integrated with the Window (Browser) creation process in ActiveMARK. If you were to set a BP on the first line highlighted above, you would see this procedure called. We are going to bypass this procedure, which will eliminate the generation of any Browser windows. Make the following change as shown below:
Figure 38. This simple jump will take us to the end of the routine, thus bypassing the main logic. We are done with this section. |
7.
Patching the New Target - Section
3 |
This section shows how ActiveMARK records our Trial Time usage within an application and how we can bypass it. The following code snippet is for INFORMATIONAL purposes only!! We are not changing any code here!! For this target, the SETTIMER API is visible in Olly’s “Found Intermodular Calls” window. This is not always the case due to obfuscated code and how Olly's analyzer perceives it. Also, for obvious reasons, the procedure that contains this API and it’s counterpart CreateWindowExA for the “Fake Window” that anchors it, are buried in obfuscated code and not easily detected. I present the procedural code below (taken from ANOTHER PROGRAM using an earlier version of ActiveMARK) so you can see the full routine below: 005431D3 /. 55 PUSH EBP 005431D4 |. 8BEC MOV EBP,ESP 005431D6 |. 83EC 34 SUB ESP,34 005431D9 |. A1 B82E5900 MOV EAX,DWORD PTR DS:[592EB8] 005431DE |. 53 PUSH EBX 005431DF |. 56 PUSH ESI 005431E0 |. 57 PUSH EDI 005431E1 |. 33FF XOR EDI,EDI 005431E3 |. 8BF1 MOV ESI,ECX 005431E5 |. 3BC7 CMP EAX,EDI 005431E7 |. 75 51 JNZ SHORT dumped_.0054323A 005431E9 |. 57 PUSH EDI ; /lParam => NULL 005431EA |. 57 PUSH EDI ; |/pModule => NULL 005431EB |. FF15 C8915900 CALL DWORD PTR DS:[5991C8] ; |\GetModuleHandleA 005431F1 |. 50 PUSH EAX ; |hInst 005431F2 |. 57 PUSH EDI ; |hMenu => NULL 005431F3 |. B8 00000080 MOV EAX,80000000 ; | 005431F8 |. 57 PUSH EDI ; |hParent => NULL 005431F9 |. 50 PUSH EAX ; |Height => 80000000 (-2147483648.) 005431FA |. 50 PUSH EAX ; |Width => 80000000 (-2147483648.) 005431FB |. 50 PUSH EAX ; |Y => 80000000 (-2147483648.) 005431FC |. 50 PUSH EAX ; |X => 80000000 (-2147483648.) 005431FD |. 68 0000CF00 PUSH 0CF0000 ; |Style = WS_OVERLAPPED|WS_MINIMIZEBOX|WS_MAXIMIZEBOX|WS_SYSMENU|WS_THICKFRAME|WS_CAPTION 00543202 |. 68 080A4700 PUSH dumped_.00470A08 ; |WindowName = "FakeWindow" 00543207 |. 68 000A4700 PUSH dumped_.00470A00 ; |Class = "STATIC" 0054320C |. 57 PUSH EDI ; |ExtStyle => 0 0054320D |. FF15 A0995900 CALL DWORD PTR DS:[5999A0] ; \CreateWindowExA 00543213 |. 3BC7 CMP EAX,EDI 00543215 |. A3 B82E5900 MOV DWORD PTR DS:[592EB8],EAX 0054321A |. 75 1E JNZ SHORT dumped_.0054323A 0054321C |. 6A 01 PUSH 1 0054321E |. 57 PUSH EDI 0054321F |. 68 80285900 PUSH dumped_.00592880 00543224 |. 8D4D CC LEA ECX,DWORD PTR SS:[EBP-34] 00543227 |. E8 5F000000 CALL dumped_.0054328B 0054322C |. 8D45 CC LEA EAX,DWORD PTR SS:[EBP-34] 0054322F |. 68 70045900 PUSH dumped_.00590470 ; /Arg2 = 00590470 00543234 |. 50 PUSH EAX ; |Arg1 00543235 |. E8 10670300 CALL dumped_.0057994A ; \dumped_.0057994A 0054323A |> 8B5D 08 MOV EBX,DWORD PTR SS:[EBP+8] 0054323D |. 68 B0315400 PUSH dumped_.005431B0 ; /Timerproc = dumped_.005431B0 00543242 |. 8BCB MOV ECX,EBX ; | 00543244 |. 69C9 E8030000 IMUL ECX,ECX,3E8 ; | 0054324A |. 51 PUSH ECX ; |Timeout 0054324B |. 56 PUSH ESI ; |TimerID 0054324C |. 50 PUSH EAX ; |hWnd 0054324D |. FF15 B49A5900 CALL DWORD PTR DS:[599AB4] ; \SetTimer 00543253 |. 85C0 TEST EAX,EAX 00543255 |. 75 1E JNZ SHORT dumped_.00543275 00543257 |. 6A 01 PUSH 1 00543259 |. 57 PUSH EDI 0054325A |. 68 80285900 PUSH dumped_.00592880 0054325F |. 8D4D CC LEA ECX,DWORD PTR SS:[EBP-34] 00543262 |. E8 24000000 CALL dumped_.0054328B 00543267 |. 8D45 CC LEA EAX,DWORD PTR SS:[EBP-34] 0054326A |. 68 70045900 PUSH dumped_.00590470 ; /Arg2 = 00590470 0054326F |. 50 PUSH EAX ; |Arg1 00543270 |. E8 D5660300 CALL dumped_.0057994A ; \dumped_.0057994A 00543275 |> 8B45 0C MOV EAX,DWORD PTR SS:[EBP+C] 00543278 |. 895E 04 MOV DWORD PTR DS:[ESI+4],EBX 0054327B |. 8946 0C MOV DWORD PTR DS:[ESI+C],EAX 0054327E |. 8B45 10 MOV EAX,DWORD PTR SS:[EBP+10] 00543281 |. 8946 08 MOV DWORD PTR DS:[ESI+8],EAX 00543284 |. 5F POP EDI 00543285 |. 5E POP ESI 00543286 |. 5B POP EBX 00543287 |. C9 LEAVE 00543288 \. C2 0C00 RETN 0C --- Back to our target. Note: You can set a BP on SetTimer as shown below to see the following upon reaching our BP:
Figure 39. The stack pane shows the following values:
Figure 40. Notice anything special about the timeout value above? Converted = 60 seconds. The Timerproc referenced above Calls a KillTimer routine which will reset our SetTimer proc to launch again, also our registry keys and data files will be read for possible expiration, then updated with a new time (+ 1 minute). We will make the following change to bypass this functionality in its entirety. Find the following code in Olly:
Figure 41. You will notice that it looks fairly identical to the previous code for "browser". It's also very near the same code section!! We make the same identical type change as seen below to bypass this functionality:
Figure 42. That's it. We are done. No more Timer. While we are in this code section, we will make another change that will disable the "time out" feature. You know, the one that tells you your application has expired and now you must buy it. Find the code below in Olly:
Figure 43. Are you starting to see a pattern here. We will make the following change to bypass the "timeout" expiration routine as seen below:
Figure 44. We are done!! No more timeout. Please note that not all programs are "Time Limited" trials. Some are "Execution" based (i.e. number of uses). In order to deal with these programs we can do the following. Find the code below in Olly:
Figure 45. Every time you run a program, ActiveMARK tracks the number of executions (uses) whether the program uses this limitation or not, it is still there. We can make the following patch below to bypass this functionality:
Figure 46. We are done!!. Finally, there is one more area of interest that is not totally clear, but is integrated with the Browser functionality. The "dialog" routine is probably most responsible for the communication layer between ActiveMark (the program) and its localized reference to your computer: amlocalhost (amlocalhost.com) which is your http://127.0.0.1 and also the Trymedia Servers it communications with if you were to buy or reactivate the program. We can bypass (disable) this routine as well since we don't need it. Find the following code in Olly:
Figure 47. Make the following change to bypass this routine:
Figure 48. We are done with this section. Please observe your changes and we will continue.
|
8.
Time Limitations |
This section provides a brief overview on the repository used for Trial protection. In our previous Tutorial Part I Basic we introduced a tool, Regshot, which can take a before and after snapshot of your registry and, optionally, every file on a designated drive. If you don’t have this utility, you can get it here: http://www.majorgeeks.com/download965.html . There are other similar tools available. You can use Regmon, etc. Note: Running the program normally, ActiveMARK will detect Regmon so you’ll need to hide it. We can also find the registry keys by doing the following. Open your target in Olly and set BP’s on every call to RegDeleteKeyExA as shown below:
Figure 49. Run (F9) the target. We eventually land on the following BP:
Figure 50. The stack pane shows the following:
Figure 51. This is one of the (4) main registry keys. Note: ActiveMARK registry and data file keys are unique to the machine. On your machine, this key will be different. The registry keys may not be in ascending order as you cycle through them in your debugger. The registry keys ALL have one thing in common, the subkey “Implemented Categories”. If you were to run ‘Regedit’ and look for your respective key, you would find many subkeys. ActiveMARK apparently clones an existing key in your registry, then appends any additional encrypted subkeys for its own purposes used in storing date/time/usage information. Repeat the above procedure and you will eventually find the (4) MAIN registry keys. Another idea suggested is to use a conditional log BP. You can do the following:
Figure 52. Enter the following or similar in the popup window:
Figure 53. Note: The value for ESP was taken from the register (FPU) Pane on a BP. Make sure to select the radio buttons for log value, log function arguments, optionally, Pause program (Never). You can view the log later using Olly’s menu “View” and select “log” to see the results. Note: You should find the (4) main registry keys. As described in Tutorial Part 1 Basic, you can find the Trymedia data directory in either of (2) places depending on your machine and the version of ActiveMARK: 1. C:\Documents and Settings\All Users\Application Data\Trymedia 2. C:\Program Files\TryMedia\ActiveMark You can also find the encrypted data files (keys) by setting a BP (from Section 1) on CreateFileA and looking at the path info.
|
9.
Patching the New Target - Section
4 |
1. Your Trial application has expired and you want to reset the Trial / error status for the duration of this execution. With the changes noted above, this indicator is no longer important, but you can change it if you want. Note: The code below may be difficult to find in actual practice. Your easiest method is your own experience and by doing a conditional breakpoint for the code below on the value: EAX==00000001 (BAD) which is the value if the application has expired. See BP below:
Figure 54. Make the following patch (in red) below:
Figure 55. New value of AL will be ‘00’ (GOOD). Note: this code may be executed any number of times depending on the program. The patch above can be applied even if the application has not expired. 2. My program may or may not be expired, I am sick and tired of those damn ActiveMARK keys and data files. This change is not required, but may give you peace of mind. Also, to maximize your viewing pleasure, you may wish to delete all your old keys and files before running with this patch. We can bypass the routine (procedure) that creates / encrypts the registry and data file keys resulting in ONLY ONE REGISTRY KEY and NO DATA FILES!! Find the code below:
Figure 56. The code above is relatively easy to find by doing a “search for”, then “sequence of commands” using Olly’s context menu. We will make the following change to bypass the relevant code of this procedure. See below:
Figure 57. Note: We are simply jumping to the end of the procedure (address highlighted below):
Figure 58. If we were to make the change above, the application MIGHT possibly abort and display the “Internal Error” Window and ultimately exit. So we may need to apply the following change. Find the code below and set a BP as shown:
Figure 59. Note: Once again, the code above may be difficult to find in real practice. Basically we look for the instruction above (There could be many) with the (condition) EAX register having a value = ‘00000000’ (BAD). You can use the conditional BP for finding and determining this code. We change the code as follows:
Figure 60. EAX = ‘00000001’ (GOOD). A final status indicator is set upon completion of the registry and data keys processing. The following code is obfuscated so we can either step into it (you can set a BP as I have done) or go directly to the expression (address) shown below:
Figure 61. The value of the low order byte of the EBX register, BL, should be equal to '01'. If not, we can change the first line above as follows:
Figure 62. We come back to the following condition again as noted in Figure 59 above. The value in EAX should remain as '00000001' after the instruction on line 00F44162 executes below:
Figure 63. And here's what your final registry key will look like after you're done:
Figure 64. We are done!! We can apply all of our changes using Olly's context menu to copy the patches to an executable as shown below:
Figure 65. Repeat the above for all our changes. When you 'X' out of the "File" Window below (small 'x' on toolbar):
Figure 66. Olly will prompt you to "Save" the File (see below):
Figure 67. Press the "Yes" button and give the file a new name (i.e. Rapalx_new.exe or similar). After saving the new file, we can rename our original unpacked file "Rapalx.exe" to "Rapalx_bkup.exe" and rename the new saved file with our patches back to "Rapalx.exe". Run the new target without your debugger (Olly, etc.) and it should run. Congratulations!
|
11.
LOADER
vs UNPACK / FIX |
| This choice is dependent on your ultimate success in unpacking and fixing an application and / or your own personal preferences. When using a loader keep in mind that your patches MUST be applied prior to the normal application's "Browser" Window displaying. For this reason the (2) attached loaders are designed for this purpose. 1. The Standard Loader utilizes a timing loop to wait for the target to unpack itself and find the relevant code, then apply the patches and exit. This method may be crude, but it is effective. 2. The Debug Loader is more precise in waiting for an event to occur, then applying the patches and depending on your OS, detach from the process and exit. This loader also has built-in code for hiding the debugger and avoiding INT3 tricks. Both Loaders (standard and debug) are configured to work (hopefully) with any OS. Both have been tested on WinXP machines successfully.
|
12.
Conclusion |
| Using the
methodology as described in this Tutorial, targets that are unpacked and
fixed or run via a loader are all designed to run on ANY machine and as
such are transferable. With each new release of ActiveMARK we can expect to find some changes. A major new release, Version 6.0 is in Beta and soon to be released. Macrovision® has announced that it is acquiring Trymedia® Systems. This will obviously have some impact on future releases of ActiveMARK. So until then, have fun! |
Greetingz |
|
Disclaimer |
This TUTORIAL is for EDUCATIONAL PURPOSES ONLY. For NO REASON, will ARTEAM or any of its members be held liable for the use, misuse and dissemination of the materials and knowledge contained in this Tutorial or any subsequent SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES RESULTING FROM same. |
References |
|
1. stdloader.txt - (attachment) Example standard loader template file written in C. 2. dbgloader.txt - (attachment) Example debug loader template file written in C. 3. Patching of Packed/Protected files...(Writing a Loader) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ by R!SC -- April 1999 -- risc@notme.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ with assembler source similar to item 1 above. LINK: http://wasm.ru//forum/files/24732259__loader.txt Note: You can also Google this article and find elsewhere!! 4. Excellent Tutorial on Loader Theory from the [ARTEAM]: Cracking With Loaders Theory General Approach And A Framework V12 By Shub-nigurrath Thunderpwr
|