Help with cracing Trymedia Activemark app

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