CD check reverse engineering Lv3

décembre 29, 2014

Plutôt que de vous goinfrez de fois gras et de boire comme des pochetrons, quoi de mieux qu’un bon petit reverse engineering de cd check en cette période de noël ? Continuons notre avancé dans le reverse engineering de protection CD, place aujourd’hui à l’année 1998 avec 1 jeu qui aura marqué particulièrement son époque : Tomb raider 3 ! Oui madame !

Récemment j’ai retrouvé une vielle boite en carton contenant tout un tas de vieux jeux originaux. A l’époque je claquais allégrement mes quelques deniers dans les dernières nouveautés sortis. Je ne vous cache pas que les temps ont bien changé :) Bref, je suis notamment tombé sur une perle d’Eidos interactive, le jeu Tomb Raider 3 sorti en novembre 1998.

Je me souviens qu’à l’époque la protection de l’éditeur était assez novatrice. Non pas qu’elle était particulièrement compliquée, mais plutôt disons ; « originale ». Bien loin d’une protection plus complexe type LaserLock, SecuRom, SafeCast, CD-Cops, j’en passe et des meilleurs, Eidos nous a gratifié un mix vaseux : « Dummy Files + d’une TOC (Table Of Content) particulièrement tordu + d’un Oversize + d’un petit CD check pour terminer.

La première chose qui m’a surpris lorsque j’ai exploré le cd original dans mon lecteur, se sont les 5 fichiers portant l’extension *.AFP dont certain ayant une taille tout à fait hors du commun pour un simple CDRom. ( Awcs.afp = 680 megabytes, Config.afp = 116 octets, Neir.afp = 681 megabytes, Oket.afp = 680 megabytes, Vfaw.afp = 681 megabytes)

cdcheck3.1

 

Si à l’heure des DVD/BLU RAY.. quelques fichiers de 680Mo sur un support nous semble tout à fait anodin, dans les année 98 ou n’existait que les graveurs CD de 650/700mo, et ou un disque dur de 3 Go était du luxe, cela nous faisait beaucoup moins rire ! :)

Vous venez donc de faire votre première rencontre avec la protection ‘dummy files’. Le programme ira régulièrement lire des bytes dans ces fichiers afin de vérifier qu’ils sont intact. L’idéal serait de créer des fichiers portant le même nom, mais ne contenant qu’un seul byte et ensuite trouver dans Ollydebug l’adresse ou le programme lit ces fichiers. Cette protection était forcement assez facile à reconnaitre, de part le poids des fichiers mais egalement de l’extension .AFP qui sera repris sur d’autres protections de même type sur d’autres jeux du même éditeur. De manière générale elle est composée de 4 à 5 fichiers de grande taille, et d’un fichier de 1k (parfois illisible) mais reprenant en fait une sorte de liste des 4 autres :

De plus, lorsque l’on regarde la taille globale du cd on s’aperçoit qu’elle fait + de 659mo. Impossible donc de faire une simple copie de CD à CD avec les outils d’époque. Dite cette fois bonjour à la protection dite ‘Oversize’. :)

Partant du principe que je désire en faire une copie CD, je copie l’intégralité du CD, à l’exception des fichiers .AFP, que je recrée manuellement d’une taille d’1 octet à l’aide d’un éditeur de texte. Je tente de lancer le Tomb3.exe et là , pas de surprise la protection CD Check m’annonce la couleur :

cdcheck3.4

Les réjouissances sont annoncées, ne perdons pas une minute et dégainons Ollydebug dans l’espoir que les Referenced text String nous en apprennent plus concernant ce ‘Tomb Raider III CD ?’. Malheureusement peine perdu, mais pas totalement, car on y retrouve nos 4 Dummy Files.

 

cdcheck3.3

 

 

en cliquant sur le premier fichier DUMP : VFAW.AFP je me retrouve ici :

Nous pourrions tout a fait ici nous occuper de ce qui semble être un premier check :

0048D509     75 21          JNZ SHORT tomb3.0048D52C

regardons donc le call 00482800  juste avant : cdcheck3.7

il s’agit de la routine du Getlogicaldrive, cette fonction permet de demander quel sont les unités de disque valide, car il  vérifie si les données sont bien à la racine de l’unité, il va donc lister nos lecteurs, avec ensuite un getdrivetypeA que vous connaissez bien desormais et qui permet de demander le type d’unité disque, afin d’etre sure et certain qu’il s’agisse d’un CD et non d’un disque dur ou d’une cle USB. Jusque là pas de pb, je desire en faire une copie CD, donc inutile de s’y attarder. Vous avez sans doute compris que si vous desirez reproduire cet article a partir d’une cle USB, c’est ici qu’il vous faudra modifier votre GetDriveTypeA . je vous invite à reprendre mes articles précédents en la matière :)

Auquel cas vous allez vous retrouver avec ce message d’erreur :

cdcheck3.8

Bref passons, retournons maintenant à notre VFAW.AFP. Un click droit GO TO me permet d’aller au CALL appelant cette routine c’est a dire  4B2BE7

 

cdcheck3.6

 

Pourquoi vouloir regarder le CALL de provenance ? tout simplement histoire de vérifier

4B2BE7 => appel de la routine principale de protection avec dummy files
4B2BEC => test la valeur de AL et si AL = 0
4B2BEE => message indiquant tomb raider III CD?

Le registre AL et un registre de faible poids (8bits). Il est couramment utilisé comme un flag indiquant au reste du programme si la tache est terminée ou non.

Retournons à nouveau vers notre VFAW.AFP, cette fois je vais plutôt m’intéresser a ce qu’il y a en dessous, je vous détaillerez l’ensemble de la routine ensuite. :

0048D51B  |. 84C0           |TEST AL,AL .

Pourquoi je m’attarde sur cette ligne me direz vous ? comme je vous l’ai indiqué précédemment le registre AL est utilisé comme un indicateur permettant au programme de savoir si la tache est terminée ou non. En l’espèce ici notre routine de protection CD dummy files

En suivant le Jump if Equal : 0048D51D  |. 0F84 66010000  |JE tomb3.0048D689

j’arrive ici :

le XOR AL, AL m’indique ici que la valeur  de AL = 0

cdcheck3.5

 

C’est à dire :

Pour résumer le registre AL = 1, puis retourne, et arrivons vers un JNE  qui semble être le JNE indiquant que le CD est OK.   Explication : Pour chacun de nos fichiers DUMP, la routine de protection va opérer certains controles (vérifier présence ou nom du fichier ou encore la possibilité de lire des valeurs à l’intérieur du fichier) et tant que AL ne sera pas égale à 1, le programme estimera que le cd n’est pas original.

Je vais maintenant essayer de vous expliquez le fonctionnement l’ensemble de la routine du cd check afin que vous puissiez mieux comprendre. Attention vos yeux vont piquer un peu.

Résumons ;  J’ai essayé de détailler la routine de protection du cd/dummyfiles pour que cela vous paraisse + clair. Afin de faire fonctionner notre backup, il conviendrait donc d’effectuer quelques changements aux addresses :

et sans oublier de forcer le JUMP ici :

Mon cd gravé / avec l’exécutable cracké :) et les fichiers AFP de 1 octet fait desormais la taille de 530mo ;-) bye bye l’oversize :).

Prenez bien le temps de lire et relire  et rerelire votre Ollydebug,il n’est jamais évident des le premier coup d’oeil de comprendre la routine.

Voila cet article touche à sa fin, j’espère qu’il vous aura plus, en attendant la suite ne vous goinfrez pas trop pendant les fetes, et à très bientôt !