TUTORIAL sur StarForce v1.0 (le jeu War And Peace : 1796-1815) :

Protection commerciale : StarForce 1.0 (http://www.star-force.com)
Editeur : Microïds
Date de sortie : FR Jeudi 21 Novembre 2002
http://www.jeuxvideo.fr/fiche-war-and-peace-689-0-0.html
Site officiel : http://www.warandpeace-game.com
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)

Outils nécessaires :
Softice 4.01
Icedump / Frogsice
Procdump / LordPE
ImpREC / Revirgin
Hiew / Hex Workshop
W32Dasm
Adump
Masm v8
(Yoda's Process Patcher, facultativement)
Vous devez posséder le jeu original ou un clone fonctionnel pour pouvoir appliquer ce tutorial !!!
De plus, il s'agit de la version française du jeu War And Peace : 1796-1815...


OS sur laquelle je travaille: Win98 SE.
[ Vous pouvez bien sûr le cracker sur XP mais alors adaptez ce tutoriel.
Vous pouvez utiliser Driver Studio v3.2 ou d'autres debuggers ring 0. Pour Ollydbg, il vous faudra coder un driver pour le hook de l'int 01 & int 03.
Certains outils sont équivalents, donc vous n'êtes pas obligés de tous les avoir.]

Ce tutorial est détaillé de façon suivante :

A) Introduction et généralités
B) Localisation des vérifications d' intégrité des fichiers
C) Breaker sur l'OEP
D) Unpacker l'exécutable
E) Restaurer et reconstruire les imports
F) Perspectives et conclusions
G) Remerciements



A) Introduction et généralités :

1) Introduction :

StarForce était d'abord destiné pour l'Asie et la Russie, les taux de piratage y étant particulièrement élevés...
Jusqu'à la version 3 de StarForce, War And Peace : 1796-1815 est le seul jeu protégé par StarForce dont j'ai eu connaissance en Europe.
(Si vous connaissez d'autres jeux protégés par Starforce 1 / 2 en Europe, please mail-me).
Par contre, la diffusion de sa version 3 s'est généralisée en Europe, c'est le moins que l'on puisse dire...
Comme quoi, avec un bon marketing, n'importe quelle protection arrive bien vite à s'imposer...

StarForce 1 est caractérisé par un anneau bien visible à la périphérie du CD.
Cette protection demande la saisie d'une clé (CD-key/serial number). Elle ne sert que pour la protection et n'est donc pas utilisée par le jeu lui-même.
Le répertoire du jeu contient outre le fichier exécutable (compressé/crypté) du jeu, les librairies bass.dll et microids.dll.
La librairie bass.dll intervient dans la protection comme nous le verrons plus tard, mais microids.dll est la librairie de la protection (protect.dll) :





Dans la version 3 de la protection , elles portent des noms différents et complétement anodins : graphics.dll et fmod.dll ... (ex: Cycling Manager 3).
Au 1er lancement du jeu, la protection crée une .vxd dans le répertoire système : prodrv04.vxd .
Pour pouvoir cracker le jeu , il est nécessaire de posséder le jeu original ou un clone.
En ce qui concerne la copie, le mieux est d'utiliser Alcohol 120% , capable d'émuler StarForce 1 / 2, mais aussi StarForce 3, pourvu que l'on débranche les lecteurs IDE.
L'avantage réside dans le fait qu'en ayant une image du jeu dans le disque dur, il n'est plus nécessaire d'insérer le CD, puisque Alcohol émule la protection.
version d'Alcohol utilisée à l'époque:  1.9.2 Build 1705
Au cas où vous n'auriez qu'une copie "non-cloné", le fichier WP.mds (3 Ko) est fourni (nécessaire à l'émulation). Donc vous faites une image sur le DD de ce CD "non-cloné" et vous remplaçez le fichier .mds par celui fourni. N'oubliez pas de sélectionner l'émulation RMPS dans Alcohol.
Pour finir Starforce est considéré par beaucoup de gens comme l'une des plus dures protections commerciales concernant les jeux avec TAGES (MotoRacer 3, XIII, Beyond Good & Evil, Asterix and Obelix XXL 1 & 2, Fahrenheit, Desperados 2, etc..)... et ce d'autant plus qu'il y a de plus en plus de jeux protégés Starforce 3 ...
Qu'en est-il vraiment pour la version 1.0 ?

2) Protections mises en place :

Anti-softice (anti-debugger ) : MeltIce (facilement détectable avec frogsice)
API IsDebuggerPresent (pas valable pour Win98)
Vérification de l'intégrité des fichiers, "CRC"
Cryptage / compression (exécutable packé)
Anti-bpx / anti-tracing
APIs émulées

3) Mise en évidence des différentes protections :

Première chose, on lance le jeu sous SoftIce, boom un petit message nous avertissant que ce n'est pas bien d'avoir SI en mémoire... (fig. anti-SI)




Cet anti-softice est facilement détectable avec le fameux "Blue screen of death" de frogsice :
MeltIce localisé à l'adresse CS:6900C02F (microids.dll).
On lance icedump et on n'est plus embêté...

Avant de commencer le plan d'attaque, il n'y a rien de mieux que d'analyser dans le détail les différents fichiers et leurs PE avec procdump, par exemple.

Le fichier, qui m'a fait retenir le plus d'attention au départ était bass.dll puisque le nom des sections est effacé. (Cela me semblait suspect...)

Une première approche :
A l'OEP de cette dll, on trouve :



