Help with cracking Trymedia Activemark app
 

Target is protected with Trymedia Activemark 5.41.1210
Steps taken so far crack:
1.Start the target and go to the "enter the code" page.
2.Open latest PE_Tools
3.Select target and do full dump
4.Do "Get OEP". Note down those OEPs.
5.Disassemble dumped target in IDA. Check noted OEPs.
Found what looks like correct OEP at B5D024
Start imprec, select the target.
Punch in B5D024 (our possible OEP) and press "IAT autosearch".
imprec says "cant find good imports"
Next, put address and size of .idata segment into ImpRec.
It finds valid IAT entries plus bad thunks.
Delete bad thunks (IDA says no parts of the code call these "bad thunks" so they must not be valid parts of the IAT).
Then do "fix dump" on the dumped exe file.
Resulting dump wont run.
hxxp://users.tpgi.com.au/adsloptd/target.zip is the origonal packed target
hxxp://users.tpgi.com.au/adsloptd/rct3d_.rar is my current dump

Can anyone tell me what I am doing wrong or how to get this target to actually run?

I also tried an OEP of 0129064F (which is what PeID said the OEP is) but that didnt make it run either.

Hopefully someone can tell me how to get this target running :)

I also managed to get IceExt running at last.
If I run with SoftIce not loaded at all, target works and displays "enter key" screen.
If I run with SoftIce loaded and protection off, I get "anti-debugger" message.
If I run with SoftIce loaded and protection on, program loads and silently terminates.

So I have no way (at least that I can see) to use SoftIce on this target (e.g. to be sure what the OEP really is)
The target detected OlyDbg too.

I don't know anything about the target app and trymedia system but i can guess that IF you did the right job it might have a sdk where developer checks for presence of the envelope and if not it crashes the program but it is only a supposition.

Hi jonwil:

First, take a look at the following thread: ActiveM***, in
http://www.exetools.com/forum/showthread.php?t=7013

maybe there you will get a clue.


Could you tell us which is the program you are dealing with?

I have totally rebuilded and working "Chuzzle Puzzle", that has the same AM version 5.41.1210.

I am hard testing an already developed generic unpacker but not yet published, because sometimes the program rebuilded, even working well, ask for the CD.
And another times, rebuilded program says things like: "You need Shockwave Player 8.5 installed in your PC".

I want a totally free of errors unpacker, giving always a working program, before publishing it.

The OEP, as I said in a post in the above thread, when edited in an hex editor, is below the string '_com_err': is the first value you find in that column that is bigger than the position of the first section and smaller than the position of first section plus the size of first section.

In your rebuilded program, you still need to fix all the call's and mov than uses redirections to AM functions. AM picks fetch to functions of some DLL and rewrite them to call to AM functions, that are controlling the trial time, the registration of the program, and so on.
All of them all always preceeded by a nop.

Good luck in your research!


Cheers from Spain! :cool:

Nacho_dj

Hi,

The older versions of Intervideo DVD copy is protected with this TryMedia crap. Maybe the latest trials too.

Here is InterVideo DVD Copy 3 Gold/Platinum

ActiveMark is a weak protection. It detects most of the tools with a very primitive methods.

You cannot run SICE because AM searches for the following devices (and drivers) NTICE, SICE, SIWVID, FROGSICE, SUPERBPM. It was good but few years ago.
Let me guess. You had SICE / FileMon / RegMon / LordPe or ImpRec running at the same time. Try to run it without any additional tools and it will work (with IceExt protection turned on).

Also think about breakpoints. AM detects them and will refuse to run if you set any (CC). Use hardware breakpoints since AM does not operate on debug registers.

Hope that helped. Good luck.

no, I has just SoftIce with IceExt running.
What I did notice is that if I turned off IceExt int3 protection, it went back to giving me the "dont use a debugger" message.

ok, I found the OEP, actually 2 OEPs.
One is E9064F, same as PeID, the other one is 75D022 which matches with what I found before.
Which one is the correct OEP and how can I tell? (i.e. which one do I set the OEP in the PE file to?)

Going to locate and remove all these "trymedia" calls.
What about IAT, is ImpRec the correct way (someone on another board said using ImpRec is NOT the correct way but I am not 100% sure since it seemed to give what look like valid IAT entries)

