ActiveM***

[SystemeD]

Originally Posted by Hero

1- Dump running program while browser is showing with LordPE.

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.

Originally Posted by Hero

Now this dump should work and show something(I heard that I should see something
about error in activemark),...

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).

0014D370   58 23 55 00 00 00 00 00  2E 3F 41 56 5F 63 6F 6D   X#U......?AV_com
0014D380   5F 65 72 72 6F 72 40 40  00 00 00 00 00 00 00 00   _error@@........
0014D390   54 64 6E 41 56 70 46 40  03 99 1F 00 71 A5 06 00   TdnAVpF@.™..q¥..
0014D3A0   E0 DE 0B 00 4C 06 00 00  63 31 36 38 34 35 39 64   ��Þ..L...c168459d
0014D3B0   33 38 65 35 31 62 32 33  63 38 37 63 38 64 63 65   38e51b23c87c8dce
0014D3C0   35 34 37 31 37 66 34 35  00 00 00 00 00 00 00 00   54717f45........

You can see that the pattern is a bit different from the previous version of the packer, i.e.:

001636D0   74 77 61 72 65 5C 00 00  54 64 6E 41 43 42 B9 3F   tware\..TdnACB¹?
001636E0   AE 4F 26 00 64 0B 0C 00  00 65 0F 00 00 03 00 00   ®O&.d....e......
001636F0   34 37 32 36 36 62 34 66  35 63 64 62 39 65 33 35   47266b4f5cdb9e35
00163700   61 35 30 63 37 65 37 63  34 36 38 66 63 37 30 31   a50c7e7c468fc701

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

[Hero]

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???
(have you in his dump API - LoadLibraryA??)

EXAMPLE:
004014BD    90              NOP
004014BE    90              NOP
004014BF    90              NOP                        -----/ 
004014C0    E8 58C21100     CALL    Dumped2_.0051D71D  -----/wrong CALL
004014C5    85C0            TEST    EAX, EAX
004014C7    74 24           JE      SHORT Dumped2_.004014ED
004014C9    8B10            MOV     EDX, DWORD PTR DS:[EAX]

Originally Posted by Hero

Thanks SystemD!
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?

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

[Nacho_dj]

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!

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
3) No.
4) Yes.
5) 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:

00BF85A0  5C 54 72 79 6D 65 64 69  \Trymedi
00BF85A8  61 20 53 79 73 74 65 6D  a System
00BF85B0  73 5C 41 63 74 69 76 65  s\Active
00BF85B8  4D 41 52 4B 20 53 6F 66  MARK Sof
00BF85C0  74 77 61 72 65 5C 00 00  tware\..
00BF85C8  54 64 6E 41 BD 5A 1F 3E  TdnA½Z>
00BF85D0  9E 86 8F 00 AA 32 11 00  ž†?.ª2.
00BF85D8  60 BA 14 00 FC 07 00 00  `º.��..
00BF85E0  39 30 65 39 62 31 64 32  90e9b1d2
00BF85E8  63 34 63 38 35 61 65 36  c4c85ae6
00BF85F0  37 35 66 31 38 32 32 33  75f18223
00BF85F8  34 35 33 33 39 39 37 33  45339973

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


Can anyone help?

Thanks.

Originally Posted by noobzilla

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.

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

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.

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.

have fun... bye !
frip.

[MEPHiST0]

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
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