Ceci indique que bass.dll est packé... Avec quoi ? Je n'en sais rien. Peut-être un packer fait "maison". Si quelqu'un a des infos, please mail-me.
En traçant dans bass.dll et après en désassemblant avec IDA, je me suis vite aperçu que cette approche n'avait pas grand intérêt pour cette protection (de même pour son unpacking).
Ce n'est que mon avis...
En fait, elle sert de "loader"/"launcher" et passe la main à microids.dll ("lui prépare le terrain") tout en ayant un rôle important comme on le verra par la suite (dans l'émulation des APIs de WP.exe).
Finalement, j'ai abandonné cette 1ère approche...

Ensuite, on peut remarquer (et contre toute attente de ma part ) que microids.dll (une des librairies de la protection) est désassemblable...
Et dans la version 3 (par exempls, Cycling Manager 3), cette librairie est packée avec UPX...

Je relance WarAndPeace.exe (que l'on appelera WP.exe désormais) et boom "file infected by virus". Le fait de simplement éditer les sections de certains fichiers avec procdump les modifient !
En fait, deux cas se présentent :
- vous examinez bass.dll avec procdump et vous avez la boîte de dialogue suivante :



(c'est comme cela que j'ai su que la protection utilisait des dlls)
Vous n'avez pas ce problème avec LordPE .

- vous examinez WP.exe avec procdump/LordPE et vous en avez une autre :
(Au passage, vous avez là une belle confirmation de la protection utilisée...)



Ne faites donc pas comme moi la 1ère fois avec cette protection ( sauvegardez les 3 fichiers de la protection avant toute manipulation ).

Si cela n'est pas déjà fait, entrez la clé du jeu.
Elle est inscrite dans la base de registre dans :
[HKEY_CURRENT_USER\Software\Microids\War and Peace\Keys]
 

On peut détailler les différentes étapes de la protection :

1. Vérification de l'intégrité de bass.dll puis unpacking de celle-ci

2. Anti-softice dans microids.dll

3. Vérification de l'intégrité de microids.dll et WP.exe par microids.dll

4. CD-check :


5. Vérification de la présence du CD-key dans la base de registre

- si cette clé est absente/fausse, on a une boîte de dialogue la demandant :


- si la clé saisie est invalide, on a alors :


6. Protection proprement dite (lecture des erreurs/secteurs du CD dûe à la protection) et affichage du CD_CHECK_DIALOG :

(ici, émulation avec Alcohol 120%)


Si l'authentification du CD a échoué, on a la boîte suivante :



7. Enfin, on a mise en place de protections spécifiques : anti-bpx... ainsi que la décompression/décryptage de WP.exe puis son lancement.
Maintenant que l'on a quelques infos sur la protection : Let's fight ;-)




B) Localisation des vérifications d' intégrité des fichiers :
(on s'intéresse en particulier à WP.exe que l'on a modifié avec procdump).

Ces vérifications sont localisées dans microids.dll .
Il y a différentes façons de s'en apercevoir :
- un bpx MessageBoxA puis F12 nous renvoie dans microids.dll quand on lance un WP.exe modifié :



- une analyse des String References dans W32Dasm puisque le fichier est désassemblable...

Finalement en posant deux bpx (un en 6900C0AC et un autre en 6900C141), on s'aperçoit qu'il y a deux vérifications d'intégrité des fichiers :

Le premier break nous amène en CS:6900C0AC je 6900C0B9

Un r fl z puis F5 nous fait breaker en CS:6900C141 je 6900C159
(String References en 6900C0B2 et 6900C147 dans W32Dasm).

1ère vérification :



En y réfléchissant, quand on met un bpx, Softice remplace à l'adresse de celui-ci le code par une int 03 (CC).
Pour éviter cette modification en mémoire, on peut mettre un bpx à l'adresse 6900C02F (breakpoint classique).
(anti-SI situé avant le CRC ), puis bc* (effacement des breakpoints), puis un bpr 6900C0AC 6900C0AD R (memory breakpoint).
On breake en 6900C0AC et on obtient :
eax = 0F62AF80 et ecx = 0F62AF80
WP.exe étant modifié, c'est donc la vérification de microids.dll .
Si l'on pose un bpx en mémoire dans microids.dll, on a alors ecx différent de 0F62AF80...
conclusion : eax = résultat que l'on devrait avoir (référence)
                  ecx = résultat "calculé" que l'on a, suivant la modification ou non de microids.dll en mémoire.

Pour éviter cette vérification, le mieux est encore de poser des bpm, car les bpr font crasher le programme dès qu'on le relance et les bpx modifient microids.dll en mémoire.

L'algorithme permettant la vérification de l'intégrité de microïds.dll est le suivant :



Après l'exécution de l'instruction en 6900C080, eax = 1000 (offset du début de la section .text),
edx = 69000000 (image base) et esi = C000 (taille du bloc à vérifier). [bloc : crc.dat fourni].

Il s'agit d'un CRC-32. On d'ailleurs la confirmation avec HexWorkShop :




2ème vérification :

6900C13F cmp [ebx], eax
6900C141 je 6900C159

Si WP.exe est modifié avec procdump (comme on l'a vu précédemment),
en 6900C13F cmp dword ptr [ebx], eax
on a : eax = 3DCCE412
         ebx = 00400114 et [ebx] = 2F03778A

Si WP.exe est intact,
eax = 2F03778A
concusion : eax = résultat calculé
                 [ebx] = référence (ce que l'on devrait avoir)

Modifier les instructions en mémoire (par exemple en 6900C0A8 ou en 6900C141) fait crasher le programme juste après l'affichage du CD_CHECK_DIALOG. De façon logique, il en est de même pour une modification définitive (avec hiew par exemple). En posant un bpr à ces adresses, on aboutit à ce code (avec ecx pointant sur ces adresses) :



Le programme doit certainement utiliser les valeurs de certaines "zones sensibles" comme celles évoquées précédemment pour décrypter d'autres parties du programme.

Remarque :
Pour les fans de String Data References, on trouve ça :



EDIT: Si vous voulez comprendre comment du code d'une dll peut être exécuté avant celui de l'exécutable, vous pouvez regarder l'exemple (source + binaire) fourni par BeatriX, ici.


C) Breaker sur l'OEP :

Avec l'expérience, on se dit fichier packé , donc bpx getversion (ou sur tout autre API au démarrage de l'exécutable), pour breaker juste après l'OEP.
On le fait et boom crash de Softice... Ca, ce n'est pas vraiment marrant et j'en connais, qui diraient "What's this fuck ?"
;-)
Comme on le verra plus tard, c'est normal : il y a de l'anti-tracing / anti-bpx.
Maintenant cette technique du bpx getversion est bien connue des protectionnistes...
Mais nous n'allons pas nous décourager si vite...

En gros, je dirais qu'il y a 3 méthodes pour breaker à l'OEP d'un programme sans compter celle d'avant, lorsque l'on connaît l' OEP du programme :

