Log in

View Full Version : ActiveMa** unpacking

agnonymous
October 18th, 2004, 12:11
Hi all,
This is my first post but i've been a reader of this forum for some time now. I'm grateful to this forum because just one year ago I did not know anything about unpacking, now I think it's one of my hobbies ...
we, manual unpackers have a nice advantage: the packer-cryptor programmer is fighting his natural tendency for order and structure (as a computer programmer), so the most complex protections still have order in them, and that is also the weak point we must look for
Anyway...my first post is about activema**.

I've been fighting this beast for a few days now but i can tell you there's nothing impressive about it. I've had a few successful unpackings so far.
basically:
- find OEP
- dump
- fix imports
the packer replaces some of the calls call ds:[API] (6 bytes) with a nop; call proc (the call proc takes only 5 bytes, hence the nop)

so patching the dump is needed. Why I did is opening the partly fixed dump in disassembler, find out all the suspicious calls (nop followed by a call), see what API they eventually call and patch them back to a call ds:[API]
I believe IDA pro + a IDC script would be a very nice solution

At the moment I'm working on static unpacking to avoid api tracing which is too time consuming for me. If someone is working on the same thing I would be interested to share ideas.

manual unpacker
nathan
October 19th, 2004, 02:03
Did you actually dumped from OEP (e.g., by using Olly) or directly with some PEtool ?

nathan
agnonymous
October 19th, 2004, 05:39
Quote:
[Originally Posted by nathan]Did you actually dumped from OEP (e.g., by using Olly) or directly with some PEtool ?

nathan


dumped at OEP. The only tools I use are ollydbg(load/trace target up to OEP) LordPE (dump) and imprec.
R3v3nG3
October 19th, 2004, 06:00
Hi,
I'm working on the same target and I noticed that there are other commands changed by the packer. Not only

CALL xxx--> NOP CALL yyy

but also

MOV reg, xxx--> NOP MOV reg, yyy

and others. Search for NOP in the dump for a full list.
Hope this help.
Bye,
R3v3nG3
nikolatesla20
October 19th, 2004, 06:40
Unpacking this and patching all the jumps is really, a non-worthwhile task ( A WASTE OF TIME).

You see, ActiveM*** uses 2 layers. The first layer is the unpacking and decrypting. The second layer is the code replace that you are seeing.

The first layer is finished as soon as you see the nice HTML box come up telling you to register the program.

LunarDust came up with a very creative technique against ActiveM***.

So, to quote from LunarDust:

Quote:

Got some apps that are version 5.2

Activemark stores time limits in the registry keys and data files mentioned before, but also has a nice trick for NTFS systems, it stores one last copy in the EXE itself, in a NTFS file stream (AFS). You can use a stream viewer to see it, and if you use FileMon you will see the process accessing itself with a filestream moniker with a GUID for its name (xxx.exe:{XXXX-XXXX-XX-XXXXXXXX}).

Imports are easy to recover.

Finding OEP. You don't want OEP of original program, since then you'll have to fix all the ripped code (pain). Instead, Activemark has 3 layers: Compressor, License manager, Original program.

Dump the program when it reaches second layer. YOu know this by just BPX on GetVersion. Second layer uses GetVersion API. Use second layer OEP as entry point of dumped proggie.

More notes:

Quote:


ActiveMark

TO find program's OEP (the actual real program):

1. dump the program from mem while it's on the HTML splash screen.
2. open the dump in a hex editor
3. look for the text "TdnAVp"
4. Select 0xC bytes (including this text). the DWORD that follows is the original OEP RVA.

However, this info does you no "good" in unpacking the latest, such as Pixelus game.

What you need to do here is:

Use ImpREC to recover the big import table, paste it on the dump.

Disasm with IDA, look for references to GetVersion. YOu will find the "Second layer" of
protection starts with the traditional GetVersion call. This is the OEP of the second
layer. You need to dump at this OEP and start the program from this OEP. That way
any Import API redirects that exists in the real program code (the protector overwrites
many CALL [XXXXXXXX] imports with a NOP, CALL XXXXXXXX to its own code), these redirects
will be in place if you use the original code.

