Le forcement (ou la violation) d'un logiciel bridé ressemble à la résolution d'une énigme (parfois complexe) et vous pourriez vous aussi en devenir "accro". (Je l'ai constaté en regardant ma grand-mère qui ne pouvait s'arrêter de faire ses mots-croisés)

Le défaut du cracker, c'est qu'il ne se satisfait pas d'être un "génie", il veut que cela se sache. Nous arrivons à la partie illégale "du jeu". Pour cela il diffuse largement ses créations sous cette forme.

1. L'utilitaire de forcement.
2. Une description courte.
3. Un gros fichier texte ou une animation contenant des informations précisant que les crackers ne sont rien moins que les individus les plus brillants sur la Terre, et que le programme craqué est un bijou de technologie qui ne pouvait pas les arrêter en raison "de son système de protection boiteux".

Fin de la plaisanterie : En le distribuant aux autres personnes via les sites web, les newsgroups, les mailing-lists, le ftp, les CD-ROM "abonnement", etc, ils portent directement atteinte aux auteurs de logiciels, à ceux qui mettent de l'énergie et du temps pour confectionner un produit le plus parfait possible.

Même si nous supposons que les crackers n'achèteraient pas votre produit en temps normal, il n'en est pas moins sûr que la diffusion du crack est criminelle. Car c'est justement les gens qui vont télécharger ce crack qui auraient pu acheter votre logiciel. C'est comme si quelqu'un diffusait des copies des clefs de votre voiture. Peu importe si sa démarche est motivée par l'appât du gain ou non.

Avant, je ne dépensais que rarement d'énergie pour la protection de mes programmes mais depuis la découverte de plusieurs cracks je me suis demandé pourquoi leur faciliter le travail ?
En tant que programmeur ma réponse a été de leur rendre le plus difficile mais il faut également penser que la meilleure des protections ne sera jamais efficace à 100%. Il faut faire un rapport entre le temps de développement et le temps de protection. Pour cela, il faut éviter de commettre quelques erreurs...

Les crackers ne sont pas des super-génies .. Ce sont des "simples" programmeurs qui ont appris quelques techniques pour neutraliser les schémas de protection communs - et si vous savez où et comment les crackers cherchent, vous pouvez leur faire perdre du temps !

Partant du constat qu'il n'y a aucune protection 'pare-balles' pour protéger vos programmes, vous pouvez jouer avec leurs nerfs avant qu'ils ne décident de trouver une autre cible plus facile. En effet, il est important pour eux d'avoir un tableau de chasse pour prouver leur "génie" et garder leur "feeling" et de ne pas rester continuellement devant leur écran ;-)

La plupart des programmeurs de langages évolués ne connaissent pas l'assembleur. Leurs idées de dé-protection sont donc assez limitées. Personnellement, je ne connais pas beaucoup l'assembleur, et j'ai décidé d'ouvrir mes yeux et commencé à rassembler une collection de protections anti-crack. J'ai fait de mon mieux pour "apprendre l'autre côté" .. beaucoup de conseils cités ici ont été trouvés en étudiant les techniques de base des crackers, les divers "guide du cracker" trouvés sur le net ou encore en lisant des articles de protection écrits par des crackers professionnels (certains programment même des protections).

Bien, j'espère que j'ai appris mes leçons, et je vais partager mes expériences avec vous dans cette page.

NOTA : Cette FAQ est un recueil d'expériences. Si vous pensez que j'aurai pu aborder d'autres points ou si vous avez une solution pour qu'un développeur ajoute facilement une protection, merci de me contacter. Je vous répondrai via cette FAQ (avec votre permission), soit directement. Ne me posez pas de questions sur la sécurité.
Je ne suis pas un expert en langage machine !
Je ne peux pas répondre à tous et envoyer des codes sources d'exemples. Je ne prépare aucune publication. Vous lirez tout sur cette page.

Pour finir, je ne fournirai aucune URL de crack ou de dé-protection. Mon site est un site de programmation, pas un site de "Chasse aux crackers"
Et enfin la voilà ...

Comment rendre un peu plus difficile le détournement de vos programmes