- patch de manière définitive à l'OEP en int 03 (CC) puis bpint 03 pour breaker.
inconvénient : CRC ou autre vérification d'intégrité. De plus, il faut que les instructions au niveau de l'OEP ne soient pas affectées par un décryptage ou une décompression (donc pas utilisable pour un fichier packé).
- utilisation d'un memory patcher tel que R!SC Patch Process ou Yoda's Process Patcher. Patch à l'OEP en int 03 (CC) puis bpint 03.
La modification ne se faisant qu'en mémoire, cela évite beaucoup de checksums et autres CRCs.
- ma méthode (je ne l'ai jamais vu utilisée ailleurs) : modification de l'OEP vers une zone "nulle" dans le PE et Softice redonnera la main pour corriger le bug lorqu'on le lançera. :-)
 
La 1ère méthode n'est pas utilisable pour des raisons évidentes...
La 2ème entraîne normalement un crash du programme (opération non conforme), certainement à cause d'autres vérifications faites par StarForce.
Ici, il est préférable d'utiliser la troisième méthode.
Note : Bien évidemment, tout bpx, bp et bpr au niveau de l'OEP provoque également un crash de windows. Et l'on n'a plus qu'à rebooter, dans ce cas...

Finalement j'ai mis l'entrypoint à 00000002 comme RVA pour qu'il n'exécute aucun code.
L'entrypoint de WP.exe était de 3DFC88 (RVA).
Et comme l'on a vu comment détourner le CRC portant sur WP.exe, l'unpacking de celui-ci est proche :-)
Attention : modifier l'exécutable de la sorte peut affoler votre antivirus (Norton, pour ne citer que lui...)

Remarque :

On peut utiliser la 3ème méthode pour étudier bass.dll
L'entrypoint de bass.dll est de 56043 (RVA), on peut le changer en 56044 pour breaker. Sous sice, on fait r eip vraie_valeur_de_OEP cad ici r eip 56043, on est à l'OEP de bass.dll et on peut alors continuer comme si de rien n'était ;-)
Enfin, presque... puisque bass.dll n'aime pas être modifiée.

On peut alors utiliser Yoda's Process Patcher pour modifier en mémoire l'opcode B8 par CC (2ème méthode).
Ensuite un bpint 03 sous Softice nous permettra de breaker dans bass.dll à l'OEP au lancement du patcher.
Une modification de bass.dll est repérée par la dll elle-même :



Cette approche n'ayant pas été suffisamment intéressante pour moi, je me suis dit que l'on pourrait peut-être localiser les vérifications d'intégrité des fichiers microids.dll et WP.exe
Et une approche avec WP.exe modifié par procdump semble être une bonne approche...


D) Unpacker l'exécutable WP.exe :

Comme on l'a vu précédemment, on met l'OEP à 00000002 (RVA) avec l'éditeur de PE de votre choix.
On peut aussi faire d'autres modifications. Et notamment, remettre le bon nombre de sections dans le PE de WP.exe (cela évitera le crash de procdump lors du dump...).
Car un examen rapide avec Procdump laisse penser qu'il n'y a que 5 sections alors que réellement il y a 8 sections en tout :



Vous n'avez juste qu'à remplacer 05 par 08 à l'offset 0x10E avec un éditeur hexadécimal :



