ActiveM***
 

Hi,

there has been some detailed tutorial on security Activ*Mark?Read I everything from of this board - from RCE board,and from Woodmann - but always me it doesn't go - programme all the time crash ,though repare import OK .
Progress from LunarDust too I know a.
Something on version 5.3 and higher - thanks.

It's good you read tutorials but you have to know that many times you have to put some effort on your part and use the debugger to guess where and why an unpacked application is crashing.

If you give here your steps that you have taken to unpack that application, I'm sure that some "ActiveMark unpacker people" here can direct you ;)

Cheers

1) start progg.and dump with PETools(or LordPe)
2) find OEP in dumped.exe (PEiD - detect)
2) launch ImpRec on running progg.
3) find IAT
3) Fix dump Dumped.exe -> Dumped_.exe

EDIT:
OEP second layer?????,,
Each write his search otherwise - by TRW and Softice - I I have Xp so that TRW no-use - examine it in Olly - but I don't know how find OEP for the second layer

Unpacking ActiveMark following the steps you said, requires to dump the prog and set the EP of the dump, to the packer second layer's EP.
Are you sure you did it?

I trying to learn how to unpack ActiveMArk myself.For finding OEP,I using PEid
Generic OEP finder,Is there anybody who know this OEP is for layer 2 or not?

In addition:I you want to test your algorithm,you can use downloaded yahoo games,
For example Cubic2 is uses activemark and its only 8-9 MB.

sincerely yours

It's very long time since I played with ActiveMark and I don't remember exactly which is the EP found by PEiD. However if I remember well you can find the 2 EPs opening the UNPACKED file with an hexeditor and searching one of this strings: "?AV_com_error@@" or "TdnA" without quotes (they must be near each other) and right after them there must be 2 recognizable addresses (DWORD).
The first is the second layer EP and the second is the OEP. You need the first, compare it with the one from PEiD.
Hope this helps.