So use SoftICE to bpmb on the OEP of the second layer. It won't work with Break 'n Enter,
the program will detect it. Just start the program and then a few seconds later, CNTRL+D
into SI and set the breakpoint. When you get there do a "a eip, jmp eip, enter" to
freeze the program, leave SI, and dump it with LordPE. Remember to go back and fix your
infinite loop now.

Now paste the imports on this file and you will have a working program. Howerver, it exits.
It detects it's not the original program.

Here's the workaround. On the new 5.2 activmark it exits with ExitProcess. Use Olly to
BPX on ExitProcess to find the call. Find out where ExitProcess gets called, and right
above it, where the value of exiting gets PUSHED, change the instructions to JMP to the
OEP of the REAL PROGRAM. Reason this works is everything is in place now to allow the
real program to run, it just has to be called. So we do this with brute force by just
jumping to it.

You can add the JMP in Olly and then "Copy to executable file->Selection" to save out
the changes (much faster than using hex editor).


OH AND YEAH, this version of ActiveMark uses the same time limit registry and file entries,
but on NTFS systems it adds a new twist: It stores additional data in a file stream (one
of those NTFS hidden file streams) in the original EXE. to get rid of it, simply copy the
file to a FAT32 partition and back again. Or use a stream editor tool to delete it.



Enjoy.

-Lunar_Dust




I love that last part :P Just force the program to run, it's on your hard drive for goodness sakes.

-nt20
agnonymous
October 19th, 2004, 08:43
I have seen previous attempts at this protection but my goal was different. My goal was to restore the original exe as it was before the protection, not to crack some protected app (reset time limits, etc)

Usually I stop reading tutorials as soon as I see "press F8" or "search for byte sequence 12 45 65 12 ab 1c" because the approach is too specific and there must be a better and more generic way

Anyway, you don't need to patch every location where there is a [nop; call sub_123456] or [nop; mov RegX, sub_123456; call RegX]

you can simply patch at sub_123456 to make it jump to the API it is supposed to jump to. whichever way the target is using to call this sub_123456, it will always jump to the API. Of course this will not produce an exact copy of the original exe (before packing) but it will run perfectly

makes sense?
R3v3nG3
October 21st, 2004, 10:48
Hi all,
I packed w1nhelp32.exe with ActiveMa** 5.3 and I successfully unpacked it without problem(I followed LunarDust instructions).
After, I tried to unpack a game from Trym3dia with the same method but I get a Visual C++ Runtime Library error at startup.
Any ideas?
Thanks,
R3v3nG3
dELTA
October 21st, 2004, 15:36
Custom protection underneath the packing layer?
R3v3nG3
October 25th, 2004, 02:50
You're right!

Thanks,
R3v3nG3
R3v3nG3
October 27th, 2004, 02:56
No, I was wrong! I'm sure that the error depends from the packer, but it's not an antidebug trick.
My initial target was Scr4b*** and yesterday I found another release of the same game unprotected and well?
I saw 3 files in the installation dir with same names but different sizes. The TryM3dia ones were littler than the other, so I tried to use the larger ones with the exe unpacked by me and it worked!
The conclusion is that the unpacking method, works for the exe but ActiveM4rk packs also some other files and then probably the method is not enough against this feauture.
You can have a proof of that, opening the file with the .fun extension in an hexeditor, you will see it starts with "TMSAMVOH" and you can find this string 3 times inside the unpacked exe too.

I'm going to analyse a bit more....

Bye,
R3v3nG3
condzero
March 3rd, 2005, 08:40
R3v3nG3,

You are 100% correct in your findings regarding the packing of resources as you describe. It's easy to discover in any hex editor. Unfortunately, I have seen noone publish anything that can unpack the resources. To do this, you would have to get your hands on their custom dll and exploit the necessary routines.

Good Luck
Hero
March 3rd, 2005, 09:11
Hi all
Can you tell me the PEid Generic OEP finder,finds OEP for layer 2 or 1?

sincerely yours