Pour poser le bpm 6900C141 X (permettra de contourner le CRC et cela à cause de la modification de WP.exe) :
- On tape Ctrl+D sous Windows et on met un bpx MessageBoxA.
- Ctrl+D pour quitter SI.
- On lance WP.exe -> break sous SI -> F12 (On retourne immédiatement après le call [MessageBoxA] -> entrée pour quitter la boîte de dialogue -> Sous SI,
bc* puis bpm 6900C141 X (hardware breakpoint).

- On relance WP.exe -> break en 6900C141
- On tape r fl z pour contourner la vérification (CRC)
- puis sur F5 pour relancer l'application
- Softice nous redonne la main pour corriger ce bug ;-) (break en 400003)
Break due to Page Fault (0Eh),     Fault=0006
- r eip 7DFC88 (modifiaction de l'eip)
- puis u eip (affichage du code sur eip)



Il suffit de faire :
* a 7DFC88 et de taper jmp eip (remplace l'opcode 558B par EBFE)
* de relancer avec F5 pour lancer une boucle infinie
* de sélectionner le processus dans Procdump -> click droit -> full dump
options : Recompute Object Size
             Optimize PE structure
             Use actual import infos

Il ne reste plus qu'à restaurer les instructions :
007DFC88   55                                   PUSH EBP
007DFC89   8BEC                             MOV EBP,ESP
Cela peut être fait avec hiew (ou tout autre éditeur hexadécimal).

Note: N'oubliez pas de rectifier l'OEP dans le PE, aussi...
On obtient ainsi un fichier que l'on nommera dumped.exe . Etape [A]

Vous aurez remarqué que la rectification de l'OEP en mémoire et le relancement de WP.exe à l'aide de la touche F5 ne provoque aucun bug et lance le jeu.
Par contre le fait de tracer avec F10 (Step Over) ou de placer un bpx adresse_dans_WP puis de relancer provoque un crash de Softice : ça c'est plutôt chiant...
Au départ, je me demandais par quoi ceci pouvait-il bien être provoqué...
Nous n'allons pas abandonner en si bon chemin alors que WP.exe est décrypté (unpacké).

Nono, lui, il n'a même pas peur ;-)



En fait, il suffit de se rappeler de ceci :
Pour tracer pas à pas dans un programme, Softice utilise l'interruption matérielle 01. L'interruption matérielle 03 permet de stopper un programme en cours d'exécution et lorsque vous placez un breakpoint sur une adresse précise, Softice y place une int 03 , détournée bien-sûr, et de ce fait vous redonne la main à l'emplacement souhaité, en replaçant la ligne initiale bien entendu...

Ensuite, un rappel sur l' IDT de Pulsar s'impose :


L' IDT (Interrupt Descriptor Table) est comme son nom l'indique la table où sont stockées les adresses correspondantes aux interruptions...
Le mieux est de prendre pour exemple la bien connue int 03h. Quand le processeur rencontre un int, il va voir dans l'IDT quelle routine gère cette interruption puis l'appelle...
Rien de franchement fabuleux ici, sauf qu'il l'appelle en ring 0.
Regardons un dump des premiers bytes de mon IDT (les votres peuvent être différentes), (en utilisant la commande dd dans softice vous n'aurez pas à inverser l'ordre des bytes pour trouver les bonnes valeurs) :



En sachant que la première int est l'int0, on en déduit que les bytes concernant l'interruption 03h sont les suivants:

0028AFE0 C00EEE00

On trouve que le lowword de notre routine est AFE0 et le highword C00E, ce qui nous fait une adresse égale à C00EAFE0

(Remarque : pour trouver sous softice l'offset à laquelle est située l'IDT, faites IDT puis d IDT_base_donne_par_softice)

Donc lorsque Softice fait arrêter le programme à cause du bpm 6900C141 X, à l' IDT, on a :
(les valeurs dans l'IDT changent à chaque redémarrage de Windows)



Lorsque l'on breake et que l'on se repositionne sur l'OEP, c'était devenu :



Pas étonnant que Softice crashe...
Changez les lowword et highword pour les interruptions 01 et 03 par leurs valeurs initiales et tout rentrera dans l'ordre :-)
Vous pourrez ainsi tracer et poser des breakpoints à différentes adresses dans WP.exe ...

Mais on n'est pas encore au bout de nos surprises. Car, au cas où vous ne l'aviez pas encore remarqué :
il va falloir restaurer et reconstruire les imports (voir (1) dans la capture d'écran à l'OEP ci-dessus).
Et donc ce n'est pas plus mal que l'on puisse tracer dans WP.exe pour pouvoir comprendre ce qui se passe au niveau des imports. En plus, un bpx API à ce niveau ne provoquera aucun break...

Je croyais à ce niveau que j'avais cracké 98% de la protection: j'étais loin de la réalité, car la restauration / reconstruction des imports est de loin la partie la plus intéressante et la plus subtile de la protection, il faut bien l'avouer...


E) Restaurer et reconstruire les imports :

1) Restaurer les imports :

On localise facilement l'IAT, elle est située de l'adresse 837000 jusqu'à 8375B0.
Pour certains imports, on remarque que les Call API sont redirigés vers des routines dans bass.dll .
C'est le cas des imports KERNEL : de 8370B8 à 83715C
                  des imports USER       : de 8374DC à 837558
et de deux autres imports isolés en 8375A8 et 8375AC


.
.
.
etc
.
.
.


Le dump de l'IAT est fourni (IAT0.dat).

Remarque :
Comme il y a un reroutage au niveau de certaines APIs, on peut déjà voir ce qu'il y a dans bass.dll, par exemple, avec un u 01AA0000 :
(c'est l'adresse 8370CO qui pointe vers 01AA0000)

Pour mieux comprendre, traçons à l'intérieur du call [008370D0] situé à l'adresse 007C525E :
(le mieux étant de poser un bpm 007C525E X)



On se retrouve alors dans bass.dll :




Après le RET 0004, on retourne dans le code de WP.exe c-à-d en 007C5264.
Nul doute que c'est une émulation d'API.(on a un MOV EAX,BFFA1D67 et un CALL BFF992D1, qui sont très louches !).

Les APIs sont en fait recopiées en partie et remaniées. Ces légères modifications consistent en l'ajout d'instructions inutiles (nop et jmp eip+2) ou d'instructions équivalentes :

PUSH EDI est remplacé par :
XCHG EAX,EDI
PUSH EAX
XCHG EDI,EAX

ou bien, PUSH BFFA1D67 est remplacé par :
PUSH EAX
MOV EAX,BFFA1D67
XCHG EAX,[ESP]

On comprend ainsi que les bpx API et les API rebuilders sont inutiles à ce stade.
La routine ci-dessus n'est donc pas une routine de redirection vers une API.

Le problème est de savoir quelle est l'API émulée...
J'ai remarqué que pour de nombreuses APIs Kernel, on a souvent au début de celles-ci un push BFFxxxxx remplacé dans l'API émulée par un mov eax,BFFxxxxx.
Dans le cas précédent, il suffit de faire un s BFF70000 l 30000000 67,1D,FA,BF pour retrouver l'API concernée.(l'adresse BFF70000 étant l'adresse où est chargée kernel.dll sous Win98 SE).
Les adresses des APIs varient suivant l'OS sur laquelle on travaille.
Ici on a donc LoadLibraryA.
 


Le saut en BFF776F2 de l'API LoadLibraryA nous fait arriver ici :



Au final on a une API émulée équivalente à l'API initialement référencée dans le programme avant qu'il ne soit protégé...

Le problème de reconstruction des APIs dans cette protection est certainement ce qui est le plus délicat et le plus subtil.
En effet, on ne peut pas faire un "call fixer" comme pour les protections Safedisc et SecuROM , puisqu'il ne s'agit pas ici de simples redirections vers les APIs (en ce qui concerne les imports Kernel et User).
Le programme WP.exe, une fois unpacké n'entre plus en contact et n'exécute plus beaucoup de code à l'intérieur des librairies Kernel et User et c'est cela qui est ennuyeux...

Ce qu'il faut faire, c'est breaker à l'initialisation de l'IAT sans pour autant crasher SI (à cause des modifications dans l'IDT)
Note : j'ai évité de poser des bpx sur GetProcAddress (semble ne pas être utilisé par SF) et LoadLibraryA. Je n'aime pas faire crasher windows pour une protection ;-)
On lance WP.exe, on breake à cause du bpm 6900C141 X puis on fait r fl z et on relance avec F5.

The wrong way :
Ensuite, lorsque SF_CDCHECK_DIALOG s'affiche,
on fait CTRL+D (le faire plutôt vers la fin de l'affichage de SF_CDCHECK_DIALOG et avant le
break dans WP.exe).
Ensuite, vérifiez l'IDT et faites les modifications, qui s'imposent .
S'il n'y a pas encore eu modification dans l'IDT, c'est que vous avez breaké trop tôt...
Passez ensuite à l'étape (*).
(Si l'on breake trop rapidement [Ctrl+D], que l'on pose le bpr de l'étape (*) et qu'on relance, on crashe en 01A402BC).

The good way :
Après le r fl z et avant de relancer l'application, faites un bpr 837000 8375B0 RW (lecture / écriture).
On atterrit en :



N'oubliez pas de faire tout de suite les modifications dans l'IDT...
Maintenant, on veut déterminer quelle est la routine, qui initialise l'IAT (écrit dans l'IAT, l'adresse des APIs émulées).
On efface ce point d'arrêt et on met le bpr suivant :
(*) On met un bpr 837000 8375B0 W (écriture dans l'IAT).
Normalement, on arrive en 6900114D mov [ebx], ecx dans microids.dll
ebx = adresse dans l'IAT (section .rdata de WP.exe)
ecx = adresse de l'API émulée

Une fois à l'adresse 6900114D, on peut effacer ce bpr et mettre un bpr 8370B8 83715C W à la place puisque l'on ne s'intéresse qu'aux APIs Kernel.
En appuyant plusieurs fois sur F5, on voit progressivement les adresses suivantes pointer vers une routine de la dll :



Donc lorsque l'on aura au niveau du mov [ebx], ecx
ebx = 8370CC
ecx = 1B30000
on pourra mettre un bpr 1B40000 1B40200 W pour connaître les instructions qui écrivent la routine de l'API émulée dans bass.dll
On arrive en 15B659B...



Au niveau d'instructions relativement proches de celles-ci, on a d'abord détermination de l'adresse de l'API à émuler. Ensuite, d'autres instructions se chargent d'émuler l'API concernée en recopiant des blocs d'instructions de l'API elle-même avec des variations, dans bass.dll . Puis ces instructions passent le relais à microids.dll, qui par son instruction mov [ebx], ecx en 6900114D se charge de copier l'adresse de l'API émulée dans .rdata . Ainsi, lorsque l'on breake la 1ère fois en 15B659B, on a ebx = BFF776D0, correspondant à l'adresse de l'API LoadLibraryA.
Le problème, c'est que cette instruction est exécutée plusieurs fois avant de passer le relais à microids.dll et que ebx ne pointe pas toujours exactement sur l'adresse de la 1ère instruction de l'API concernée...
Or, ce qui nous intéresse, c'est justement une instruction avec un registre pointant  toujours exactement sur l'adresse de la 1ère instruction de cette API.

Dans SoftIce, on désactive tous les points d'arrêt précédents sauf le bpm 01A7:6900114D X, pour pouvoir y  breaker.
Une fois arrêté sur cette instruction de microids.dll, on désactive son bpm et on rajoute un bpr 15B0000 15C0000 R.
En relançant et en traçant un tout petit peu, on arrive à l'instruction, qui détermine
l'adresse de l'API à émuler :



Et un peu plus loin, on a les instructions, qui émulent ces APIs...



avec en 015B660D, ebx = adresse de l'API à traiter (ebx pointe justement toujours sur l'adresse de la 1ère instruction de l'API).
Les blocs d'instructions sont recopiés dans bass.dll par MOV [EAX+EBP-01],BL...
Hum, It's time to be destructive :)

1ère tentative pour restaurer les imports :

C'est alors que j'ai codé cette petite routine en asm... (voir WP1.asm livré avec ce tutoriel)
Que va-t-elle donc faire ?
D'abord une petite explication sur le jmp far (long) : (c'est pour expliquer les patches en jmp Adump1 et autres à divers endroits du code)

adresse1 : jmp adresse2
adresse1+5 : instruction suivante
...
adresse2 : ...

l'opcode qui correspond au saut long est E9
l'opcode qui détermine l'endroit où sauter est (adresse2)-(adresse1+5) soit (adresse2-adresse1)-5

Prenons un exemple quelconque:
:0075C9AA E99A7D0000 jmp 00764749
:0075C9AF 90 nop

l'adresse où l'on doit sauter est 00764749
l'adresse où se trouve la saut est 0075C9AA
l'adresse de l'instruction suivant le jmp est 0075C9AF
(00764749-0075C9AF)=00007D9A soit 9A7D0000 (inversé)
l'opcode correspondant au saut jmp 00764749 en 0075C9AA est donc:
E9 9A7D0000

La routine Adump 1 :
On va détourner l'adresse 015B644E vers Adump1, qui va se charger de sauvegarder l'adresse de l'API (ebx) que Starforce veut émuler (On la sauvegarde à l'adresse Adump+100h).
Ensuite, on écrase l'instruction jmp Adump1 par les instructions d'origine en 015B644E, pour éviter toute détection et l'on effectue un saut sur celles-ci pour ne pas perturber le cours du programme...

