Intro:
Salut les amis! Aujourd'hui nous allons continuer d'étudier les protections simples. Alors voilà, la victime est Shogo car sa sécurité est simple mais trompeuse pour un débutant, c'est pouraquoi je vais tout vous expliquer pas-à-pas. Ok, c'est un vieux jeux mais au moins il à le mérite d'être simple à déplomber... Avant tout, il vois faut les outils suivants :
- un désassembleur (WinDasm....)
- un éditeur héxadécimal (HEdit, Hex WorkShop...)
Voilà, ca serat tout.
Analyse:
Tout d'abord on va étudier le type de protection de ce jeux. Installons le prog' complètement (je vous assure que ca aide) et démmarrons-le sans mettre le CD. Paf! et là une MessageBox s' affiche :(
Hm...On va dans le gestionnaire de fichier et on voit bien de Shogo prend 430Mo en installation complète et vu la tête du jeux on est en droit de pensser que le CD ne sert qu'à jouer le rôle d'un "passe" pour montrer qu'on à bien le CD et qu'on est réglo pour démarrer le jeux, il sagit de la protection appellée "CD-Check" et c'est ça que l'on va faire sauter :)
Méthode:
Il sagit donc d'un CD-Check qu'on va exploser. Pour cela on va faire ce qui s'appel du "Dead-Listing", pourquoi ? Tout simplement parcequ' en désassemblant le fichier Shogo.exe avec WinDasm (par exemple), tout le listing d'assembleur apparrait avec en plus les "String Data". Cette méthode à l'aventage d'être efficace pour trouver asser simplement une protection.
On va donc désassembler le fichier Shogo.exe car ça doit être le reflex premier de désassembler le fichier executable principal. Ok, Shogo.exe n'est pas protéger contre le désassemnlage et tout est visible. Les String Data sont là et comme c'est le message "Inserez le CD-ROM....." qui etait dans la boîte de dialogue, on va chercher ce message. Une fois trouver double-cliquez dessus pour atterrir à l'endroit du listing où ce trouve ce message. Ok, on tombe dessus mais cliquez encore sur la phrase pour voir si il n'y à pas d'autre "Inserez le CD-ROM...." dans le listing. Ahhh! Il y en à au moin 35, alors là c'est galère, il va peut être falloir tous les virer ce qui est bourrin et en plus ce n'est même pas sur que ça fonctionne, d'ailleur j'ai essayer pour voir, ca fonctionne mais la MessageBox est encore présente et il faut tout le temps cliquer sur Ok pour la passée ce qui n'est pas top.
Go-go-go!
Et c'est là que je vais vous montrer comment faire sans pour autant que vous aillez des supers bases en assembleur ;)
Là on commence à réflechir et on se dit qu'avec tout ces String Data de "Inserez le CD-ROM...." il doit surment avoir un jeux d' instruction qui permet de lancer une recheche sur le lecteur de CDs sinon ça voudrais dire que les programmeur s'y sont pris comme des pieds niveaux optimisation du jeux ce qui n'est pas souvent le cas. Mais qu'est ce que l'optimisation? Pour vous répondre je vais vous monter un shéma d'exemple qui correspond avec la protection de Shogo :
.Début :J'appel de Cd CD Ok? Oui, alors je saute vers Jeux Si non alors je saute sur Non0! Je ne sais pas ce qu'i lse passe, alors je saute sur Autres cas :Jeux Ok d'après ,:J'appel de Cd, le CD est là Alors je dois demarrer le jeux Jeux démarré... :Non! Ok d'après ,:J'appel de Cd, le CD n'est pas là Alors je ne démarre pas MessageBox de non présence du CD La MessageBox doit s'afficher dans plusieurs cas, de Non0! à Non35! :Autres cas Ok, problème de CD CD non présent Je saute vers ,:Jeux, pour lancer la routine de recherche :Non0! MessageBox de non présence du CD Clique sur Ok Alors je saute vers ,:J'appel de Cd, Clique sur Annuler Alors de saute vers ,;FIN, :Non1! MessageBox de non présence du CD Clique sur Ok Alors je saute vers ,:J'appel de Cd, Clique sur Annuler Alors de saute vers ,;FIN, [...] :Non35! MessageBox de non présence du CD Clique sur Ok Alors je saute vers ,:J'appel de Cd, Clique sur Annuler Alors de saute vers ,;FIN, :FIN On ferme le programme
Voilà-voilà =]
Donc on retourne dans WinDasm, on regerde un peut tout ce qui se trouve dans les Strigs Data. Là on tombe sur "CdRom Drive". Hm.... allons voir. Yop! il n'y en à qu'un seul, ca alors comme c'est étrange tout ca, on va voir ce qu'il se passe autour:
* Referenced by a CALL at Addresses: :00401190 , :00404548 , :0040473F , :00405E4C :004011F0 64A100000000 mov eax, dword ptr fs:[00000000] :004011F6 6AFF push FFFFFFFF :004011F8 68EB0B4200 push 00420BEB :004011FD 50 push eax :004011FE A090D24200 mov al, byte ptr [0042D290] :00401203 64892500000000 mov dword ptr fs:[00000000], esp :0040120A 81EC60040000 sub esp, 00000460 :00401210 53 push ebx :00401211 33DB xor ebx, ebx :00401213 56 push esi :00401214 3AC3 cmp al, bl :00401216 57 push edi :00401217 0F852C010000 jne 00401349 :0040121D 899C2450010000 mov dword ptr [esp+00000150], ebx :00401224 53 push ebx :00401225 6802000080 push 80000002 :0040122A 53 push ebx * Possible StringData Ref from Data Obj ->"1.0" | :0040122B 6804914200 push 00429104 * Possible StringData Ref from Data Obj ->"Shogo" | :00401230 68A0904200 push 004290A0 * Possible StringData Ref from Data Obj ->"Monolith Productions" | :00401235 68EC904200 push 004290EC :0040123A 8D8C2468010000 lea ecx, dword ptr [esp+00000168] :00401241 899C248C040000 mov dword ptr [esp+0000048C], ebx :00401248 E873180100 call 00412AC0 * Reference To: KERNEL32.GetDriveTypeA, Ord:00DFh <--- Magnifique! | :0040124D 8B3DD0214200 mov edi, dword ptr [004221D0] :00401253 85C0 test eax, eax :00401255 0F8480000000 je 004012DB <--- On s'en fou :0040125B 8D44240C lea eax, dword ptr [esp+0C] :0040125F 53 push ebx :00401260 8D4C2414 lea ecx, dword ptr [esp+14] :00401264 50 push eax :00401265 51 push ecx * Possible StringData Ref from Data Obj ->"CdRom Drive" | :00401266 68E0904200 push 004290E0 :0040126B 8D8C2460010000 lea ecx, dword ptr [esp+00000160] :00401272 C744241C1E000000 mov [esp+1C], 0000001E :0040127A 885C2420 mov byte ptr [esp+20], bl :0040127E E87D1A0100 call 00412D00 :00401283 85C0 test eax, eax :00401285 7454 je 004012DB :00401287 8A442410 mov al, byte ptr [esp+10] :0040128B 3C14 cmp al, 14 :0040128D 7E4C jle 004012DB :0040128F 0FBEF0 movsx esi, al :00401292 56 push esi :00401293 8D542434 lea edx, dword ptr [esp+34] * Possible StringData Ref from Data Obj ->"%c:\" | :00401297 68D8904200 push 004290D8 :0040129C 52 push edx :0040129D 8AD8 mov bl, al :0040129F E86C6D0000 call 00408010 :004012A4 83C40C add esp, 0000000C :004012A7 8D442430 lea eax, dword ptr [esp+30] :004012AB 50 push eax :004012AC FFD7 call edi :004012AE 83F805 cmp eax, 00000005 :004012B1 7528 jne 004012DB :004012B3 56 push esi :004012B4 8D4C2454 lea ecx, dword ptr [esp+54] * Possible StringData Ref from Data Obj ->"%c:\GAME\SHOGO.EXE" | :004012B8 6808914200 push 00429108 :004012BD 51 push ecx :004012BE E84D6D0000 call 00408010 :004012C3 83C40C add esp, 0000000C :004012C6 8D542450 lea edx, dword ptr [esp+50] :004012CA 52 push edx :004012CB E8D0FEFFFF call 004011A0 :004012D0 83C404 add esp, 00000004 :004012D3 85C0 test eax, eax :004012D5 0F8586000000 jne 00401361
Voilà, ici c'est clair, on peux voir que ce sont les instruction CALL se trouvant aux lignes :00401190 , :00404548 , :0040473F , :00405E4C qui vont servir à aboutir dans la zone où se trouve * Possible StringData Ref from Data Obj ->"CdRom Drive".
Pour voir, on lance une recherche sur 00401190 ,:00404548 , 0040473F , et 00405E4C pour voir où ils se trouvent. En fait, le seul qui va nous interresser c'est le CALL 00401190 qui va nous interresser puisque les autres se trouvent après lui (bon, on va pas trop entrer dans les details mais en général c'est ca) vu son offset qui est 00000437.
Maintenant on retourne sur le CALL 00401190 et on entre dedans. Là on attéri pile sur un CALL 004011F0, pourant il n'est pas réfférencer dans la liste que WinDasm nous à indiquer, cela veut dire que l'on entre aussi dedans, comme le Shgo va le faire, sans se préocuper de ce qui se trouve juste en dessous (c'est pas bien important) et là on retombe bien sur l'endroit où se trouve * Possible StringData Ref from Data Obj ->"CdRom Drive". C'est y pas jolie tout ca?
Conclusion:
Tout ca nous montre bien qu'il faut virer ce CALL 00401190 pour virer la verification du CD car pas coup de chance et surtout pas mauvaise protection, les String Data CdRom Drive et KERNEL32.GetDriveTypeA nous ons vite inssiter à voir ce qu'il se passais autour et voilà, c'etait bien là qu'il fallait chercher :)
Ensuite pour ce qui est du crackage du fichier, je penses que vous devez savoir faire ca depuis... Surtout si vous avez lu les MemenTo précédants. Bref, il faut nopper le CALL 00401190 ;)
Aller, bonne route!