According to to me PEID - find OEP for the first layer.(maybe) :rolleyes:
But how find OEP for second layer - in each tutorials which I have them it otherwise and malfunction nothing.......
This is for DUMPED file!!!
(for example - search in hex editor string "TdnAVp" or".?AV_com_error@@"and at 24h - this is RVA for OEP......)
(for example2 - search in hex editor string "TdnAVp" and patch before JE to JNE..........)
..........and .......... big nothing - AV...Could it anybody point out concrete instance??(I don't care on what)
tHx

Well, I took my old target (protected with ActiveMark 5.3) and gave it a look. I dumped it at the browser window and searched the famous string. Result is in the image attached. The dword highlighted is the RVA of the 2nd layer's EP.
Hero's target has a bit different pattern because it's an old version of the packer (2.7...), the strings are still there but in a different position.
You can check packer version running protected apps with this arg "--AmClientVersion" (without quotes).
Regards,
SystemeD

PS: I edited my previous post because it was wrong...

Hi SystemD
Thanks for checking that,But imagin said:
I tested PEid for this version on my work(2.7) and it returns the second layer
OEP(too interesting! :D ).
But I don't know why my work is not working:
1- Dump running program while browser is showing with LordPE.
2- Using the OEP that I found in ImpRec and find my IT and reconstruct the my dump.

Now this dump should work and show something(I heard that I should see something
about error in activemark),But Is not doing anything.
Any suggestion that why this happens and my dump is not working?

sincerely yours

OK - same progress like HERO (other target) - same problem - why?

EDIT:
Here I found sign. for ActiveMark - to the PEID (without detection version) :rolleyes:

[ActiveMark -> Trymedia]
signature = 79117fab9a4a83b5c96b1a48f927b425
ep_only = True

Probably the problem is here, dump the program when it reaches the second layer EP (use Olly to set an hardware bp) and use that address as the EP of the dump.

Exactly, I've done it and I obtain a msgbox saying: "Unable to start ActiveMark client engine due to an internal error."
I will try to attach my dump.

@imagin:
The image I tried to attach in my last post contained the following dump, it's my old target and here you can see after TdnAVpF@ the dword 001F9903 which is the rva of the second layer EP (so add 400000 for the address in Olly).
You can see that the pattern is a bit different from the previous version of the packer, i.e.:

Remember that important parts are "TdnA" and the long hex number that follows. Hope this help,
Bye

Thanks SystemD!
But I still can't make an working dump!??!!
WHat I have done Step by Step(in Repaired OllyDbg):
1-Hide My OllyDbg by IsdebuggerPresent(I tested without hiding and no change in result)
2-Set an Breakpoint on GetVersion and run until getting to it.
3-Dump using OllyDump and set OEP to C0B64(for cubis2.exe).
(I set to fix Sections,I don't know do it or not)
4-Run ImpRec and set OEP to C0B64 and find IAT and get imports then fix dump.
5-My dump crashes!!!!!
6-If I dump using LordPE,Program is not crashing,But It is not working too.
I don't know Why I can't make a correct fixed dump.
Any suggestion?

sincerely yours

Yes - difference is and among dumper with LordPE and PETOOLS - but it will not the main problem - largely problem why programme falls is according to to me in instruction NOP,CALL which must repair !!!(packer AM patching norm.instr.CALL to NOP,CALL) - but which and who repair this??? :rolleyes:
(have you in his dump API - LoadLibraryA??)

I have another question about AM.
Old game (2 years or so) named Codename: Silver has crypted resource files. This files are handled by AM and decrypted in memory. So only PACKED .exe work correctly.
I can dump and fix .exe, but I really don't know how to unpack that damn resources :-(
Maybe someone know how to deal with this AM trick...

Your OEP is not correct, you have to set the layer2 OEP
(RVA 0x26A593)
Only use the real OEP for the jump right before the layer2 wants to
jump to ExitProcess.

@ tr1stan

1, this OEP isn't functional (target crash)
2, why 0x26a593??? (string inicant OEP which wrote HERO)
3, it is necessary unpack and bass.dll??
4, you have some full progress??
5, what about you CALL and JMP?

tHx

Some steps to get the rebuild program
 

Hello:

I'm testing a fix to the 5.3.1071 AM release. I have got some programs totally recovered, but other not yet, just trying to fix the bugs of my "AM fixer" program. When I get good results for all I will tell you about.

But it is a very good beginning getting the "18 Wheels of Steel - Pedal to the Metal". This is the only one (I have found till today) of the 5.3.1071 AM release that keep in the dumped code the equivalences for the AM calls that you can find inside the dumped code as:

401175 nop
401176 call [AM redirection]

If you search in the dumped code (starting the program and when the "you have 60 min left" or similar displays, you have to dump it, as several people in this thread have said) for the [AM redirection] from above, you'll get this in a table, to the rigth of another pointer, pointing to the Name of the correct function. This does not work for all the others programs I have tested but this one.

All you have to do is replace the "nop call[AM redirection]", stated as 90E8XXXXXXXX by a call to the pointer of the function that I have told before.

Of course, there are another AM redirections, such as:
nop jmp [AM redirection]
not mov edx, [AM redirection]
not mov ebx, [AM redirection]
...

All of them are always preceded by a nop, this a great clue!

OK, I have builded a table of 'AM redirections', taking all of the table of AM equivalences, that you can find in the dumped file searching for:

1. The 'PEStub' string an then six 0 bytes, then the equivalence table begins.
If not try point 2.

2. The 'machine.' string, if fails try point 3.

3. The 'reason=' string, if fails it has to be a different release from 5.3.1071 AM release.

Then, you have to subtract to each 'AM redirection' the value of the beginning of the section that holds this table, and subtract the image too. With this you can build a table that contains the offsets of every AM redirection that works for all the AM programs of this release, only adding the beginning of the section that holds the AM equivalences table and adding the image, try this and you will see.

Well, if this is a little 'dark' I explain a little bit more detailed in another post.

Be lucky with this!

Cheers from Spain! :cool:

Nacho_dj

1) Works very well here :)
2) This is the OEP for the second layer. As mentioned in some tuts.
AM consists of 3 layers:
1.layer is the licence layer
2.layer is the exe protetion layer
3.layer is the actual progam
What you have to do is only get the IAT from the real program, paste it
into the second layer and simply start the program from the OEP of the
second layer, which is at RVA 0x26A593 :o
3) No.
4) Yes.
5) :rolleyes: If you rebuilt the program it will simply exit right after execution, because
the second layer checks if something was changed and if the license is
valid. To find the termination of the second layer set a bp on ExitProcess.
Once you are at the bp in olly trace back from where the ExitProcess was
called. One instruction above "call ExitProcess" there is a push with the
exit code and there you change it to "jmp (OEP of the 3. layer)" which will
jump to the actual program and everything should work...