La routine Adump 2 :
Une fois le programme arrivé en 6900114D (microids.dll), on empêche Starforce de mettre l'adresse de l'API émulée dans l'IAT (section .rdata) en détournant vers Adump2 par un jump. Cette routine va mettre dans l'IAT, l'adresse de l'API originelle (sauvegardée précedemment à l'adresse Adump+100h)... En même temps, on restaure notre jump Adump1 en 015B644E, pour la prochaine API à traiter.
Par contre, contrairement à la routine Adump1, on laisse le jump Adump2 en 6900114D. Du coup, on est obligé d'incorporer dans notre deuxième routine les instructions écrasées dans microids.dll par notre jmp Adump2 (en majuscules dans la source ci-dessous) et l'on saute ensuite 6900115D pour reprendre le cours du programme...
title imports_fixer
.386
.model small, stdcall
option casemap :none

.code
Adump       equ 83E6E000h
_TextOffset equ 00401000h
_IATStart   equ 00837000h
_IATEnd     equ 008375B0h

start:


Adump1:
pushad
mov eax, Adump
mov [eax+100h], ebx               -> sauvegarde l'adresse de l'API émulée  
mov eax,015B644Eh                 |
mov dword ptr [eax], 0F9800B8Ah   | restaure les instructions
add eax,04                        | en 015B644E
mov byte ptr [eax],68h            |
popad
;jmp cs:015B644E
db 90h,90h,90h,90h,90h,90h

Adump2:
pushf
cmp ebx,_IATStart                         | Est-ce que
jb here1                                  | microids.dll touche
cmp ebx,_IATEnd                           | à l'IAT (section .rdata) ?
ja here1                                  |
pushad
mov eax,offset Adump1-_TextOffset+Adump   |
mov ecx, 015B6453h                        |
sub eax, ecx                              | restaure le jmp
83E6E000 (Adump1)
mov byte ptr [ecx-05],0E9h                | en 015B644E
mov [ecx-04], eax                         |
mov eax, Adump
mov ecx,[eax+100h]
mov [ebx], ecx                            -> patche dans la section .rdata avec
popad                                        l'adresse de l'API émulée
popf
jmp here2
here1:
popf
mov [ebx], ecx
here2:
ADD DWORD PTR [EDI+10h],06         | exécute les instructions "effaçées"
ADD EDX,[EDI+14h]                  | à partir de 6900114F
MOV DWORD PTR [EDI+14h],00000000   |
;jmp cs:6900115D
db 90h,90h,90h,90h,90h,90h

end start

EDIT: Je me suis bien compliqué la vie avec des sauts longs...
L'utilisation de push xxxxxxxx / ret aurait bien été plus simple, mais je n'ai pas envie de réécrire cette routine :p.

Vous devez bien sûr changer la valeur Adump equ 83E6E000h avec celle que vous avez en tapant r dans adump. On assemble et on charge cette routine en mémoire par la commande l d'adump.
On recommence ce qui a été décrit précédemment :
bpm 6900C141 X puis on fait r fl z et on relance avec F5
bpr 837000 8375B0 RW (puis changements dans l'IDT au break...)
bc*
On met cette fois-ci un bpm 015B644E X pour y breaker.

Une fois arrêté à cette adresse, on assemble sous SoftIce par la commande a  eip, de manière à obtenir :
15B644E jmp 83E6E000 (c-à-d jmp Adump1)
En même temps, pour rendre fonctionnelle notre routine, on doit aussi assembler aux adresses suivantes :
6900114D jmp 83E6E024 (c-à-d jmp Adump2)
83E6E01E jmp 15B644E
83E6E06E jmp 6900115D

Il n' y a plus qu'à relancer et attendre le "break" en 400003, après avoir effacé tous les points d'arrêt...
Puis, on jette un oeil aux imports et là : What's this fuck ?!
C'est pas encore ça... L'IAT est remplie par une valeur unique, à savoir BFF5182B c-à-d l'adresse de la
1ère API traitée... Etrange...

Remarque:
L'intérêt de restaurer les instructions d'origine est d'éviter d'autres vérifications faites par StarForce comme vous  le  verrez par la suite...


2ème tentative pour restaurer les imports :

Je me suis dit que l'on pourrait peut-être remonter plus haut dans les instructions pour déterminer celle, qui  donne  l'adresse de l'API à émuler. Pour cela on relance WP.exe et on met un bpm 015B644E X.
Dès qu'on y breake, on tape un d esp+30 pour regarder les valeurs dans la pile :



(avec ESP=00DCE6FC)
On effaçe ce bpm et on en met un en 6900114D. Lorsque l'on breake à cette adresse, on le désactive
et on met un bpr DCE72C DCE73C W. Et c'est là que l'on trouve l'adresse suivante :
01A7:015B0043 89742430               MOV [ESP+30],ESI
où ESI est l'adresse de l'API émulée...
Le début des instructions est :




J'ai codé la même routine en asm, en l'adaptant à ces adresses pour comprendre le problème avec la routine
précédente... (voir WP2.asm)

On recommence tout ce qui a été décrit précédemment et on met cette fois-ci un bpm 015B0033 X (ou avec un bpr) pour  breaker.
Une fois arrêté à cette adresse, on assemble sous SoftIce par la commande a  eip, de manière à obtenir :
15B0033 jmp 83E6E000 (c-à-d jmp Adump1)
En même temps, pour rendre fonctionnelle notre routine, on doit aussi assembler aux adresses suivantes :
6900114D jmp 83E6E024 (c-à-d jmp Adump2)
83E6E01E jmp 15B0033
83E6E06E jmp 6900115D
Cette fois, on désactive le bpm 015B0033 X et on ajoute un bpm 6900114D X (dans microids.dll) pour y breaker. Une fois arrêté sur cette instruction, on désactive le 2ème bpm et on réactive le 1er...
Et là on s'aperçoit, qu'il n'y a pas de break sur le 1er bpm comme prévu.
Notre instruction en 15B0033 : jmp 83E6E000 (c-à-d jmp Adump1) a été effaçée  (écrasée) par les instructions d'origine, ce qui est normal (routine Adump1)...

Le problème intervient donc entre les deux routines.
Il convient de trouver immédiatemment le coupable ;-).

Ce n'est pas très dur. Un bpr 15B0000 15B0043 R nous amène aux instructions suivantes :



L'instruction en 00DCE9AD parcourt / lit donc le code en 015B0000. Une sorte de hash est calculé à a partir des octets lus dans cette zone mémoire. Ce hash permet en fait de retrouver l'adresse de cette zone mémoire pour y revenir après. Si le hash est mauvais, la routine en 015B0000 n'est plus jamais executée et l'IAT n'est plus résolue. Ceci explique qu'avec ce patch (modifications de la zone mémoire en 015B0000), notre IAT contient un unique et même pointeur...

Ces instructions ci-dessus (zone mémoire en 00DCE960) sont réécrites par l'instruction mov dword ptr [ebx], ecx de microids.dll (en 6900114D), celle qui écrit également dans l'IAT, les adresses des APIs émulées...

Il s'agit donc d'une interaction entre 3 zones de codes exécutables :
- 015B002F où eax pointe vers l'adresse de l'API à émuler, pour la traiter ensuite...
- 6900114D (dans microids.dll), qui remplace dans l'IAT l'adresse de l'API émulée entre autres, mais aussi réécrit les instructions au niveau de la zone suivante...
- 00DCE9AD, qui lit les instructions dans la 1ère zone (celle qui émule l'API en retouchant les instructions...).
Cela permet d'extraire un hash, permettant de retrouver l'adresse de la 1ère zone, pour y retourner, par après.
Et ainsi de suite en boucle... (pour chaque API à traiter).



Note : Il faut vérifier et spécifier parfois les segments avant l'adresse pour placer les bpm et bpr, car SoftIce ne nous les met pas toujours à l'endroit, où l'on voudrait...

3ème tentative pour restaurer les imports :

La dernière tentative et la bonne :-)
(voir WP3.asm)

La routine Adump 1 :
On va détourner l'adresse 015B0033 vers Adump1, qui va se charger de sauvegarder l'adresse de l'API (eax) que Starforce veut émuler (On la sauvegarde à l'adresse Adump+100h).
Ensuite, on écrase l'instruction jmp Adump1 par les instructions d'origine en 015B0033, pour éviter toute détection et l'on effectue un saut sur celles-ci pour ne pas perturber le cours du programme...