As for the target, it is a beta version of a game (I wont say which one) which uses Trymedia to verify that u are tester with correct key (I am not interested in cracking this to play the game, I am interested in cracking this so I can reverse engineer the new data formats in the new version (I already know some of data formats from other games with similar formats, this one has new formats that I want to investigate)

Try search button before you ask >> http://exetools.com/forum/showthread.php?t=7013

I already read that thread.
If I use "2nd layer EP" (in .bss segment) for EP, it crashes somewhere before calling the OEP (I can see code that calls OEP in there but it doesnt reach it)
If I use "Origonal EP" (in .text segment) for EP, it crashes on "nop call sub_11CA1B7"

I cant see anything in that thread (or elsewhere) showing how to deal with the crash I get if I use 2nd layer EP (or anything indicating that using Origonal EP and doing manual fixups for all the "nop call" type API things is what I should be doing instead)

Nacho_DJ, if you have a generic unpacker for ActiveMark, it might be that my target is one that works in your packer.
Can you send me the packer (or alternatively unpack the target and send me the unpacked target)? My target doesnt need a CD and only has "enter code" mode (not "trial" mode).

hmmm, mabie because the code hasnt been entered properly, thats why the crashes are happening when I use the "2nd layer EP" of ActiveMedia (the one PeID gave me)

Hi jonwil,:)
Have you tried the tut at hxxp://xoomer.virgilio.it/pinc0pall/crktute/2/ActiveMark.txt mentioned in the Exetools thread pointed by NOP. Is this method works on new versions of Activemark...?

Unpack AM is not problem - find the first and second layer and dump is easy - problem is replace the FAKE NOP CALL - you must be find and by hand repair - it is every time otherwise :mad:

I tried that tutorial but it requires using tools that only run on windows 9x (plus its not usefull for latest AM) so it doesnt help.

Could my problems be caused because the Trymedia crap does a check to see if the exe file on disk matches with what it expects?
If so, how do I convince it to read the packed exe instead of the unpacked one?

Clearing some points...
 

You are right imagin, unpacking is not the main problem, but the nop + call rebuilding.

Ok, as far as I know, till 5.31.1140 AM release, you can find the "nop + call" equivalence to the good call in the AM equivalences table, as I call it.

¿Where? When you have unpacked the AM protected program, opening an hex editor, search for one of these strings:
'PEStub', 'machine.', 'reason='.

If one of then is followed by some ceros, then you can find behind the equivalences table, as I have mentioned in ActiveM*** Thread.

This table has elements that consist of two fields.

If you are lucky you will find this:
- First field: a word, that is a pointer to a name of function of DLL; for instance: ExitProcess.
- Second field: a word, that is the value that the call invoques, this that is preceeded by a nop; for instance, value = 537562, that would be then 'nop call 00537562'.

This is cyclic till all the equivalences pointer-value are covered. Behind last couple of values, you can find pointers to the dll names.

But sometimes, you only find the first field, and the second is cero, during all the equivalences table. No values for calls here.


You need only a program for every release with the equivalences complete (first and second field not equal to cero) to build a generic AM unpacker/rebuilder.

What procedure do you have to follow? This simple one:
Take the second field of one element in the table (f.i. : 537562), subtract to it the image (f.i.: 400000), then subtract to it the offset of the AM section, i.e., the section where the information of the AM release is located (f.i.: B0000).
Then, in the example I have chosen, you'll get the following value: 537562 - 400000 - B0000 = 87562 = AM equivalence for ExitProcess

Take this value, and put it in a table. Every time you are rebuilding a new program in that AM release (it has to be the same release exactly), do the same but inversely:

Am equivalence + Image + Offset AM section = value that is invoqued in a 'nop call value', then replace this nop + call for a call to the ExitProcess.

The same for all the values found in AM redirections (nop + call).

And that's all, you have recovered the original call's of the program.


This I have done in my rebuilder and is working for every program that belongs to the same release.


Of course, you need to rebuild the import table too, because it is affected for several changes leaving it in bad state, another AM change. This you can do with an import rebuilder, but ImpRec is not working well in several situations where ordinals and no functions names are used, so I have built a procedure in my 'still in developping status' program that correct this.


OEP is not a problem, is a field always n x 16 positions behind the '_com_err' string, with 'n' a little integer value.


I do not know how the AM packer works, but how to rebuild the AM calls.


Tell me if this is working for you...


Cheers! :cool:


Nacho_dj

