Help with cracing Trymedia Activemark app

[Nacho_dj]

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!

Nacho_dj

[jonwil]

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)

[jonwil]

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)

[Nacho_dj]

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.

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!


Nacho_dj

[jonwil]

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?

[jonwil]

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