La routine Adump 2 :
- Elle détermine d'abord si microids.dll (6900114D) est en train de réécrire les instructions au niveau de 00DCE9AD...
Si elle est en train d'écrire en 00DCE9C8, c'est qu'elle déjà a réécrit en 00DCE9C8-4 et donc l'instruction en 00DCE9C2 peut être détournée (par un jmp Adump3)...
Pourquoi détourner en 00DCE9C2 ?
Parce qu'une fois que l'on sera à cette instruction, la lecture (et donc la détection de modifications) au niveau de 015B0000 (et donc en 015B0033) sera terminée (lecture effectuée par la routine en 00DCE9AD)...
- Elle détermine également si microids.dll tente de patcher l'IAT...
Deux cas se présentent :
1) Elle patche l'IAT pour les APIs non émulées par Starforce. Alors on laisse faire et l'on continue le programme normalement...
2) Elle patche l'IAT pour les APIs émulées par Starforce. On ne laisse pas faire et l'on patche par l'adresse originelle de l'API que Starforce veut émuler, puis l'on continue...

La routine Adump 3 :
Elle sert à restaurer le jmp Adump1 en 015B0033 (la réécriture au niveau de cette zone étant terminée :))
Elle restaure également les instructions d'origine en 00DCE9C2 (le jmp Adump3 est supprimé)...

