Le Soft-Cracking - Les méthodes de protection
--------------------------------------------- 
              Part II by S/ash (rtc-slash@fr.st)

Disclaimer : S/asH signale que le debugage de logiciel est jusque là
autorise en France. De même que la modif de prog ou la fourniture de crack
du momment qu'ils ne soient pas distribués avec le prog. Cependant
l'utilisation de logiciel sans licence est elle illégale. Si vous n'habitez
pas en france je signale que dans beaucoup de pays non européen tout ce que
vient de citer est illégale. Pour ma part, je ne suis pas responsable de 
l'utilisation faite de ces informations par les lecteurs.

Je vais ici écrire un article beaucoup plus théorique que le premier. 
J'y commente les différentes techniques de protection utiliser par les
développeurs.

I. Les clefs d'enregistrements
------------------------------
Les clefs d'enregistrements est la technique la plus utilisé par les auteurs
de shareware. Ces clefs répondent, dans la plupart des cas, à un algorithme
en fonction en générales d'une autre chaîne de caractère (en générale le
nom). Il se peut cependant que la clef soit fixe (comme pour les soft de m$).
Les techniques pour en venir à bout sont nombreuses : patcher le logicielle
pour enlever la vérification de la clef (cf article précédent), recréer
l'algorithme de génération de clef ou encore aller chercher en mémoire lors
de l'exécution la chaîne avec laquelle la clef sera comparé... Pour les clef
fixe, cette dernière méthode est la plus élégante et pour les clef généré,
la méthode la plus élégante est le Key Generator (cependant il est chiant à
réaliser).

II. La protection par mot de passe
----------------------------------
La protection par mot de passe est souvent utilisé dans les jeux (en général
les vieux). Pour la contrer, plusieur méthodes existent : modifier le test
pour qu'il accepte n'importe qu'elle mot de passe, sauter la vérification du
mot de passe (la plus élégante), faire en sorte que ce soit toujours le même
mot de passe (enlever la partie génération aléatoire), et afficher le mot de
passe à taper à l'écran.

III. La protection par support de donnée
----------------------------------------
J'entend par cette protection, une protection contre la copie. Il s'agit d'une
chaîne de donnée écrite à un emplacement particulier du support (boot, partie
caché de la table iso9660...). Il existe bien sur des programmes qui
effectuent des copies complètes des supports mais cela est fastidieux. La
solution la plus pratique est de retiré la vérification de la protection.

VI. La protection par Dongle
----------------------------
C'est une protection très efficace mais couteuse. En effet on ne peut pas 
comme les codes, le recopier sur un bout de papier. On peut cependant en 
émuler mais cela est également couteux. La meilleur solution est de retiré 
la vérif du dongle.

V. Les techniques anti-debugging
--------------------------------
Je parle ici des techniques cherchant à nous empêcher de réalisé le crack.
Ces techniques sont censé faire planté le debugger.

  a. Faire joujou avec l'interrupt 3
  ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù
  Maintenant, peu de codeur le font car c'es chiant à mettre en oeuvre : il 
s'agit de modifier l'interrupt 3 qui sert au débugage. Cette méthode n'est 
plus utilisé pour plusieur raison : peu de gens code en assembleur, cette
protection est incompatible avec Windows et des logiciels comme Soft-Ice ne 
sont pas affecté par celle-ci.

  b. Faire joujou avec le mode protégé
  ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù
  Cette méthode consiste à passer successivement du mode non protégé au mode 
protégé et vice-versa. Cela à un effet redical sur certain debugger : il 
plante car il ne supporte pas le mode protégé. Pour éviter cela ? utiliser
SoftIce ou Turbo Débugger. Un truc drole est que Windows supporte aussi très
mal cela :)

  c. Faire joujou avec la mémoire
  ùùùùùùùùùùùùùùùùùùùùùùùùùùùùùùù
  Ben si c'est un programme DOS, réservé toute la mémoire basse à pour effet
d'empecher un debugger de tourner.

  d. Le coup de la PIQ
  ùùùùùùùùùùùùùùùùùùùù
  Bon, toutes les techniques précédentes ne nous emmerde pas car elles sont
inéfficace sur les debuggers actuels. Le coup de la PIQ est là pour empêcher
le débugage pas à pas. Il consiste à modifier la vérification de la version 
de DOS dans le code en instruction d'arrêt. Il n'a pas d'incidence dans le
cas d'une éxécution classique car le code normal sera déjà chargé mais à pour
effet de planter le débuggeur en mode pas à pas. Il suffit de sauter
l'instruction quand on la rencontre. C'est technique est peu connus donc peu
utilisé (kewl !!!)
Voici le code asm correspondant :
PIQ_Stop_System proc near
   push ds
   push ax
   push bx
   push cs
   pop  ds
   mov  cs:word ptr [@int_21_fonct],4cb4h  ; c'est le code de modification
                                           ; fonction arrêter
@int_21_fonct:
   mov  ah, 30h                            ; fonction de version du DOS
   int  21h
   pop  bx
   pop  ax
   pop  ds
   ret
PIQ_Stop_System endp

  e. L'encodage des données
  ùùùùùùùùùùùùùùùùùùùùùùùùù
  Cela consiste à coder le programme et à le décoder à l'éxécution. Bof, 
empêche d'utiliser WDasm (désassembleur) mais pas SoftIce. Technique peut 
utilisé car dérangeante.

  f. Le checksum
  ùùùùùùùùùùùùùù
  C'est la technique la plus chiante à enlever, surtout si elle est appliqué à
plusieur reprise. Cette technique est sans doute la seule encore utilisé. Elle
consiste à effectué une somme de contr“le de certaine partie du code. Si un
logiciel patché s'arrête, il y a de forte chance que ce soit à cause de cela.
La seule solution est d'aller modifier la somme de contr“le (attention il
peut y en avoir plusieurs !!!).

Conclusion : ne vous inquiétez pas trop pour ces techniques anti-debugging,
elles sont rarement mise en oeuvre !!!
<--                            File by S/ash                               -->
[EOF]