Here is some info about the activationcheck:
If activation was successfull it goes to the following code:
Quote:
00432FEB |> \A1 BCC44500 mov eax,dword ptr ds:[45C4BC]
00432FF0 |. 3BC3 cmp eax,ebx
00432FF2 |. 74 16 je short TagesCli.0043300A
00432FF4 |. 53 push ebx ; /lParam
00432FF5 |. 53 push ebx ; |wParam
00432FF6 |. 68 0B800000 push 800B ; |Message = MSG(800B)
00432FFB |. 50 push eax ; |hWnd => 1703EC
00432FFC |. FF15 28054400 call dword ptr ds:[<&USER32.PostMessageW>; \PostMessageW
Important checks to get to there are:
00432F91 |. /74 58 je short TagesCli.00432FEB
(needs to jump)
00432F56 |. /0F84 B9000000 je TagesCli.00433015
(should not jump)
00432F4E /0F82 C1000000 jb TagesCli.00433015
(should not jump)
Also important part for the last check mentioned:
Quote:
004371F6 |> \66:8B41 FF mov ax,word ptr ds:[ecx-1]
004371FA |. BA FF7F0000 mov edx,7FFF
004371FF |. 66:23C2 and ax,dx
00437202 |. 0FB7D0 movzx edx,ax
00437205 |. 8BC6 mov eax,esi
00437207 |. 0FB7D2 movzx edx,dx
0043720A |. 2BC7 sub eax,edi
0043720C |. 3BC2 cmp eax,edx
0043720E |. 73 61 jnb short TagesCli.00437271
There it seems to checks some end of a crypted block.
If it does not have a special value, it will simply set eax to 0 on later position.
So esi would be 0 at:
00432F00 |. 8BF0 mov esi,eax
and check at:
00432F4B |. 83FE 04 cmp esi,4
00432F4E 0F82 C1000000 jb TagesCli.00433015
fails.
Sadly you can not just modify the TagesClient.exe.
If you do so it will end in an endless loop.
If you try to simply modify in a debugger you will see a success-screen.
But if you press end, the program starts again and you will see the same damn window again.
(But it generates a Vca.bin with a part of the crypted block I mentioned before.
But sadly not useful for now.)
I also think that the activation-code is needed to decrypt the executable itself, but its just a guess.
PS:
Maybe someone knows what this is:
Quote:
0037ECFC /$ E8 7B1C0000 call dvm.0038097C
0037ED01 |. 8B48 14 mov ecx,dword ptr ds:[eax+14]
0037ED04 |. 69C9 FD430300 imul ecx,ecx,343FD
0037ED0A |. 81C1 C39E2600 add ecx,269EC3
0037ED10 |. 8948 14 mov dword ptr ds:[eax+14],ecx
0037ED13 |. 8BC1 mov eax,ecx
0037ED15 |. C1E8 10 shr eax,10
0037ED18 |. 25 FF7F0000 and eax,7FFF
0037ED1D \. C3 ret
I already googled constants ... seems to be part of encryption/decryption.(atleast for creating keys etc. ... yes i know its probably uses a part of "Gregory Braun" crypto-algo, just don't know where to find the encryption/decryption itself.
But it looks like it is used for TagesClient.dat and Vca.bin )
Another info:
Quote:
100018DF |. 50 push eax ; kernel32.VirtualAlloc
100018E0 |. A1 30670310 mov eax,dword ptr ds:[10036730]
100018E5 |. 68 2C670310 push offset dvm.VMCALL
100018EA |. 50 push eax
100018EB |. 51 push ecx
100018EC |. FFD6 call esi
Inside the dvm.dll the whole stuff seems to begin here.
If check fails it simply exits, if check is right it continues.
Sadly you can not simply ignore that part because of decryptions etc.
But i'm pretty shure that a cracker with an activated game can dump the dll after that.
Btw. at the offset of vmcall is a pointer to an address.
It gets called at the Darkathena.exe's entrypoint:
Quote:
00928499 > 50 push eax
0092849A 68 10A8915E push 5E91A810
0092849F A1 26839200 mov eax,dword ptr ds:[<&dvm.VMCALL>]
009284A4 8B00 mov eax,dword ptr ds:[eax]
009284A6 FFE0 jmp eax
Google