IMHO better way is dumping after unpacking, before showig the NAG screen (i think that AM uses somethink like UPX) a then patching reg.rutine(nag) it works for me well ... (i patched 2 progs which have encrypted data files and decrypting cca 20filez is too much work)

So, is there some way I can fix my dump so that when I start at the "2nd layer EP" I dont crash and instead get working code?
Or do I need to start at origonal EP and fixup the "nop call" and "encrypted data files" myself?

I found the table with the functions in it but unfortunatly, the "calls" are 0.
So it looks like (unless someone else has a binary with usable values in it) fixing up all the calls for version 5.41.1210 of ActiveMark has to be done by hand. Ditto the decrpytion of encrypted files

Either that or some solution has to be found where you can use the 2nd layer EP and then modify the code between the 2nd layer EP and the OEP of the program somehow so that the "nop call" instructions and the encrypted data files are correctly setup/read/decoded but without any crashes or errors.

I have tried everything to get this to work but it seems no-one knows anything about 5.41.1210 of ActiveMark (or what steps to take to sucessfully crack it).

With the info out there, I am surprised no-one has made a "generic" ActiveMark unpacker that can unpack AM directly I see several people saying "I am working on it but it doesnt unpack everything yet so I dont want to release it" (even if it doesnt unpack everything, mabie it might unpack to working some targets, mabie even mine :)

I also have the .lcn file from someone who has the target (in "C:\documents and settings\All Users\Application Data\Trymedia\licenses") but the target wont recognize as "unlocked".

Is it because there is more data that goes with the licence somewhere? Or is it because the .lcn file is locked to a particular machine? Is there some way to get the target to use this licence file (I cant just type the "unlock code" into the trymedia window because it talks to the internet to check if its valid)

Hello:

Unfortunately, when the AM equivalences table has the second field to zero, you need, at least once, tracing the nop + call till a call to a function of DLL appears in the obfuscated code. A good way is using always F8 (not to enter the calls in the obfuscated AM code) to get faster the function name that nop + call is replacing to. No more than 1 minute tracing and the function name appears.

Then, you have got the function name and the value of AM redirection. Just do as I have explained before to go filling an equivalences array in your program, that will work for every same AM release program. The found values for every AM call found in your program probably do not cover the entire AM equivalence table, and you have to repeat this procedure of tracing every time you are facing new values for the AM equivalences table. But with several programs (4 or 5) maybe you will have found the main redirections for all programs.


If you try to search the AM equivalences table in old AM releases, such as 2.x.xx or 4.x.xx you will find them with the two fields not equal to zero easily, so providing you all the equivalences for you generic rebuilder.


Another issue talking about Import table is that AM erases some functions of DLL from the import table.

So, when you replace the nop + call for the correct call, guided by the AM equivalences table, you could get an impossible reference due to this fact.

Then, it is necessary adding this 'disappeared function' to the import table. This requires, as you could imagine, rewrite a lot of calls of the program in order to correctly fetch the proper functions.


You see, is a hard task but done carefully you will get a good fix for the program.

This has to be written down in a tutorial, I know. Let me first follow testing the rebuilder for all known AM releases.

jonwil, I am trying to attach the rebuilded target but I cannot, do not know why. Is there another public place where I could hang it? Maybe it is the big size (similar to yours) that is preventing the upload.

Cheers! :cool:

Nacho_dj

You could email it to [email protected]
Also does anyone have any other targets protected by 5.41.1210? (or better yet, some way to encode our own targets with that version :)

And, does anyone know exactly what to run to prevent this version of AM from seeing the debugger (I cant get SoftIce+IceExt to sucessfully hide from AM, nor Olly+hidedebugger.dll plugin I dont think)

ok, I got a dump that works except for the encrypted resource file
Here is my resource file code:
push ebx
push esi
push edi
push offset aRb ; "rb"
push offset aMain_common_ovl ; "c:\\main.common.ovl"
call fopen
push 85C001h
mov esi, eax
call malloc
push esi
push 1
mov edi, eax
push 85C001h
push edi
call fread
push offset aWb ; "wb"
push offset aMain_out ; "main.out"
call fopen
mov ebx, eax
push ebx
push 1
push 85C001h
push edi
call fwrite
push esi
call fclose
push ebx
call fclose
add esp, 3Ch
pop edi
pop esi
xor eax, eax
pop ebx

It reads and writes the file all right but it doesnt actually decrypt it (i.e. what I see in memory and in the output file is the encrypted file).
Any suggestions? (I checked and the code definatly goes through the "nop call" redirected APIs inside fopen, fread, fwrite and fclose)