Hi,

I'm trying to unpack a target protected by ActiveMark v2.7 and I am running into similar problems others were having.

What I have managed to do so far is make a dump, get the imports using ImpRec, fix the imports in the dump. However, when I try to run the dump it crashes (yes, more work needed). Edit: By crashes I mean that the process just exits, no error message, nothing.

The problem is, that when I try to run the original exe through Olly, it gives me a lot of access violations among other things and simply refuses to get to the stage of the browser window.

I believe I have found the right OEP value and have followed the initial steps, but I can't get far enough when running the exe through the debugger to stop at the right breakpoints. I do have the HideDebugger plugin and I have enabled all of the options.

Here is the important section of the dumped exe:

I have been using the value 0x001132AA as the OEP.


Can anyone help?

Thanks.

AM using SMC - tracing is s*it and lengthy.

No need to rebuild anything !!!!!
 

Hi all !
Please, let me tell you something about trymedla. There is no need to rebuild anything to crack an application 'protected' with this layer.
I suceeded in cracking recently this (over 600Mo) game : Sec0nd 5ight.
This target is available to dowbload as a 15 min. demo.
Protected by trym*dia, it could be broken with only a few bytes changing in the original file.
Trace into the proggy until you reach the nagscreen saying 'xx min letf' or 'time out : now buy the game !'.
Then, try to break just after you return from that screen.
Then, using F10, just try to find a stupid and simple test EAX,EAX + JZ/ZNZ.
:eek:
If you reverse the jump, the game starts.
Try to find back the routine which has been called just before this JZ/JNZ test.
Put a breakpoint onto this routine.
Close the proggy and start it again.
What happened ? Softice break at your breakpoint.
You are right in the 'LICENSE testing routine'. It returns 1 if GOOD or 0 if BAD.
If you want to reverse-engineer this, just do it : obfuscating is only a bit annoying... not really a big deal.
There is no intergrity check in this protection, then, you can include a modifying code just after decompression routine to modify the result from License check.
:)
No more bad protection on these proggies.
:cool:
have fun... bye !
frip.

hi everyone

recently i downloaded a 'trial version' of a video game.
the video game is complete tho, the only trial is ActiveMark protection.

i wanna play this game :)
so i spent some time on it last night and took some notes for everyone..

1: Debug check..
The EXE add's a command line to the exe if there is a debugger detected..
(how the debug detection works im not sure)

Load in Olly, set a memory on write on SECOND .TEXT section (mines 5f2000), now follow the address of the second text section in teh dump window.. now Shift+F9 once, and wait for it to Break, once it breaks.. you will see this below:
MOV ECX,.005F3020 ; ASCII " --MPRMMGVA--"
this added command line is what stops the game from launching any further.

at the beginning of the second text section (005F2000)
is where the command line.. "c:/Games/thisgame" --MPRMMGVA--" is.
(if you shift+f9 acouple more times you will see this appear in the begiinning of 2nd text section)
simply from memory, in the dump window, ERASE the --MPRMMGVA-- either from the address from ECX or at the beginning of 2nd .text section.

it seems the first time i bypassed this debugger, it allows me to run the exe without fixing the debug check everytime... so once you fix it the first time, it should be fixed forever in your olly as long as u have the .udd file

2.) FAKE OEP.. or second layer OEP..
PEiD came very handy at this point, using PEID Generic OEP finder.. scan the exe and get the OEP with PEiD.. this is the second layer OEP.. (if you leave that memory on write on .text, and set a hardware break on the 2nd layer OEP... you will break there..)
the second layer is nothing special.. it has the Trial Info and stuff..

