Protection commerciale : Laserlock SPEEnc v 2 (http://www.laserlock.com/)
Editeur : Microïds
Date de sortie : FR 01 novembre 2002
http://www.jeuxvideo.com/articles/0000/00002557_test.htm
Niveau requis en cracking : [ ] facile [x] intermédiaire [x] confirmé [ ] expert
Il est préférable d'avoir déjà cracké des protections de jeu de type Safedisc/SecuROM avant de lire ce tutorial (+ des connaissances sur le PE, manual unpacking, anti-debugging et imports rebuilding) et peut-être d'avoir mon précédent tutorial sur Laserlock :p
Outils nécessaires :
Softice 4.01
Icedump
Procdump / LordPE
Hiew / Hex Workshop
W32Dasm v8.93
Adump
Masm v8
Vous devez posséder le jeu original ou un clone fonctionnel (il y a un profil Laserlock dans Alcohol 120%), pour pouvoir appliquer ce tutorial...
De plus, il s'agit de la version française du jeu Tennis Masters Series 2003...
Ici, l'exécutable protégé est "Tennis Masters Series 2003.exe", que l'on appellera désormais tms2003.exe...
OS sur laquelle je travaille: Win98 SE.
Ce tutoriel est aisément transposable sur d'autres debuggers (OllyDbg, par exemple) et d'autres OS.
Ce tutorial est détaillé de façon suivante :
A) Introduction et généralités
B) Approche "Cracking"
1. Localiser l'OEP
2. Fixer les call Laserlock
3. Reconstruire les imports
4. Contourner le CD-check
C) Approche "Reversing"
1. Fixer les adresses "changeantes"
2. Etude du code polymorphe
3. Etude du code en général
4. Localiser facilement l'OEP
5. Etude des anti-debugging tricks
6. Vérifications d'intégrité
7. Etude des couches de cryptage
8. Faille au niveau de la vérification du CD original
D) Perspectives et conclusion
E) Remerciements
A) Introduction et généralités :
Laserlock est une protection commerciale créée par MLS LaserLock INC.
Elle est caractérisé par un dossier Laserlok à la racine du CD (il est caché -> ils nous prennent pour des cons).
[Le CD est d'ailleurs caractérisé par la présence d'un anneau bien visible au centre...]
S'ils croient qu'en mettant l'attribut caché à des fichiers "sensibles", on ne voit pas leur petit jeu... -> "une technique pur lamerz" :p
Ce dossier Laserlok contient 5 fichiers laserlok.in, laserlok.o10, laserlok.o11, laserlok.o12 et laserlok.o13, tous cachés (pour un poids de 92.9 Mo !!!) ...
La protection repose sur ces fichiers "incopiables" (en tout cas de façon conventionnelle ).
Il ne reste alors à la protection, qu'à vérifier la présence de ces fichiers pour déterminer s'il s'agit d'une copie ou non.
Quant à la protection au niveau de l'exécutable, elle est aisément détectable en éditant celui-ci à l'aide d'un éditeur hexadécimal :
Ils sont gentils ; ils nous donnent même la version du SPEEnc (ici, il s'agit de la version 2).
Enfin, sur leur site (copie disponible datant de Septembre 2003), on est averti (au secours Maman, j'ai peur :p) :
Actually, it is this powerful combination that makes LaserLock protection system so secure, unique and reliable, especially when compared to the other protection systems available today!
LaserLock MARATHON is:
- Uncrackable, with no Generic CracksB) Approche "Cracking":
1. Localiser l'OEP pour unpacker l'exécutable :
Après deux petits jump après l'OEP, on arrive en 0040117B et d'après le code, qui suit, on peut déjà se douter que l'exécutable est packé... (cf. le pushad en 0040119F).
Pour arriver à l'OEP "réel", testons d'abord les bpx APIs classiques (par exemple, bpx GetVersion)...
Baooom, le PC explose... lol... Nan, juste un crash... :p
Il est donc inutile
de poser tout bpx à cause des anti-bpx...
Comment alors arriver à l'OEP de notre exécutable unpacké ?
En posant un bpr 402000 650000 R (memory breakpoint).
Pourquoi 402000 ? Parce que cela permet d'éviter de retomber sur les instructions de la protection (de 4010D1 à 40192A) avant le ret en 0040157C (qui permet d'arriver dans le code "aux adresses changeantes").
Pensez à mettre un "range" assez grand, car bon nombre de jeux n'ont pas leur OEP aux alentours de 401000 (contrairement à beaucoup d'exécutables de sharewares)...
Un 1er break nous amène sur l'instruction LODSB en 00BA73FE :
On désactive le bpr par un bd 0 et l'on met un bpx 00BA7417 pour sortir de la boucle...
Zut : faut pas utiliser de BPX !!! Dans ce cas, on crashe en 00BA21FA...
Il faut donc préférer un bpm 00BA7417 X (hardware breakpoint).
On réactive ensuite le bpr par un be 0 et l'on relance pour breaker ensuite sur l'instruction REPZ MOVSB en 00BA5078 :
On désactive à nouveau le bpr (bd 0) et l'on exécute l'instruction REPZ MOVSB en 00BA5078 par un F10 (Step Over)...
On réactive alors une dernière fois le bpr (be 0) et l'on relance pour enfin breaker 1 min. après, sur l'OEP de tms2003.exe unpacké ;)
Note : Une méthode plutôt moyenne pour "trouver" l'OEP de l'exécutable unpacké consiste à le dumper en cours d'exécution (il est alors décrypté / décompressé), puis à désassembler ce dump et à chercher dans le code :
push ebp
mov ebp, esp
Elle peut constituer un moyen de vérification tout au plus (car il y a plusieurs occurences)...
2. Fixer les call Laserlock
Si l'on regarde attentivement le code au niveau de l'OEP, on a ceci :
Voyons ce qu'il y a, à l'intérieur...
On doit donc remplacer call Laserlock par call API...
Ici, il faut remplacer FF156077BA00 par FF1538399000.
e 0064697F 38,39,90,00.
Et voila, on a fixé un call.
Il nous reste plus qu'à automatiser ce que l'on vient de faire manuellement par une petite routine (un "call fixer").
Ceci constitue une protection anti-dump, dans la mesure où si l'on ne fixe pas ces calls et que l'on dumpe, l'exécutable "voudra aller" dans des zones mémoires, qui n'existent plus (et qui étaient initialisées avec la protection), entraînant irréversiblement un crash du programme...
Vous souvenez peut-être du "Call-fixer" de la version précédente de Laserlock (la version 5 de Laserlock, par exemple Desperados : Wanted Dead Or Alive) ?
Eh bien, il suffit de garder le même pour fixer tous nos Call Laserlock de cette version (il n'y a que très peu de choses à modifier).
Si vous voulez plus d'explications sur le fonctionnement de cette routine, je vous renvoie à mon tutorial précédent :p
Rem : - Par rapport à la version précédente (version 5), il n'y a plus de checksums effectués sur la routine, qui calcule l'adresse de redirection des "call Laserlock", ni d'ailleurs sur l'exécutable proprement dit, lors de l'appel à ces call. Ne nous ne privons donc pas de modifications du code si nécessaire (et c'est ce que j'ai fait en patchant à l'adresse 00BA6F8E par un jmp edi !!! ).
- La faille, présente à la version 5, qui consistait à patcher elle-même les call Laserlock par les call/jmp APIs à partir de la 50ème API et qui permettait de détourner la vérification du CD, a été corrigée...
Call-fixer (Laserlock.asm) :
Format de l’Image Import Descriptor ou Import Table (lire « peering inside the PE » de Matt Pietrek !) :
Une entrée (une DLL et l’ensemble de ses fonctions) dans l’Image Import Descriptor est constituée de 5 Dword.
Dword 1 - Characteristics (hint name array)
Ce dword est un pointeur vers le premier élément d’un tableau de pointeurs.
Chaque pointeur de ce tableau pointe vers le hint name suivi du nom d’une fonction.
Dword 2 - TimeDateStamp
Dword 3 - ForwarderChain
Dword 4 - DLL’s name
Ce dword est un pointeur vers le nom de la DLL (null terminated ascii string)
Dword 5 - Import Address Table
Ce dword est un pointeur vers le premier élément d’un tableau d’adresses.
Ce tableau d’adresses fonctionne en parallèle avec celui des pointeurs vers les hint names (noms des fonctions).
tiré de Import Function tutorial.doc / Import-Function in section RDATA.doc de El.CaRaCoL.
Merci à lui ;-)
C) Approche "Reversing" :
1. Fixer les adresses "changeantes" :title cca
.386
.model small, stdcall
option casemap :none
.code
_TextStart equ 00BA0000h
_TextEnd equ 00BA7B9Dh
start:
pushad
mov edx, _TextStart
@1: cmp edx, _TextEnd
je @2
check1:
cmp word ptr [edx], 01EBh
jne check2
cmp word ptr [edx+05], 07EBh
jne check2
cmp word ptr [edx+0Ah], 0F9EBh
jne check2
mov ecx, 0Eh
jmp paste
check2:
cmp word ptr [edx], 04EBh
jne try_again
cmp word ptr [edx+03], 04EBh
jne try_again
cmp dword ptr [edx+14h], 03
jne try_again
cmp word ptr [edx+29h], 04EBh
jne try_again
cmp word ptr [edx+2Ch], 0FBEBh
jne try_again
mov ecx, 2Fh
jmp paste
paste:
mov al, 90h
mov edi, edx
rep stosb
try_again:
inc edx
jmp @1
@2: popad
int 03
nop
end start
L'Image Base est en clair dans le SPEEnc depuis le début...
Image Base, qui est initialisé (au début de la protection), par ce code :
01A7:004014EC 3E8B853E000B10 MOV EAX,DS:[EBP+100B003E]
01A7:004014F3 89041E MOV [EBX+ESI],EAX
Quant à l'OEP, il est juste "codé" et une simple soustraction permet de le retrouver facilement !!!
OEP (VO) = 9B917A32h - 9B6D10DBh = 00246957h
5. Etude des anti-debugging tricks :
A priori, on pourrait dire qu'il n'y a aucun anti-debugs.
En effet, le jeu se lance sans problème avec SoftIce chargé en mémoire. On n'a aucun message d'avertissement, crash, sortie brutale ou autres...
Il n'y a donc pas de détection directe d'un debugger.
C'est dès que l'on met des bp / bpm (hardware breakpoint), que l'on s'aperçoit qu'il y a bel et bien des anti-debugs...
Tout d'abord, un petit log de FrogsIce (Merci +Frog's Print) :
Hook de l'interruption 3 :
Laserlock détourne donc l'int 03 vers sa propre routine (située en 00BA21BC), chargée d'effacer les Debug Registers (dr0, dr1 et dr2) et par la même occasion les Hardware Breakpoints !!!
De plus, cette routine en 00BA21BC est appelée (en Ring 0) bien plus d'une fois, par l'intermédiaire d'int 03, disséminées un peu partout dans le code...
Et si vous mettez un bpx adresse/API, vous allez directement à cette routine (mais pas quand c'était prévu :p) et vous avez droit à un joli crash en 00BA21FA !!! (crash en ring 0).
Tout simplement parce que l'adresse ds:[ebp+048B5986] en 00BA21FA (1) n'est pas "valide"...
Il en est de même pour l'adresse ds:[ebp+048BD074] en 00BA231E (2), où vous arrivez si vous avez évité le 1er crash en modifiant l'eip.
Et si vous arrivez à retourner à windows après ces crashes, et bien vous aurez droit à chaque fois à un crash de l'explorer, dès vous voudrez aller autre part que sur le Bureau (Mes documents, un dossier quelconque, etc...) et même lorsque vous voudrez redémarrer...
En effet, un crash (ou une sortie) prématuré du SPEEnc laisse l'int 03 hookée (ce n'est donc pas très propre). Ce n'est pas le cas de Starforce . L'exploreur utilise apparemment l'int 03 à ses fins, lors de la navigation dans les dossiers . Si vous réduisez le jeu entre l'hook et l'unhook par le SPEEnc après un breakpoint / boucle infinie, vous aurez des crashes de l'explorer en cas de navigation dans les dossiers.
Maintenant, pourquoi ces crashes en (1) et (2) ?
A cause de la valeur "excentrique de ebp". En exécution normale du SPEEnc, ebp a une valeur bien définie.
Lorsque l'on est en (1), ebp = FC2EA6D0, donc ebp+048B5986 prend 00BA0056 comme valeur et eax = 9B6D10DB.
Lorsque l'on est en (2), ebp = ECCD9F74, donc ebp+048BD074 prend 00BA7744 comme valeur (eax a sa valeur initiale).
Donc, quand l'int 03 est appelée à un autre moment (que ceux prévus par le SPEEnc), comme par exemple lors d'un bp, on a de grandes chances de se retouver avec un accès en lecture / écriture non autorisé, à cause de la valeur différente d'ebp.
La restauration de l'IDT, au niveau de l'int 03, ne se fait que juste avant la redirection vers l'OEP de l'exécutable unpacké...
Note : L'int 03 est détournée par les instructions en 00BA1F7E et 00BA1FCF... (voir Tutorial sur Starforce pour plus de détail sur l'IDT).
Si l'on évite l'hook de l'int 03 (en évitant les instructions en 00BA1F7E et 00BA1FCF), le programme crash... (ceci est dû aux int 03, disséminées un peu partout dans le code).
Effacement des Drx :
Enfin bon, cette routine n'est pas très efficace, puisque j'arrive à breaker à l'aide de bpm sans problèmes !!!
En effet, lorsque l'on pose un 1er bpm, SoftIce utilise le dr3 et comme celui-ci n'est pas effacé, on peut donc breaker.
Cette routine ne limite donc l'utilisation des hbp à un seul !!!
Et vous n'êtes nullement empêché de poser plusieurs bpm et de breaker sans problèmes dans le code séparant deux int 03 consécutifs...
Nopper les mov drx, eax fait planter le programme, beaucoup plus loin, à cause des vérifications d'intégrité du SPEEnc !!!
Il faut donc procéder autrement pour contourner ceci...
Interruptions (int 03) disséminées un peu partout dans le code :
Présence d'int 03 en 00BA1BD2, 00BA1C93, 00BA205C, 00BA23CA, 00BA2656, 00BA2847, 00BA29CE, 00BA3C48, 00BA3F82, 00BA43A1, 00BA445E, 00BA4A69, 00BA4EBB, 00BA515D, 00BA55FC, 00BA6073 et 00BA66B2. Elles sont donc assez nombreuses et sont autant de possibilités de d'anti-bpx et d'anti-hbp (par effacement des drx).
Quelques exemples :
etc...
Vous avez certainement vu ce cmp dword ptr ds:[ebp+048B59C0], 00000000 récurrent et précédant tous (sauf celui en 00BA205C) les int 03...
Et à quoi correspond ds:[ebp+048B59C0] ?
C'est là, qu'est stockée l'ancienne routine ("l' adresse") de l'int 03 hookée...
Or, comme on l'a vu, si l'on essaye seulement d'éviter l'hook de l'int 03, le programme plante... (à cause de tous ces int 03).
On essaye alors ceci :
En 00BA1F26 (stockage de l'ancienne routine de l'int 03), on met edx à 0 (r edx 0), pour qu'il sauvegarde cette valeur.
En 00BA1F7E, on évite l'instruction en faisant pointer eip sur l'instruction d'après (r eip eip+3).
En 00BA1FCF, on évite aussi l'instruction par un "r eip eip+4".
Enfin, on évite l'int 03 en 00BA205C (r eip eip+1).
Et maintenant vous pourrez placer tous les bpx / bpx API que vous voudrez :)
On a résolu d'un même coup l'anti-bpx et l'effacement des Drx...
Mais pourquoi cette présence de cmp / je ?
Parce que contrairement à win 98, XP ne permet pas pas de lire / écrire des valeurs dans l'IDT en Ring 3 (mode normal d'exécution des programmes)...
Ce code assure donc la compatibilité avec ce dernier système.
D'ailleurs, vous aurez remarqué que cette routine de hook de l'int 03 est incluse dans un SEH.
Toute tentative de lecture / écriture dans l'IDT sous XP nous ramène en (39)07A6 (SE Handler), 390000 étant l'Image base du SPEEnc...
Restauration de l'IDT (au niveau de l'int 03) :
Juste avant le "saut" vers l'OEP de l'exécutable unpacké, l'IDT est restaurée :
Nombreuses exceptions (SEH) :
Le SPEEnc contient de nombreuses exceptions tout au long de son code :
Ici, on est dans la routine, qui détermine s'il y a assez de mémoire disponible pour le SPEEnc.
Si ce n'est pas le cas, le saut en 00BA32DD n'est pas effectué et l'on a ce message d'erreur :
Je ne vois pas trop l'intérêt de toutes ces exceptions et SEH (présents un peu partout). Comme anti-tracing sous SoftIce, ce n'est pas très subtil...
Il faut être un sacré bourrin pour tracer l'entièreté du SPEEnc :p.
6. Vérifications d'intégrité :
Voici la routine de vérification d'intégrité du code, qui fait que vous n'avez pas trop intérêt à modifier le code, au risque d'un crash :
Cette routine est appelée plusieurs fois par le call 00BA7248, situé en 00BA722C.
Au 3ème appel,
la vérification se fait sur le SPEEnc, au niveau du bloc commençant en 00BA0190 (esi) et d'une taille de 7540 (ecx).
Le résultat de l'opération est finalement stocké dans eax.
7. Etude des couches (layers) de cryptage :
1ère couche de cryptage :
Nous avons vu qu'elle était effectuée en 004014D5, afin de décrypter le bloc commençant en 00BA0000 (esi) pour une taille de 7B9D (ecx) (voir le chap. fixer les adresses changeantes). Mais en fait, les instructions ne sont valides, que pour le bloc commençant en 00BA0190 et terminant en 00BA04A5, d'où l'application d'une deuxième couche de cryptage...
2ème couche de cryptage :
Ensuite, une fois à la fin de notre 1er bloc décrypté, la routine suivante, en 00BA733F (exactement identique, d'ailleurs à la précédente, si ce n'est le code polymorphe, en plus), appelée par le call situé en 00BA0455, est chargée de décrypter le bloc commençant en 00BA04A5 pour une taille de 44F2.
Cette routine est ensuite appelée en 00BA1B32, pour décrypter un bloc commençant en 00BA9A46 pour une taille de 3421B (des datas...).
La vérification proprement dite du CD s'effectue alors...
Le call en 00BA1B32, appelle encore cette routine pour décrypter le code en 00BA4997, d'une taille de 2617 (tout le code exécutable du SPEEnc est ainsi décrypté...), puis pour décrypter un bloc de datas du SPEEnc, commençant en 00BA748C et d'une taille de 244.
Le décrytpage de l'exécutable tms2003.exe a finalement lieu, à l'aide de cette routine également (00BA733F), appelée plusieurs fois par le call en 00BA5ABC, pour procéder par blocs, en commençant à partir de la fin de l'exécutable (les relocations) et en remontant progressivement...
Reste à répondre à la question hautement existentielle : est-il possible de cracker cette version de Laserlock sans avoir le CD original ?
La réponse est oui :).
8. Faille au niveau de la vérification du CD original :
Pour déterminer où se fait la vérification (l'authentification) du CD, il suffit de poser un breakpoint sur l'API GetDriveTypeA (il ne faut pas oublier d'appliquer les dipositions précédentes pour contourner les anti-debugs). On se retrouve alors dans le module NIL32.dll .
En relançant l'exe et en mettant un breakpoint sur CreateFileA, on s'aperçoit que Laserlock crée des fichiers temporaires dans C:\Windows\TEMP, à savoir :
- nomouse
- nomouse.com
- nomouse.sp
- NIL32.dll
- SPEEnc.Dup
Ces fichiers sont ensuite effacés, lorsque le SPEEnc a terminé sa tâche et qu'il donne la main au jeu proprement dit.
Il est donc possible de récupérer NIL32.dll, en stoppant dans le code entre le moment où il est créé et le moment où il est supprimé (par exemple, en breakant sur GetDriveTypeA). Il suffit alors d'aller dans le dossier temporaire et de le copier. Il faut bien sûr éviter l'hook (interception) de l'int 03 par le SPEEnc, parce que l'explorer interfère avec ce hook (utilisation de l'int 03 par l'exploreur dans la navigation des dossiers) et entraîne un crash...
On édite alors le PE de la dll à l'aide de LordPE.
L'OEP est de 0A150 (RVA) pour une Image Base de 0x10000000.
Il suffit donc de mettre un bpm 1000A150 X pour breaker à l'OEP.
On y breake, on relance (F5) pour breaker une 2nde fois.
Le module NIL32.dll est alors unpacké (décrypté) et 1000A150 semble être également l'OEP de la dll unpackée.
Et si ce n'est pas le cas, ça n'a pas beaucoup d'importance, puisque l'on cherche à dumper cette dll, uniquement pour l'étudier en dead listing.
En parcourant le code, on aperçoit des call [00C0xxxx], correspondant aux call [API] détournés par Laserlock.
On a de nouveau des adresses changeantes à ce niveau.
On lance un call-fixer pour résoudre ce problème.
On dumpe alors à l'OEP, à l'aide de LordPE :
On crée une nouvelle table d'import à l'aide d'ImpRec :
Pour cela, on choisit le processus tms2003.exe . On clique sur Pick DLL et l'on sélectionne le module nil32.dll .
Il suffit alors d'entrer le début de l'IAT : 1E000 (RVA), sa taille : 1F4 et de cliquer sur Get Imports.
Il ne faut pas oublier de résoudre l'import correspondant à GetProcAddress pour obtenir la nouvelle table d'import (voir précédemment).
En désassemblant la dll, on s'aperçoit qu'il reste une portion de code, qui est encore cryptée (offsets allant de 0x2E66 à 0x5CED, soit une taille de 0x2E87) :
On peut mettre un bpm 10002E66 X pour breaker et dumper le code décrypté à l'aide LordPE :
On remplace alors le code décrypté dans la .dll dumpée précédemment.
On obtient une dll entièrement reconstruite. En examinant le code désassemblé, que vois-je à mon grande stupéfaction ?
Les mêmes String Data References que la dll de Laserlock v5 : "*LASERLOK* Copyright (c) 1992-1996", "Petros Skalkos **", "v5.00.607 Compile:21/3/2002".
Finalement, les protectionnistes vous ressortent toujours la même
protection mais à une "sauce différente".
Ils ont repris la dll de leur ancienne protection (version antérieure) et ont "juste" implémenté le SPEEnc, comme surcouche permettant de "cacher" la dll de la protection... pour ne pas dire, "cacher la misère"...
Comment détourner l'authentification du CD ?
En mettant un bp sur l'API GetDriveTypeA, on atterit au niveau de ce code :
On a le couple classique d'APIs GetLogicalDriveStingsA (chargé de renvoyer les lecteurs présents sur le système) / GetDriveTypeA (chargé d'en déterminer le type).
L'API GetFileAttributesA renvoie l'attribut du fichier LASERLOK.IN (attribut caché). Il suffit donc d'inverser le flag à ce niveau (ou d'y mettre un nop).
On peut également rendre inconditionnel le saut en 10005620 (cela aura le même effet).
Il est donc possible de cracker Laserlock SPEEnc sans posséder le CD original.
Contourner la vérification sur l'attribut du fichier LASERLOK.IN, suffit apparemment à contourner les autres vérifications sur la protection physique,
comme le laisse supposer certaines SDR : "_*NTCD_Last5 ChkSum error*", "_*NTCD_Prev ChkSum error*", "_*NTCD_SIGN not found*",
"_*NTCDFound*", etc...
Quoiqu'il en soit, Laserlock n'atteint pas le niveau de sécurité de certaines protections, à ce niveau.
En effet, la structure physique du CD (secteurs défectueux ou autres) sert généralement à empêcher la copie, mais est aussi utilisée par certaines protections
pour extraire une clé, utilisée pour décrypter l'exécutable du jeu...
Il faut alors posséder le CD original pour pouvoir le cracker, à moins que l'implémentation de l'algorithme de cryptage soit mauvaise (failles, bruteforce, etc...).
D) Perspectives et conclusion :
Généralisation :
Qu'est-ce qui change d'un jeu à l'autre ?
J'ai regardé un autre jeu, protégé par la même version du SPEEnc. Il s'agit de Codename : Outbreak...
Quand ils disent que Laserlock n'est pas générique, ceci me fait bien rire.
C'est exactement le même principe...
Les "variations" portent sur :
- L'image de base du SPEEnc change... On a 007A0000 au lieu de 00BA0000.
- L'OEP est toujours "décodé" par soustraction. Cette fois-ci, on retire 9F9B992D à la place de 9B6D10DB
- Les instructions du SPEEnc "fixé" ont des adresses légèrement différentes : le RET, qui fait sauter vers l'OEP est en 6C06 au lieu du 6D89 de tms2003...
Ceci doit s'expliquer par une introduction "pseudo-aléatoire" de blocs de code polymorphe dans le SPEEnc...
- L'API GetProcAddress est détournée deux fois dans l'IAT (en 50C244 et 50C3A4) au lieu d'une...
- L'IT est plus détruite que dans tms2003, puisque les pointeurs vers le nom des dlls ont également été effacés (Dword 1).
Autant dire rien de franchement fabuleux pour mériter l'appellation "non-générique" !!!
Pour infos (pour ce jeu) :
OEP = 8E3AC (VO)
IT commence en 50C000 (taille : 1D0)
IAT commence en 50C1F4 (taille : 9F0)
Voilà, vous avez assez d'informations pour faire votre propre unpacker ;-)
Créer un packer dans ce cas-ci est plus pédagogique
qu'autre chose ; très peu de jeux disposant de la protection Laserlock avec le SPEEnc sont sortis... (Codename : Outbreak, Tennis Masters Series 2003, Post Mortem et Warrior Kings, en France...).
Cette protection est finalement plus facile qu'il n'y paraît ;) ...
Elle contient encore beaucoup d'erreurs de conception et est très loin d'être incrackable, comme l'assurent ses auteurs...
Vous pouvez toujours remercier l'auteur pour cette protection amusante et intéressante ;
il a gentillement laissé son email...
Quant à Microïds, je suis assez déçu, qu'il ait fermé boutique et je ne comprends pas trop pourquoi...
Cette boîte française faisait de bons jeux comme Syberia 1 & 2, les Tennis Masters Series, War And Peace : 1796-1815, comparés aux merdes que sortent des studios français comme Davilex ou Cyanide, et qui tiennent eux encore le coup !!!
Ce studio a décidemment essayé toutes les protections disponibles du marché : Laserlock avec Tennis Masters Series 2003, Safedisc avec Syberia 2, Starforce avec War And Peace : 1796-1815, VOB ProtectCD avec Tennis Masters Series (le premier)... En vain...
Voilà c'en est fini des tutoriaux sur Laserlock :p
Enlever le CD-check de Codename : Outbreak :
Une fois Laserlock enlevé de Outbreak.exe, il reste un CD-check à enlever :
Le jeu se lance (sans les vidéos) et puis on accède au menu principal...
Mais les options "Jeu solo" et "Intro" sont grisés et non accessible :
De plus, un click sur "Jeu solo" provoque l'apparition du message d'erreur suivant (ce n'est pas le cas pour "Intro") :
Lol... J'hallucine, même si vous possédez l'original, vous passez en version limitée si vous n'insérez pas le CD !!!
De qui se moque-t-on ?
On va remédier à ça. On désassemble Outbreak.exe, par exemple avec W32Dasm. On cherche les APIs GetDriveTypeA / GetVolumeInformationA et on tombe sur ce code :
Cette routine de vérification du CD est très proche de celle de Tennis Masters Series 2003, excepté l'utilisation supplémentaire de l'API GetLogicalDriveStringsA...
Cette API détermine votre configuration en lecteurs de votre ordinateur, permettant de restreindre les tests par l'API GetDriveTypeA sur des lecteurs existant, et non sur ceux qui n'existent pas (comme x:\, y:\, z:\ ou autres...).
L'API GetDriveTypeA détermine pour un lecteur donné, s'il s'agit d'un lecteur CD.
Si tel est le cas, l'API GetVolumeInformationA récupère le volume du CD inséré (s'il y a).
Enfin, le volume récupéré est comparé à la chaîne "OUTBREAK"...
Cette routine est appelée par un call en 0046369B et un autre en 0048E0D8...
L'appel par le call en 0046369B n'est suivi d'aucun test, contrairement à celui en 0048E0D8 :
Vous aurez compris qu'il suffit de nopper le saut conditionnel en 0048E0DF, pour lancer le jeu (avec les vidéos) et d'y jouer sans le CD !
Et pour les fans de String Data References :
E) Remerciements :
Greetz :
ACiD BuRN, ArthaXerXès, Black Check, cdkiller (ProtectionID), CyberBob Jr, ^DAEMON^, Dark-Angel, DecOde12, diablo2oo2, Duelist, El-Caracol, EliCZ, Elraizer, evlncrn8, Fravia+, +Frog's Print, KeopS, Gádix, GRim@, G-RoM, Iczelion, kilby, Laxity, Lorian, LutiN NoIR, MackT, MrOcean, NeuRaL NoiSE, Neutral AtomX, Ni2, Nody, [NtSC], +ORC, Pedro, Peex, PEiD (snaker, Qwerton, Jibz), Psyché, Pulsar, +Pumqara, Ricardo Narvaja, Skuater, +Spath, +splaj, Stone, TeeJi, The Owl, tHeRaiN, TaMaMBoLo, +Tsehp, Tola, woodmann, +Xoanon, [yAtes], yoda ... et tous ceux que j'ai oublié et qui contribuent activement à la scene par leurs tutoriaux, tools et autres...
all the icedump team, ARTeam, CracksLatinos, DREAD, FRET, ShmeitCorp, UCF2000, UNPACKiNG GODS, TMG, all game groups...
All +HCU Students
All ppl of RCE Messageboard
these great sites :
http://207.218.156.34/krobar/index.html
http://arteam.accessroot.com/
http://tuts4you.com/
http://www.woodmann.net/forum/index.php
http://www.woodmann.net/yates/index.htm
Special Greetz :
Christal : Merci pour tout ce que tu as fait pour la scene française et ton aussi grande implication. Mes plus grands respects :)
Laserlock : Merci aux développeurs pour les quelques heures d'amusement. Bah oui, ça passe toujours trop vite :p
+Frog's Print & +Spath : Merci pour FrogsIce :-)
GRim@ : Merci pour tes tutoriaux "Beginner" avec lesquels j'ai commencé...
R!SC : Thanks, Master, for your tuts about commercial CD-Rom protections, like Safedisc, SecuROM, VOB ProtectCD, etc... :-)
All members of FFF ;-)
Message à TomRipley : On espère qu'il ne t'ait rien arrivé. Reviens !!!
Final words :
J'espère que vous aurez eu plaisir à lire ce tutorial.
Si l'étude de cette protection vous intéresse, je peux toujours vous uploader les cibles du tutorial. Il suffit pour cela de m'envoyer un mail à :
dWx5c3NlMjAwOV9mckB5YWhvby5mcg==
(base64 encoded)
J'ai essayé de faire une présentation originale "cracking" / "reversing" pour montrer qu'il était possible de cracker certaines protections commerciales avec un minimum de connaissances et sans même connaître l'existence de toutes les différentes techniques d'anti-cracking de la protection...
Un vague aperçu de ces différentes techniques suffit largement comme vous l'aurez aperçu...
Il est néanmoins bien plus intéressant de reverser ces techniques et facilite aussi grandement l'attaque ;)
Mais bon, la frontière entre les deux tend à s'effacer actuellement.
La réalité est toujours bien plus complexe qu'une simple dichotomie...
Concernant Tennis Masters Series 2003, je dirais que c'est l'un des meilleurs (des plus aboutis) jeux de tennis, sortis sur PC, avec les Top Spin...
C'est très loin du niveau médiocre / exécrable des Roland Garros sur PC !!!
"If you like a game, Buy it !"
uLysse, le 27 / 02 /07
"There is a crack, a crack in everything... That's how the light gets in."
Copyright © uLysse / FFF