Pour l'instant je ne parlerai que des programmes en C , les programmes en VB (reconnaissable par leur lenteur , leur piètre qualité mais surtout par l'utilisation de fichier Dll de type Vbrun300 , VB4 , Msvbm50 . . .) c'est une autre philosophie : l'exécutable n'est pas vraiment le "maître" il "refile" la main tout de suite après le démarrage du programme à ces fameux fichiers VB . . .Ce qui complique singulièrement notre mission. Et oui car ces fichiers sont placés dans des répertoires système Windoz69 et sont utilisés par d'autres applications , bref : c'est le bordel (j'abrège) .Il existe des désassembleras dédiés à ce genre de prog-->DODI , Smartchek .(Mon Email vous est grande ouverte pour les infos à ce sujet mais aussi pour les âneries que je pourrai écrire afin que je les rectifie)

En premier il faut un débugger. Les deux "grosses bêtes" de la profession sont Softice (ou Winice) et W32dasm . Il ne faut pas l'un ou l'autre , il faut l'un et l'autre. Ces outils comme leurs noms l'indiquent , débugge les prog (évidemment) on entre dans les entrailles d'un logiciel pour faire la chasse aux bug (faute dans un prog) donc de là à considérer que l' apparition d' une boite de rappel ou l'arrêt d'un prog après trente jours d'utilisation est un bug . . . il n'y a qu'un pas . Quand vous modifiez un prog sous débuggers , ils simulent vos modifications du prog mais ne l'effectuent pas , au pire vous aurez droit à un beau plantage si vous vous êtes plantés mais tout doit rentrer en ordre au redémarrage du micro (enfin . . .normalement) . Ce qui nous permet d'essayer sans aucun danger diverses possibilités pour arriver à notre but . . .LE CRACK . La première fonctions consiste à "ouvrir" un prog (le désassemblage) à ce stade vous aurez droit à un listing traduisant le code assembleur (hexadécimal ex : EB 00) en code ASM (mnémonique ; ex : JMP 00) qui est déjà beaucoup plus clair car les termes employés se rapprochent du langage humain (version anglophone ) . Notre exemple du JMP --->du verbe anglais Jump ---> sauter : donc notre code JMP 00 ---> se traduira par "sauter à la ligne 00" . De plus les lignes seront placées les unes en dessus des autres (logiquement) alors qu'en hexadécimal elles seront l'une derrière l'autre formant un ensemble compacte sans aucun repère. Bon c'est bien tout ça mais avec la tonne de lignes qu'il y a : qui quoi donc qu' on fait avec cha . . . ! Eh oui nous sommes un peu comme des vétérinaires : inutile d'attendre que notre patient nous dise où il a mal . C'est là que W32dsam entre en jeu . En effet les programmeurs pour se repérer dans leurs prog insèrent des repères (évidemment pour se repérer) dés fois qu'ils y retourneraient plus tard pour le modifier (pour corriger les bugs par exemple) . Ces repères sont révélés par W32dasm mais celui-ci nous débusque aussi tous les ensembles de mots , phrases etc... (string data réf ) et à nous de les exploiter . Bien entendu ce n'est pas toujours vrai avec quelques fois l'absence totale de ces références ou la présence de termes pas vraiment explicites .Ces repères nous emmènerons à un endroit du prog qui sans nous donner l'endroit exact où modifier le prog , nous placera dans le "secteur" .Voilà ce sont les grandes lignes du désassembleur .La deuxième fonction est le débugging qui consiste à tracer un prog ligne par ligne . C'est à dire qu'en théorie on est capable de démarrer ligne de commande par ligne de commande (une à une ) un prog à partir du point qu' on appellera zéro jusqu'à son chargement complet en mémoire . (sachant qu'un programme de taille normale contient plusieurs milliers de lignes . . . Bon courage ) Donc toujours en théorie on est capable d'influer sur le comportement d'un prog puisque visuellement vous verrez le prog se développer au fur et à mesure de la progréssion dans les lignes de codes et si je continue dans mon délire vous pouvez donc supprimer des trucs qui ne vous intéresse pas . (Quoi donc . . . attendez que je réfléchisse . . . par exemple . . .euh . . . des nags du genre "Veuillez régler votre licen . . ." ) .Bon on en revient à nos string data ref qui nous aiderons à aller plus rapidement à l'endroit du prog. Il y a aussi les API de Windoz69 (Spécial thanks Bug'sBilly ) . Les API sont à Windoz69 ce que les interruptions sont au DOS , on peut les comparer à des macros , de petits prog standarts utilisés régulièrement par de multiples applications (ex: boite de dialogue qui sont souvent les mêmes quelque soit le logiciel que vous utilisez ; Enregistrer...sortie de prog: exitprocess) Nota : je suis prét à parier que l'utilisation des API par les éditeurs de logiciels de toutes sortes doit se traduire par une sacrée facture . . . eh qui c'est qui paye au bout . . .? . Enfin bref , les API sont là ; autant s'en servir ( je parle de nous) . Elles sont visibles toujours avec W32dasm et aussi Softice .Elles sont nommées par exemple Getwindowtext , Messagebox , Hmemcpy etc . . . et ce sont de bons exemples . Et enfin on arrive à l'arme suprême , celui que je nomme affectueusement le suppositoire masqué , j'ai nommé le . . .suspens . . . le . . . . . le . . . le BPX (breakpoint = point d'arrêt) une des commandes présentes dans W32dasm et Softice . Le BPX pour le crackeur , c'est comme le marteau pour le mécanicien , le PV pour le gendarme , le préservatif pour la prostituée . . .INDISPENSABLE .C'est grâce à lui que l'on pourra stopper un prog à un endroit précis ; ce qui nous évite de tracer ligne par ligne jusqu'à un point donné puisque qu'il suffira de lancer le prog : celui s'arrêtera automatiquement sur le BPX , mais en plus on pourra aussi le stopper même quand le prog sera chargé en mémoire . Voilà en résumant pour la première étape , vous avez les "string data réf" , les API -->les repères ( il y en a d'autres) et les BPX à poser sur les repères (aux alentours) ou à des endroits stratégiques . Ensuite il faut s'intéresser à quelques autres commandes indispensables pour les modifications :

Ses avantages :

Tout à la souris-->très pratique

  Ses fameuses String data références-->génial

Une vue d'ensemble du prog désassemblé bien meilleure que Softice

Un bon tutorial malheureusement in English

Ne débugge pas les prog 16 bits (désassemble seulement)
 
 

Softice (Winice):

Ses avantages :

Débugge les prog 16 bits

La possibilité de "jouer" avec les handles

Ses inconvénients :

Vous démarrez sous Windoz69 mais le travail se fait sous fenêtre Dos .

Vous devez rebooter votre micro (ligne ajoutée dans l'autoexec.bat)
 
 

Hiew 584(éditeur hexa , déci , Asm)

Maintenant que vous savez quelle modif est à éffectuer dans votre prog pour le cracker , il ne vous reste plus qu'à éffectuer réellement la modif , et c'est là que HIEW584 intervient . Celui-ci a l'avantage par rapport aux autres éditeurs hexa de pouvoir basculer à tout moment de l'hexadécimal au décimal à l'assembleur .Son inconvénient principale : un prog dos .Vous devez rentrer manuellement l'adresse du prog à bidouiller dans l'onglet propriété /programme de l'icône Proféssional write ex : c:\hiew584\hiew.exe c:\emplacement de votre prog (de plus le nom de votre prog ne doit pas dépasser 8 caractères-->il vous répondra : File non found ) .Par sécurité faites une copie de votre prog . NOTA : La version 6.xxx améliore les manipulations.
 
 

Touche Enter : basculement hexa , décimal , mnémonique

Touche F7 : recherche de suite d'octet (à éffectuer sous hexa)

Touche F3 : modification -->F2 hexa ou asm

Touche F9 : enregistrement des modifs (Attention pas de backup)

Touche F10 : sortie

Voilà ce qui dans les grandes lignes nous intérresse pour le moment .Après il me paraît nécessaire de passer au crack par l'exemple .
 
 
 
 

D'autres éditeurs Hexa .

Hworks32 (excellent pour les comparaisons )

Ultra édit ( il existe en version française )

SOMMAIRE