title imports_fixer
.386
.model small, stdcall
option casemap :none

.code
Adump       equ 83E6E000h
_TextOffset equ 00401000h
_IATStart   equ 00837000h
_IATEnd     equ 008375B0h

start:


Adump1:
pushad
mov ebx, Adump
mov [ebx+100h], eax               -> sauvegarde l'adresse de l'API, qui doit être émulée  
mov ebx,015B0033h                 |
mov dword ptr [ebx], 01C244C8Bh   | restaure les instructions
add ebx,04                        | en 015B0033
mov byte ptr [ebx], 33h           |
popad
;jmp cs:015B0033
db 90h,90h,90h,90h,90h,90h

Adump2:
pushf
cmp ebx, 00DCE9C8h                | Microids.dll, est-il en train de réécrire
jne here3                         | les instructions en 00DCE9C8,
cmp ecx, 0E58B1189h               | par son MOV [EBX],ECX
jne here3                         | (à l'adresse 01A7:6900114D) ?
pushad
mov eax, offset Adump3-_TextOffset+Adump | Microids.dll veut réécrire en 00DCE9C8...
mov ecx, 00DCE9C7h                       | C'est bien, on peut maintenant détourner les
sub eax, ecx                             | instructions juste au-dessus :-)
mov byte ptr [ecx-05], 0E9h              | Détournons vers Adump3 par un jump...
mov [ecx-04], eax                        |
popad
jmp here1                                | Maintenant, Starforce, tu peux réécrire en 00DCE9C8, si ça t'amuses ;-)
here3:
cmp ebx, _IATStart                       | Microids.dll, est-il en train d'écrire dans l'IAT?
jb here1                                 | Quoi ??? Tu veux mettre l'adresse d'une API émulée?
cmp ebx, _IATEnd                         | Pas question...
ja here1                                 |
cmp ecx,01500000h                        | Ce n'est pas une API émulée
jb here1                                 | C'est bon...
cmp ecx,01E00000h                        |
ja here1                                 | On saute :)
pushad                                   |
mov eax, Adump                           | Tu vas mettre plutôt l'adresse de l'API,
mov ecx, [eax+100h]                      | sauvegardée dans la routine Adump1 :))
mov [ebx], ecx                           |
popad
popf
jmp here2
here1:
popf
mov [ebx], ecx
here2:
ADD DWORD PTR [EDI+10h],06               | exécute les instructions "effaçées"
ADD EDX,[EDI+14h]                        | à partir de 6900114F
MOV DWORD PTR [EDI+14h],00000000         |
;jmp cs:6900115D
db 90h,90h,90h,90h,90h,90h

Adump3:
pushad
mov eax, Adump
mov ecx, 015B0038h
sub eax, ecx
mov byte ptr [ecx-05], 0E9h              | restaure le jmp Adump1
mov [ecx-04], eax                        | en 015B0033
mov ecx, 00DCE9C2h
mov dword ptr [ecx], 8B104D8Bh           |
add ecx, 04                              | restaure les instructions originales en 00DCE9C2
mov byte ptr [ecx], 55h                  |
popad
;jmp cs:00DCE9C2
db 90h,90h,90h,90h,90h,90h

end start

On recommence encore une fois, ce qui a été décrit précédemment, en mettant un bpm 015B0033 X (ou avec un bpr) pour  breaker.
Une fois arrêté à cette adresse, on assemble sous SoftIce par la commande a  eip, de manière à obtenir :
15B0033 jmp 83E6E000 (c-à-d jmp Adump1)
En même temps, pour rendre fonctionnelle notre routine, on doit aussi assembler aux adresses suivantes :
6900114D jmp 83E6E02F (c-à-d jmp Adump2)
83E6E029 jmp 15B0033
83E6E09D jmp 6900115D
83E6E0CF jmp DCE9C2
On relance et finalement on breake avec toutes nos APIs restaurées.
On peut dumper, ici et faire les modifications de l'étape [A], on gagne ainsi une étape.
Sinon, on peut faire un dump de l'IAT fixée par un /DUMP 837000 5B0 C:\IAT.dat . Merci Icedump :-)
Il suffit ensuite de copier cette IAT dans le dumped.exe de l'étape [A]. Etape [B]
On peut le lancer pour voir et ça lance encore la protection...
De toute façon, si le jeu se serait lancé, il n'aurait marché que sur l'OS, sur lequel on l'a cracké : c'est plutôt ennuyeux :-(
On va donc reconstruire les imports...

EDIT: Les versions 3 et supérieures de Starforce n'émulent plus la totalité des APIs d'une librairie donnée (ex: kernel32.dll, user32.dll).
Une très belle méthode pour restaurer les imports de l'IAT est de dépolymorphiser les APIs émulées par SF, pour retrouver les APIs en question.
C'est la méthode que Baboon a appliquée. Son article est ici.
Il a même développé un plugin pour ImpRec :-)

2) Reconstruire les imports :
Bah, on va utiliser le magnifique ImpRec...
Mais, avant on va nettoyer le dump.exe de l'étape [B], en supprimant les 4 sections .idata :)
Cela fera plus propre pour rajouter notre nouvelle table :-)
On lance ProcDump et l'on ouvre dumped.exe par la fonction PE Editor. On s'occupe des 4 dernière section .idata, on clique droit -> kill section.
Les sections .idata ont disparu de notre PE. On n'a plus qu'à les enlever du disque (du fichier dumped.exe).
On lance HexWorkShop, Edit, Goto 004DD000 (le Raw Offset de la 1ère section .idata) puis Edit, Select Block 00004000 (taille d'une section x 4), puis click droit , Delete...
On obtient un dumped.exe tout propre. Etape [C]

Ca y est, on peut enfin reconstruire les imports :-)
Le mieux, c'est d'avoir lancé une boucle infinie à L'OEP au niveau de l'étape [B], après la restauration de l'IAT.
Sinon il suffit de relance le WP.exe à OEP détourné, de faire un /LOAD 837000 5B0 C:\IAT.dat à l'aide de IceDump et de lancer une boucle infinie à l'OEP...
On lance donc Imprec :



Et l'on corrige les valeurs de manière à avoir ceci :



