peut-être serait-ce un truc utile à lire pour les débutants, je propose cela :
Problème face à soft...
---------------------------
De très nombreuses questions reviennent sans cesse : "Comment cracker ce soft ?", "Comment je fais si ... ?, etc
Ce qu'il faut voir, c'est qu'il n'y a dans le cracking aucune recette miracle.
On pourrait donner 10000 astuces et techniques que cela ne pourrait ne pas solutionner votre problème.
Il ya certes des techniques d'attaque (dead listing,live approach) mais en aucune façon, vous n'aurez de "trucs" infaillibles.
D'ailleurs aucun cracker/euse, aussi expérimenté et bon soit-il, ne peut prétendre avoir LA technique.
On dispose tous des batteries de techniques que l'on a appris ou bien trouvé soit-même et qui donnent naturellement plus d'alternatives pour trouver la chose quand on est bloqué
En effet, quand vous attaquez un logiciel, vous vous retrouvez face à un compilateur différent (VB, Delphi, Visual C, etc) et donc des schémas de compilations, de structurations et d'execution différentes.
C'est un peu comme pour les langues, certaines ont 26 caractéres, d'autres 64 majoritaires comme pour le Chinois (si je ne me trompe), des sens de lectures, des caractéres (européen, chinois, japonais, cyrillique, etc). Personne ne connait toutes les langues mais parfois vous pouvez dénoter quelques trucs dans l'intonation de la voix ou bien dans des mots orthographiquement proche.
Pour le soft, c'est la même chose et donc vous ne pouvez pas avoir les mêmes angles et techniques d'attaque constamment.
En outre, un paramètre est prépondérant : la façon de programmer de l'auteur. Est-ce mal programmé, super technique, très fouilli, etc
De même, utilise-t-il des codes sources différents via des includes ce qui peut donner une protection très linéaire avec des calls mais dont le contenu est un cauchemar en code...
Au final, cracker un soft, ce n'est pas de suivre des règles figés.
Cracker un soft, c'est de commencer très tôt à se pencher sur des alternatives d'approche et à se poser des questions comme :
"comment puis-je faire quand mon debugger est detecté ?, "comment faire si je ne trouve pas le texte dans les SDR ?", "Est-ce que je ne vais pas avoir un truc qui va m'aider si je tape ce truc dans google ?"
Avoir ce genre de logique fera que vous serez que très rarement stoppés dans l'appréciation et l'analyse d'une protection.
Poser une question du style : "j'ai un soft mais je n'arrive pas à le cracker" est similaire à dire : "j'ai un texte, je n'arrive pas à le lire."
Vous devez avant toute chose, PRENDRE DES INFORMATIONS !
Le cracking n'est PAS FIGE dans ses astuces et techniques.
Vous ne savez pas comment vous y prendre ?
Vous avez pris votre éditeur hexa, vous avez regardé dedans l'EXE ?
On ne sait jamais, vous pouvez avoir des restes de fichiers includes qui peuvent vous aider. (en crypto, il arrive que vous trouviez dans l'EXE des traces textuelles, non présentes dans les SDR : "DSA", "init HASH", etc)
Ceci est un truc simple, et pourtant cela peut être très porteur d'infos.
Vous êtes stoppés par un anti-debugger ? Vous avez regardé si vous n'aviez pas de "hidders" pour planquer votre outil ? Vous avez lancé votre soft sans le debugger pour voir si quelquechose ne vous donniez pas une idée ?
Ce n'est pourtant pas le genre d'idées qu'une poignée de personnes peuve avoir.
Si vous attaquez un soft en vous arrêtant juste parce que ce n'est pas comme dans le tut, changez de métier parce que cela va être constamment comme cela

On a toutes et tous débuté(e)s en appliquant des règles, des techniques et puis quand on a été stoppé, on a testé d'autres trucs, on a regardé si on ne pouvait pas faire ceci, cela... et puis si au final, cela n'a pas marché, ce n'est pas grave, on a au moins pu apprendre à mieux se servir de ses outils, à envisager d'autres astuces, à voir des détails intéressants dans les EXE, des détails récurrents, etc...
Cracker c'est faire preuve d'imagination et d'initiative.
C'est, d'ailleurs, en cela que c'est très amusant et/ou passionnant.
Vous pouvez parfaitement réussir un truc que personne n'a pu faire parce que vous avez eu une approche nouvelle ou THE IDEA.
*******************
Naturellement, si je propose cela c'est aussi que je vois l'avancée du "cracking non standard"

Hi hi. Eh oh, on n'a plus de théoriciens, alors on ne va pas s'arrêter pour autant.
Le Cracking non standard ou l'art de sortir des sentiers battus et de se poser les bonnes questions.
On vous assomme comme quoi tel truc est infesable ? Ok mais a-t-on pensé à tout ? Si c'est infesable théoriquement sur le papier, pourquoi cela serait-il la même chose dans sa transposition informatique avec toutes les erreurs de restranscription et les failles/limitations matériels, etc
Je tiens à préciser que ce texte n'est pas obligatoirement à porter sur un topic punaisé sur un forum


En faite, on a toutes et tous des problèmes qui peuvent peut-être se solutionner via les réponses de ce forum mais apprendre dès le départ à être autonome dans ses idées et ses techniques, c'est TRES bon, je pense.
******************
Tiens, juste une petite anecdote pour vous montrer comment des fois, le cracking peut être amusant.
Il y a quelques années de cela (1997 ou 98 si je me rappelle bien), un soft antivirus était limité dans le temps avec nag et tout le toutim.
C'était fastidieux à cracker, etc... et arriva ce qui devait arriver.
La protection étant basée intégrallement dans une DLL... quelqu'un fit le test de renommer celle-ci pour voir le comportement de l'AV...
Résultat, le soft non seulement ne plantait pas mais la protection time trial était désactivée.
Finito les nags, les 30 jours, le soft était utilisable advitam eternaem. Quelques tests avec des binairesde virus pour vérifier que le soft marchait, et oui, il marchait....
Mettre en place une muraille n'implique pas obligatoirement que l'auteur n'ait pas oublié de fermer toutes les portes !
(Un cachou à qui devine le nom de l'AV)
Bonne journée.