Qu'importe la complexité et l'intelligence du code, un cracker expérimenté ne prendra que 10 à 20 secondes pour le contourner. Croyez-le ou non.
Par contre, vous pouvez utiliser cette fonction comme leurre. Si le cracker désactive cette fonction, votre programme adoptera un comportement différent (résultat incorrect, réduction de fonctionnalité, repassage automatique en mode essai au bout de x lancements, etc). Par contre, vous ne devez pas le prévenir de la détection de son intrusion.

Évitez les nagscreens (ou fenêtre d'avertissement) - C'est là que les crackers rechercheront en premier à contourner une protection. Ils n'analyseront jamais les instructions de votre programme parmi les 300Ko d'assembleur. Plus rapide, ils rechercheront en premier vos nagscreens ou vos fenêtres "Votre temps d'évaluation est expiré!" et commenceront leur action à partir de ce message. Dans certains cas, il est même possible d'enlever directement cette protection en supprimant l'accès à une simple boucle, et ce sans créer une anomalie dans le .exe ;-(. Si vous mettez des nagscreens, vous devez la construire dynamiquement. Il est préférable de ne pas multiplier les fenêtres de rappel. Ceci pourrait incommoder les utilisateurs qui testent votre programme. La meilleure façon de montrer le mode de fonctionnement de votre programme (libre-essai - enregistré) est encore de l'afficher dans le 'A Propos'.

Ne jamais utiliser de nom de fichier comme licence.dat.
Pourquoi ? Retournez au début sans toucher 6000 € ;-)

Utilisez le chiffrement asymétrique. Le changement du nom de fichier de licence n'est pas suffisant. Evitez de prendre le même pour la totalité de vos créations. Utiliser un chiffrement 'correct'. Il pourrait tenir le cracker occupé pendant des mois (s'il aime).

Ajoutez des délais longs.
N'avertissez JAMAIS la détection d'une violation du code. Attendez quelque temps, un jour ou deux (Les crackers détestent cela).

Ajoutez des délais courts.
Après la saisie du code d'enregistrement, temporisez une ou deux secondes vos routines de contrôle. Ceci rend pratiquement inefficace la technique d'attaque "brute force". Simple, mais rarement utilisée.

Utilisez les checksums pour les DLL et les EXE. Vérifiez-les au lancement. Ce n'est pas la protection absolue, mais elle complique énormément le travail du cracker.
Régénérez automatiquement vos programmes. Vous savez que les modems et les disques durs utilisent la correction d'erreurs. Cette technique n'est pas nouvelle et personne ne l'utilise en matière de logiciel. Le meilleur est de penser au cracker qui a utilisé un décompilateur et qui lit un code périmé.

Mettez à jour votre programme. Changez les procédures d'appels des sous-programmes à chaque fois. Battez-les à leur propre jeu.
Enregistrez les numéros de série dans des endroits peu communs, comme un champs propriété d'une base de données. Evitez de lui donner l'extension .DLL et de l'implémenter dans le répertoire \%windir%\SYSTEM, trop connu.
Décomposez et enregistrez les numéros de série dans plusieurs endroits.

N'utilisez pas les chaînes de caractères littérales qui renseignent l'utilisateur : "désolé, mais... (quoi que)." Ce sont les premières choses à rechercher. Construisez les chaînes de caractères dynamiquement ou chiffrez-les.
Faites de faux appels. Inondez le cracker de faux appels ou codez en dur des chaînes de caractères. C'est toujours amusant les leurres.
Amusez-vous avec le code spaghetti. Jouer avec ses nerfs.
Oubliez les délais. Voir les détails en fin de FAQ.
N'utilisez pas de routines de validation. Chaque fois que vous voulez valider le code d'enregistrement de l'utilisateur, écrivez le dans le processus en cours. Cela évitera au cracker d'annuler l'appel au sous-programme.
Utilisez des mots réservés. Utilisez des clés ou des mots de passe codés en dur et faites les ressembler à du code ou des appels de fonctions ("73AF" or "GetWindowText"). Ceci perturbe certains décompilateurs.
Codez deux versions. Si votre programme ne sauvegarde pas les données dans la version shareware, ne le rendez pas visible dans les menus utilisateur, précisez le dans les limitations. Pas de sauvegarde, signifie pas de sauvegarde. N'incluez pas le code dans l'exécutable. La plupart des langages de programmation vous offrent la possibilité de mettre à jour un seul code avec plusieurs versions :