if you execute from the 2nd layer OEP.. you will get the 'you have 200 minutes remaining' Notice. (UNLESS you are executing from dumped EXE.. then a certain long jump in a CALL under the first GetModuleHandleA in the second layer EP.. if you change this long JE to JNE then the dump will launch)

if you look from teh second layer EP.. down just alittle, under GetModuleHandleA there is a CALL.. this call takes us thru 2 Process's
1 - Trial stuff
2 - JUMP to OEP

notes: at OEP, there seem to be some Redirected API CALLS
the redirected API CALLS are not too difficult to find.

I Might work on a OLLY SCRIPT to fix the redirected API CALLS,
otherwise heres how i started to fix them:

at real OEP.. i search 401000 for: "90 E8" without qoutes, setting a breakpoint on every one i find..
it seems ALL the Redirected API have NOP instruction before the redirected CALL.. so they are easy to find

this is all the info i have right now..

ill write a tutorial for this protector if i succeed with unpacking it..
all i have left to do is find the rest of redirected API

good luck, see you all soon.

Thank you Mephisto for these informations (in many ways, it's exactly what I've seen when tracing into this protection).
Nevertheless, I'm still thinking that creating a few bytes patch to crack tr*media is :
1 - simpler for lazy people like me :rolleyes:
2 - a lot smaller result than a complete rebuilt exe (5 or 6 kb vs many Mb)

This way, It could be possible to make an 'pretty simple' automated tool to crack 'every' application protected by the last version of this protection.
:)

once more, thanx.
frip.

I never investigated the ripped API's since one could simply launch the app from the second layer EP, but that signature you talk about (having the NOP's and then a call into ripped API) sounds a lot like how Ultraprotect worked.

Should be possible to make a ImpREC plugin for this, simply scan for calls into high mem (easy to do) and decode where they go. However, not sure if that's possible only because I never looked at a ripped API. (I didn't bother, only dumped at second EP to let it decode for me)

-Lunar

yea dumping at the 2nd layer EP.. or licence layer EP... is probly the best..

i dumped at the 2nd EP.. and my game runs, with the trial stuff.. i patched the trial stuff to just run the game....
all the fake CALLS are working ok...
but the exe is still messd up from somthin, cause it is crashing, all my targets are crashing, just minor stuff, almost got one fixed completly, everytime i fix somthin, somthin else is broke.. :|

but ive yet to get a completly unpacked exe.. i cant code much so coding a pluggin for imprec is outa the question ;)

although i did some research on teh fake calls..
not ONLY are some CALLS faked.. jump dwords to API are faked as well.. inbetween FF25 there is 90E8xxxxxx
but they are all simular..
(in my dumped at OEP.. the fake calls dont execute the right code, due to a long jump in every fake code process)
in mine, all the fake calls take me to a CALL DWORD.. to GetModuleFileNameA..
then a bit after this is the API that it really fucked... (but in dumped at OEP this real API doesnt get executed because of a long jump)

mm still yet to play my gamewithout trial :|

following the rebuilding...
 

Another issue of AM protection is the one related to functions and dll's.