Note : La 1ère fois, j'avais selectionné bass.dll dans ImpRec et avais fait un Delete Thunk.
Le programme n'a pas trop apprécié...
(Je croyais en effet que cette .dll ne servait qu'à la protection mais apparemment il s'agit d'une .dll du jeu détournée par la protection, notamment pour l'émulation des APIs...)

On n'a plus qu'à cliquer sur Fix Dump en sélectionnant le dumped.exe de l'étape [C]...
On le lance alors et ça ne marche pas...
Nan je déconne :) [Il marche même sur XP :p]
On peut aussi effacer microids.dll ; elle ne sert plus à rien, maintenant...


Tutorial commencé (la + grande partie quand même), il y a deux ans avant la fin de la rédaction ( le 19/11/2006 )... Protection crackée, il y a trois ans de cela... Eh oui, ça passe vite :'(.


F) Perspectives et conclusions :

Si l'on a cracké Starforce, on n'est loin d'en avoir fait le tour...

- Il serait intéressant de comprendre exactement comment Starforce détourne à son profit les interruptions 01 et 03, et arrive à crasher le système...
En effet, l'IDT (au niveau de l'int 01 et 03) pointe vers des routines crées par Starforce.

Ici, on a la routine, correspondant au hook de l'int 03 :




Pour pouvoir tracer cette routine, j'ai unhooké l'int 01. Ensuite, j'ai posé un bpx en 007DFC8B, ainsi qu'un hardware breakpoint (bpm 01870000 X).
En relançant, on se retrouve alors en 01870000, puisque l'int 03 est hookée. On a alors 007DFC8C dans la pile.
On traçe le code jusqu'à l' IRETD en 01870088, qui nous ramène en 007DFC8C, càd en plein milieu d'une instruction...



Au lieu de breaker à l'adresse prévue, le hook de l'int 03 permet l'exécution du code, un byte plus loin, sur une mauvaise instruction...
On sait d'où vient le crash, maintenant :-).

Voici la routine, correspondant au hook de l'int 01 :




Pour tracer cette routine, c'est plus dur puisque le tracing fait intervenir l'int 01 et celle-ci est hookée.
J'ai quand même essayé de mettre un bpm 01860000 X, puis de tracer, mais le jeu ne breake mais se lance...

Du coup, j'ai fait la méthode que précédemment, sauf que dans l'IDT, j'ai remplacé la routine de l'int 03, hookée par SF, par celle de l'int 01.
On obtient sensiblement la même chose : l'exécution continue sur le byte suivant (mauvaise instruction)...

- On observe également des accès aux GDT / LDT détectables par la fonction /PROTECT ON de Icedump...

- Coder un driver, (ou une .vxd ?) pour détecter / empêcher la modification de l'IDT par Starforce (ou permettre la restauration des valeurs initiales) pourrait également être une belle perspective et faciliter la vie...

- Il reste aussi à comprendre la structure physique des médias protégés par Starforce et la relation avec le CD-key demandé au début...



En conclusion, Starforce est loin d'être incrackable. Il en est de même pour les versions supérieures (la 3 et les versions 4/5, qui sont sorties, il n'y a pas encore longtemps), à ceci près que la difficulté est relevée d'un cran avec la possibilité de l'utilisation par la protection, de drivers (contenant des anti-debugging tricks), VM, stolen functions, stolen code, protection des ressources, etc...

De toute façon, la persévérance et la réflexion finissent toujours par mettre à mal les protections. Seul un manque de connaissances peut empêcher cette quête...

EDIT: Sous XP, il n'y a aucun problème à breaker dans Ollydbg, au niveau de l'OEP "modifié" (crash). Pour pouvoir appliquer la suite du tutorial, il vous vaudra, par contre, coder un driver pour retirer le hook des interruptions 01 & 03. Sous XP, je ne sais plus s'il est possible de modifier l'IDT avec Driver Studio comme dans SoftIce sous windows 98...


G) Remerciements :

Greetz :

ArthaXerXès, Black Check, CyberBob Jr, DAEMON, Dark-Angel, DecOde12, diablo2oo2, Duelist, El-Caracol, EliCZ, Elraizer, Fravia+, +Frog's Print, KeopS, Gádix, 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, +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 +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 :

ACiD BuRN : Merci pour le Millenium Cracking Tutorial.
Christal : Merci pour tout ce que tu as fait pour la scene française et ton aussi grande implication. Mes plus grands respects :)
+Frog's Print : Merci pour le cours de crack avancé sur Screen Ruler v1.0...
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... :-)
TaMaMBoLo : Merci pour les DrAPeAu NOiRS

And last but not least : tous les membres de la FFF ;-)

Final words :

J'espère que vous aurez autant de plaisir à lire ce tutorial, que moi j'ai eu en crackant cette protection. De plus, j'entends souvent la phrase "Moi, je ne cracke pas de jeux, car de toute façon je ne joue pas". Juste une précison : on n'est pas obligé de jouer aux jeux que l'on cracke. D'ailleurs, je n'ai jamais joué à War And Peace : 1796-1815 et n' y jouerai probablement jamais : par manque de temps (les jeux de stratégie sont très longs), mais aussi parce que ce n'est pas le genre de jeu que j'adore particulièrement... Et je ne crois pas que j'aurai assez de ma vie pour jouer à tous les jeux que j'ai cracké ;-)
J'aime particulièrement les jeux d'infiltration (les séries Project IGI, Splinter Cell, Thief) et les jeux en relation avec le Far-West ( Desperados : Wanted Dead Or Alive, Dead Man's hand, Gun,...), Desperados étant mon jeu préféré... Même si j'aime bien les FPS, je préfère les jeux d'infiltration, beaucoup plus réalistes. Et les FPS purs relèvent plus de l'adresse que de la réflexion. La phrase "L'intelligence reste votre meilleure arme" de Project IGI résume particulièrement bien ce que j'aime dans les jeux d'infiltration :-)
C'est valable aussi pour le cracking, d'ailleurs ;-)
"If you like a game, Buy it !"

If you want to study this protection, I can upload the tutorial target. You have just to mail me.

For any critical comments, suggestions, informations about Starforce v1 & 2 protections, feel free to contact me at :
dWx5c3NlMjAwOV9mckB5YWhvby5mcg==
(base64 encoded)
Any crack request will be ignored !!!


uLysse, le 19/11/2006

"There is a crack, a crack in everything... That's how the light gets in."


Copyright © uLysse_31