X ara 3D3 est un petit prog qui permet de faire des GIF animΘs. Mais dans sa version shareware, il y a un fond d'Θcran (trΦs laid) qui ne permet pas de faire grand chose...La version 'enregistrΘe' ne possΦde pas ce gros handicap...;-)

AprΦs avoir installΘ le prg, on s'aperτoit qu'il existe un boutton pour acheter le prog. Puis, une clef de dΘbridage est demandΘe...On rentre n'importe quoi, puis une zolie boεte de dialogue nous indique que la clef n'est pas bonne...

Deux mΘthodes s'offrent α vous:

Mettre un BPX sur GetdlgItemTextA ou GetWindowTextA

Mettre un BPX sur MessageBoxA

Bien que la premiΦre mΘthode soit plus logique (le plus en amont de la protection vous Ωtes, mieux c'est) je vais utiliser la deuxiΦme. En fait je triche, car j'ai dΘjα crackΘ une ancienne verison de XARA 3D, et je savais que de travailler en passant par la MessageBoxA Θtait plus simple...
Bref, vous vous en foutez..

Donc! aprΦs avoir cliquer sur OK voici ce que vous voyez:

:0048C30D	FF15B86B5100	Call MessageBoxA
:0048C313	891E	mov dword ptr [esi], ebx	On arrive ici!

Un petit regard sur les instructions AVANT le CALL nous indique aucun saut conditionnel qui passerait outre ce MessageBox. Donc on va remonter d'un niveau. F10 jusqu'α prochain RET (qui se situe en :0048C339) pour se trouver nez-α-nez avec:

:00415036	E847720700	call 0048C282
:0041503B	C6056CD74C0000	mov byte ptr [004CD76C], 00	C'est ici que l'on arrive !
:00415042	C20C00	ret 000C

On regarde au-dessus, il n'y a rien. Donc F10 pour encore remonter d'un niveau.
On arrive la-dessus:

:0048C39E	FF9294000000	call dword ptr [edx+00000094]
:0048C3A4	834DFCFF	or dword ptr [ebp-04], FFFFFFFF	On arrive ici !!
:0048C3A8	8D4DF0	lea ecx, dword ptr [ebp-10]

On effectue toujours la mΩme dΘmarche, pour se rendre compte que l'on doit encore remonter d'un niveau...
Allez, courage, c'est le dernier... ;-)
Donc on tombe sur cet extrait de code:

:0040F5FE	E85ACD0700	call 0048C35D
:0040F603	8A442413	mov al, byte ptr [esp+13]	On arrive lα....
:0040F607	33DB	xor ebx, ebx

Bon, on refait la mΩme manip qu'avant, mais cette fois-ci il y a quelque chose...

:0040F5F0

E9AA000000

jmp 0040F69F

Il est y pas B⌠ celui lα ???

Bon, j'espΦre que vous comprenez pourquoi ce JMP est interessant...Il saute complΦtement par dessus notre CALL qui reprΘsente en fait le MessageBox qui nous indique que la clΘ n'est pas bonne.

On recherche donc les sauts conditionnels qui doivent pointer juste aprΦs ce JMP...
Et cela ne manque pas en plus...Il y a toute une ribembelle (9 il me semble) de sauts conditionnels qui pointent vers cette mΩme adresse... Le premier ce situe lα:

:0040F401	83F801	cmp eax, 00000001
:0040F404	0F85F9010000	jne 0040F603
:0040F40A	8B842440010000	mov eax, dword ptr [esp+00000140]
:0040F411	3958F8	cmp dword ptr [eax-08], ebx
:0040F414	0F85DB010000	jne 0040F5F5	Le premier des sauts..

Que reste il α faire??? Et bien trouver le dernier de ces CMP/SAUT qui pointe vers :0040F5F5, et de changer le premier en un saut INconditionnel pointant vers l'instruction d'aprΦs... Le CMP en :0040F401 n'est pas "dangereux"...Le saut n'est pas pris...Donc on peut se permettre de modifier le JNE 0040F5F5 en :0040F414

C'est parti...Alors le dernier de ces couples CMP/SAUT est celui-ci:

:0040F53C	0F85B3000000	jne 0040F5F5	Le dernier de son espΦce..
:0040F542	8B0DD0EA4D00	mov ecx, dword ptr [004DEAD0]	Instruction qu'il faut pointer

Bah voilα, c'est terminΘ...(dΘjα ! me direz vous....) Vous changez donc le premier CMP/SAUT en JMP vers :0040F542 et le tour est jouΘ...

Le prg s'enregistre tout seul comme un grand. Pratique non ??
Il crΘΘ une clΘ dans la base de registre, si vous voulez essayer par une autre mΘthode ou encore le refaire de part vous mΩme, il vous suffit d'effacer l'entrΘe "KEY" dans la base de registre, et de remettre le fichier EXE dans son Θtat normal si vous avez fait une modification hexa physique....