{$IFDEF trial}

... aucune action ...
{$ELSE}
... fonction avancée pour utilisateur enregistré ...
{$ENDIF}

Diffusez plusieurs versions. Version légèrement modifiée

{$IFDEF Anticrack_Method36}
..protection code #36 ..
{$ENDIF}

En l'adaptant avec le sujet d'avant, vous pouvez modifier et créer rapidement des versions légèrement différentes de vos exécutables. Cela peut occuper les crackers car certains 'patchs' fonctionneront, d'autres pas et ce pour une même version. Les pirates de logiciels seront alors obligés de faire un crack pour chaque compilation, de proposer sur un serveur la version de votre logiciel complète ou tout simplement d'abandonner l'intérêt qu'ils portaient à votre programme.
C'est aussi une bonne méthode pour faire des compilations spécifiques entre les versions publiques téléchargeables et les versions des utilisateurs enregistrées.

Mettez à jour souvent vos programmes. Mise à jour fréquente signifie que le code changeant fréquemment, le cracker ne pourra pas patcher en dur l'exécutable directement et que le temps qu'il décode votre nouveau programme celui-ci sera périmé.

Surveillez vos diffusions. Ne diffusez pas trop largement vos archives sur des serveurs que vous ne pourrez pas suivre. Ainsi il sera difficile de trouver des versions anciennes fonctionnant avec les cracks anciens. Cela n'empêchera pas les crackers de fournir une nouvelle version, mais cela les obligera à fournir également l'intégralité de vos oeuvres et de saturer un peu leurs disques.

Créez des codes de déverouillage temporaire. Envoyer ce code immédiatement lors de la réception de la licence. Cette clef ne sera valide que pour une quinzaine ou trentaine de jours, le temps nécessaire pour vous de valider le paiement et d'envoyer la clef définitive. Envoyez la clef définitive et uniquement celle-ci. Ainsi, le cracker ignorera que son patch ne fonctionne pas et diffusera, tout content de lui, son code sur les sites warez. Avant qu'il ne soit largement diffusé, le patch sera inefficace. Cela aura pour but principal de le discréditer auprès de sa communauté pour avoir distribué des cracks inefficaces. Cette méthode peut aussi servir pour les bêta testeurs ou pour la presse.
Utilisez un chiffrement fort. L'instruction XOR n'est pas vraiment qualifiable de fort. Utilisez plutôt un algorithme difficile à retracer (Reverse-engine). Ne mettez jamais le code de chiffrement et le code de déchiffrement ensemble dans votre application.

Informations sur les protections basées sur le hardware: Beaucoup de solutions de protection logiciel utilisent des informations hardware (comme le nombre de disques durs, le checksum de certains champs du BIOS ou d'autres variables du système. Une fois calculées, vous pouvez comparer ces données et autoriser le lancement de votre programme ou permettre certaines fonctionnalités. Vous pouvez aussi créer et encrypter une liste des propriétés de la machine que l'utilisateur vous enverra pour générer le code définitif. Ce genre de protection est assez efficace et facile à mettre en oeuvre, (si vous utilisez aussi celles décrites dans cette page), mais elle implique une gestion plus lourde du suivi de vos applications et est fortement déconseillée pour les applications ayant beaucoup d'utilisateurs. En effet, à chaque changement de disque dur, renouvellement d'ordinateur ou mise à jour de celui-ci, vous devrez vérifier que sa licence est à jour, régénérer une nouvelle clef et lui envoyer, même pour un programme vendu quelques mois plus tôt. L'utilisateur pourrait même vous envoyer un courrier expliquant son étonnement de voir votre programme ne plus fonctionner sur sa nouvelle configuration et penser à un bug plutôt qu'à une protection. Ce dernier point est à prendre en compte car il pénalise fortement l'utilisateur enregistré.