Woud calling <redirected CreateFile>, <redirected ReadFile>, <redirected CloseHandle> and <redirected WriteFile> directly help? (I only used fopen etc because they are there and easier to work with)

Encryption?
 

Hello!

As you see, this strange way of working (when target is rebuilded) is one of the things I am willing to fix, this that ask you for a certain file that apparently is available for the program. :confused:

But I am only researching the code of the original program, in order to restore it, as you would get it if no protection was applied.


That means, I would like to rebuild a code without any piece of protection, as the original program did. It is my goal.

So, the question is: is it neccesary, in order to the rebuilded program be working, decrypting that code?

I think: no.


In other hand, I guess that encrypted code is dumped too with my rebuilder, but I haven't checked this point.

When I have traced (in OllyDbg, only possible from the beginning of the execution with Hidedebugger plugin, shared in another Thread of this forum) I have found things such "License", ".lic", and so on, all related to AM registration. I was thinking it would be interesting extracting the way how the registration was done. But this is another line of research. Maybe when fixed all the changes applied by the AM protector, it would be due taking this issue.

Of course, in every PC you need a different AM registration code, stated that register keys that controls the time expiration are different for every computer. Maybe it is dealing with Volume_id, FreeSpaceDisk, or similar, to get the unique code for each PC, as you can find in mounts of programs.

<"Woud calling <redirected CreateFile>, <redirected ReadFile>, <redirected CloseHandle> and <redirected WriteFile> directly help? (I only used fopen etc because they are there and easier to work with)">

jonwil, I do not understand this sentence, could you explain what this question means, just a little?


Cheers! :cool:


Nacho_dj

I have a "fake dinput8.dll" with code like this

typedef HANDLE (WINAPI *cf) (LPCSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD dwFlagsAndAttributes,HANDLE hTemplateFile);
cf Create_File;
typedef BOOL (WINAPI *rf) (HANDLE hFile,LPVOID lpBuffer,DWORD nNumberOfBytesToRead,LPDWORD lpNumberOfBytesRead,LPOVERLAPPED lpOverlapped);
rf Read_File;

HRESULT WINAPI DirectInput8Create(HINSTANCE hinst, DWORD dwVersion, REFIID riidltf, LPVOID *ppvOut, LPUNKNOWN punkOuter)
{
Create_File = (cf)0x11DC317;
Read_File = (rf)0x11EC5CC;
HANDLE hfile = Create_File("main.common.ovl",0x80000000,2,0,3,0,0);
void *x = malloc(100000000);
DWORD b;
Read_File(hfile,x,100000000,&b,0);
FILE *f = fopen("main.out","wb");
fwrite(x,b,1,f);
fclose(f);
HMODULE h = LoadLibrary("c:\\windows\\system\\dinput8.dll");
Create = (di8c)GetProcAddress(h,"DirectInput8Create");
return Create(hinst,dwVersion,riidltf,ppvOut,punkOuter);
}

This is then being placed in the game folder on a machine with a fully unlocked target.
The game is then run and promptly crashes.
With the addition of debugging output statements (snipped for clarity) I have established that the crash happens right when the call to Create_File is made.
When I run IDA on my dump without the "nop call" fixups, I can identify that 11DC317 is the redirected createfile.
And 11EC5CC is the redirected readfile.
Although when I did this code
FILE *cf = fopen("fopen.bin","wb");
fwrite(Create_File,30,1,cf);
fclose(cf);
to see what was at that memory location, the values in fopen.bin didnt match with what IDA says is at 11DC317

So obviously something somewhere means that the functions I need are not at the addresses I think they are.
Running a debugger on this machine is not an option, is there some other way I could obtain the right addresses to call for the redirected Create_File and Read_File?

ok, it turns out that the build of the exe the guy with the unlocked copy was using was newer than the one I was disassembling. And, even though it had the same ActiveMark version (5.14.1210), the "nop call" redirected functions were at a different place in the .bss segment.
Having found them, I am able to decrypt the encrypted data files. (by using said fake system dll on the machine of the person with the working copy)
However, my target wont work because the exe file I am using and the data files I have dont match (it crashes sometime during the loading process). If Nacho_dj could please run http://users.tpgi.com.au/adsloptd/rct3.rar through his magic unpacker, that would be GREAT...