AM protection removes some of the functions provided in the import table by the original program. So, in order to rebuild the program, you will need adding these lost functions (api's), or even, some dll.

It happens in functions such as Direct3DCreate8, belonging to d3d8.dll. When a nop + call is referencing to it, the rebuilding of this function has to include the insertion of the function in the import table, and, if no present, of the dll.

I do not know whether there is a tool doing this. I have included this function in the rebuilder I am developping, but it has been a difficult task.


When tracing the nop + call redirection, you can get a LoadLibrary "d3d8.dll", and then, GetProcAddress of "Direct3DCreate8".

So, another issue that has to be fixed...


Cheers :cool:

Nacho_dj

when you need to add a lost api
 

Because of adding a new API, deleted by the AM protection, in the action of rebuilding the program, you will find at least two possibilities:

- Adding it following the last name of function in the import table. This is only possible whether the dll owner of the function has to be added too, because previously did not exist in the file.

- Inserting it in the middle of the import table. This case is when the dll owner of the function exists in the import table.


The first case is more or less easy to solve. But it is necessary rewriting all the values of IAT and Original First thunk, and adding a new function name. It has to be done with a lot of care in order to get the rebuild working.

The second case means that you need to rewrite all values of first thunk, IAT and original first thunk, plus modifying the function names list. It involves the appropriate changes in a lot of calls to api's, in order to remain calling to the original api.

This is another issue that a rebuilder of this protection needs to fix.

I have found in internet some tools "doing" this, but none of them working totally.


Cheers :cool:


Nacho_dj

Managing sections of the PE header
 

Talking about sections, one issue necessary to fix in the rebuilded program is deleting the useless sections, because the AM protection increases the number of these, and consecuently, the size of the file.

If you unpack and fix all the things that the AM protection touchs, when you have rebuilt the file, it seems to be too big. Ok, just think there are several sections working for the protection, and thus useless to the rebuilded unprotected program.

So, the task is trying to choose the parts of these sections that are working only for the original program.

At least, the first section remains as is, because it has the code of the executable. The parameters, such as size and offset, could remain the same. So this section could receive the .text name.

The section that has to be converted to .rdata is the one that holds the import table.

As I said in another post, this has been rebuilt in order to get active all the correct api's. So, one way of rebuilding this is putting the IAT just behind the First Thunk of the import table, as you can find normally. I say this because a lot of times, AM protection reallocates the IAT in other area of the file.

Ok, then section .rdata must be the one that holds the rebuilt import table.
In the dumped you know some ways of getting the offset of the import table. ImpRec uses the OEP to find it.


You normally find another two sections in an executable: .idata and .rsrc.

Recovering both sections is the task where I am at the moment.


If anybody could add some in this sense i would be great!


Cheers :cool:

Nacho_dj

AM release 6?
 

Does anyone here have got a protected program by the new release 6 beta of AM?

I would like it in order to include in the generic unpacker/rebuilder, still in developping/testing status.

If you go to the trymedia URL you will see they are announcing this new version of the protection, with the possibility of maybe trying it.


At the moment, I am trying to let the size of the rebuilded program as the original had. It involves the fix of the .rsrc section.


Cheers! :cool:

Nacho_dj

Correcting my own posts
 

03-16-2005 post corrections:

Ok, that is a mistake, it is the 5.3.1078.
Now, I am testing with the tool all releases I have found.

Ok, that has changed. I have found lots of targets that keep the AM equivalences table.

Well, in the 5.3.1078 you always find the AM equivalences table following the PEStub string plus six zero bytes. The other options work for another previous AM releases to this 5.3.1078.

And in the same post, some "not call" that are to be "nop call". :)


Cheers! :cool:

Nacho_dj

Some clues in the dumped for rebuilding sections
 

Hello:

As I have mentioned in Thread:
http://forum.exetools.com/showthread.php?t=7784

there is the possibility of finding a "second PE header" in the dumped.exe from an AM protected target.

Ok, as far as I know, the rebuilding of sections in order to get the original unpacked and unprotected program remains as follows:

- From 5.0.900 AM release till now AM releases, if a second PE Header does not exist, the rebuilt target PE Header is exactly the dumped.exe PE header, but choosing only the four first sections.

- If a second PE header exists, then the rebuilt PE header has the virtual values (offset & size) as in PE header, and Raw values as the virtual values of second PE header. The names of the sections have to be these of the second PE header.

The following thing to do is deleting all the unuseless sections for the rebuilt target. The sections that normally you find in a .exe file are:
.text
.rdata
.data
.rsrc

.text is the first section, it remains as is.

.rdata contains the first thunk. You have to write there the rebuilt first thunk of the import table. This involves recalculate all the calls to api's.

.data contains the data that the program uses, and normally the IAT. So, you have to rebuild the IAT there. The offset of the IAT comes following the OEP value in the dumped.exe, found with the "_com_err" string searching.

.rsrc is the resources section. You have to "transport" the resources of the dumped.exe to that section, deleting the AM resources, such as "AMTOOLBAR", and so on.

All those operations have to be done modifying conveniently the PE header, because there is where the .exe keeps the information of IAT offset, Import Table offset, Resources virtual address and the size of all of them. Without this fix, the rebuilt target is certainly crashing or even the system does not recognize it as a valid .exe.

I will follow in another post explaining how to delete the unuseless sections. :)

Cheers :cool:

Nacho_dj