COMMENT RENDRE UN PEU PLUS DIFFICILE LE DETOURNEMENT DE VOS PROGRAMMES. TRADUCTION DE LA PAGE Anti Cracking FAQ - How to make cracking your programs a little harder Adresse de la version originale : http://www.inner-smile.com/nocrack.phtml

1. Comment rendre un peu plus difficile le détournement de vos programmes.
2. More tips you might take into consideration... 
3. Advanced tips given by Assembler freaks... 
4. Special on Delphi reverse engineering...
5. Some notes on registration numbers... 
6. Some notes on timebombs... 
7. How to find cracks for your apps... 
8. What to do if you found a crack for your app... 
9. Facts and Myths about Software pirating...
10. Thoughts and letters from crackers 

D'une façon ou d'une autre, je peux comprendre la fascination que peut engendrer un programme formidable. J'ai fais des études de psychothérapie et je cherche toujours une raison psychologique, ce qui explique que ma réaction peut choquer les personnes réfractaires aux crackers et aux pirates informatiques en général. 

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"

• Ne jamais utiliser de nom de procédure explicite comme 

 
function RegistrationOK: Boolean;

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 €. Cliquez ICI. :)
 
• 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é.

 

 

En conclusion, prenez le temps de la réflexion avant de vous lancer tête baissée dans la protection de vos programmes. Imaginez une démarche globale. Est-ce vraiment une protection efficace, utile ? Ne vaudrait-il pas mieux améliorer le logiciel plutôt que les protections ? La protection d'un logiciel est utile UNIQUEMENT si celui-ci a des utilisateurs !
Ne surestimez pas l'importance de votre travail et ramenez la à une juste valeur. Faites un compromis entre la protection et les risques de dé-protection.
 
 

• Fin de la traduction. To be continued ;-)

• Use a serial which is several KB long of arithmetical transforms, to drive anyone trying to crack it insane. This makes a keygenerator almost impossible - Also, brute force attacks are blocked very efficiently.

 
• Caution with the Runtime libary! Use it fully when writing the beta versions, in the final release rewrite some functions at least to make crackers life harder.

 
• Mangle data. Protection that mangles data is usually a good one.

At least a part of your protection should be embedded inside the data manipulation. Data structures can take ages to understand basing only on disassembly listings, they also are more error-prone for crackers.
Example: Imagine a charting program .. e.g., just disabling printing and later on enabling it basing on some registration# is the most often committed suicide. Let your thingo print. When creating data structures for printing, mangle them in some way. Unmangle them just before printing, using reg# or something other for that purpose. Even more, make this mangling subtle. Assume that you've got a pie chart to print. Don't alter anything, but add some not too big random numbers to values of data series - this is mangling then. The chart will look "not that bad", but will be otherwise unuseable (if the changes are random and on the order of 20%, for example). Finding such protection, if its connection with reg# is not self-evident can take much time. One has to delve inside your data structures and find that dreaded mangling and unmangling code.
 
• Traps. A method I'm not sure about, but I have heard some apps are using it: do a CRC check on your EXE. If it is modified then don't show the typical error message, but wait a day and then notify the user using some cryptic error code. When they contact you with the error code, you know that it is due to the crack. Be aware: such traps could also be activated due to virus infection or incorrect downloads. Imagine the possible aftereffects if you are blaming your potential customer for software piracy.

 
• Don't rely on "EXE-packers". For almost any tool which compresses EXE files (Shrinker, WWPack32, NeoLite, ASPack - to list the most popular ones) there's at least one uncompressor available (for one of them I know about a total of 8, half of them downloadable with source...) so compressors capable for software-protection should at least support configurable encryption. Unpackers for the above (and other) tools are not too wide-spreaded, however, don't rely on them as your program's (one and only) "protection" - typical crackers usually have their harddisks full of such "tools".

 
• Recompile and re-release often! Especially if you are modifying your "anti-cracking" routines often, even more advanced cracks with code-searching capabilities will be useless (see also the related tips in the above section of this FAQ).

 
• Control your own distribution! Putting your apps on compilation CDs or submitting them to "autonomic" software mirrors like SimTel, WinSite or HotFiles has two sides to take into consideration: if a crack is developed for a version that is on 30,000 CDs or downloadable from 50 mirrors worldwide, that version is likely to be pirated, and once a crack for it is available, every user will not have problems to find a download location of the version the crack works on. The other side is that from a sales point, you should make your product as easy as possible to get. You will propably gain more in sales than you will lose in theft (if your software is good and innovative, of course)! Fact is: reducing publicity (i.e., distribution channels) of your software will only guarantee a reduction in sales. My personal suggestion would be to focus on the various other tips on the page, especially to distribute slightly modified versions of your app to the various sites and CDROMs which will at least ensure more work and confusion for potential crackers.

 
• "Destructive" code in your program - yes or no? Sometimes developers tell that they put destructive routines in their programs in case their internal checking routines detect that the app was cracked. They delete system files on the user's system or mess up the Windows Registry, let the program create buggy results (obviously buggy or just noticeable after careful checks) or simply pop up warnings that "a certain patch" leads to "damage to the system files" or "contains a virus". While this might be a good way to "shock" sensible novice crackers, I truly don't believe this is a good (or even effective) method to protect your work. The typical user will think: "Who knows what activates the virus inside this app -- I'll better delete it at once!" and decide for an alternative product. After all, destructive functions or even threatenings like that may result in severe problems with consumer laws of certain countries. At least your product will be suspicious if something "happens" on the user's computer - and which professional developer would want that?

 

• The rcr/rcl trick

If a rcr/rcl is performed on a value, it becomes much more of a pain to crack - you can't reverse it with by negating it's effects without knowing what the value of the carry flag was before the original operation. If the carry flag is created as a result of some other pain in the neck operation, you are probably onto a winner.
• Stick conditional jumps in. Everywhere.

Conditional jumps are not fun to reverse engineer. No loops, but jumps which conditionally bypass/include portions of your wonderful key manipulation code. There is no easy inverse operation to be performed here.
• Use portions of the code as magic number tables.

(preferably critical sections). You have no idea how annoying this can be, if you're like most crackers and like to change things around using softice (a popular cracking tool).
• Play with the cracker's mind.

This one is fun :-) Stick series of nops in, as though you were doing self-modifying code (oh my god! what the heck! nops? Aha! Self-modifying code! Idiot spends next three years trying to find the code that should be there.). Pepper the code with junk instructions. Cut the code up into little pieces and put them all over the executable, with (preferably conditional) jumps between them. - Anything which you would find a pain in the neck.
• Detect SoftIce. Early.

Now crash the computer. You can crash a pentium or a pentium with MMX even without a vxd by the opcode: F0 0F C7 C8 (illegal form of cmpxchg8b instruction with lock prefix). Beyond that, we have to resort to the tried and true methods. Using a vxd, take the CPU out of protected mode. Windows doesn't like that. Wonder why? .. On the other hand,
• Don't loose too much time on writing anything that will kill disassemblers or debuggers.

Doing it is worthless, believe me, people who made them or others will soon find the way around, so shift your interest to more important stuff. Just do things which are easily and fast to afford, like the above tip. 

• balance between security, feasiblity, programmability and end-user headaches
• Too long, non-alphanumeric Reg#'s tend to be continuously entered badly. Think about requiring to enter a verification field (as commonly used with passwords) or, at least, provide a "non-persistent" Reg# entry field so that the user will rewrite the Reg# each time, possibly correctly at last. Many people will just "glance-compare" the entered Reg# and the one (possibly) emailed to them, arriving at the final thought that they did enter it correctly, whereas the font is too small or they are too tired to notice that this '1' and 'l' have been interchanged (in a reg# like 'l83jjd_0)pH1lTe' )
• Refrain from any user feedback. The Reg# entry box should accept strings of any length, without any validation. Don't give crackers the knowledge about the type of your Reg# - if you do "online-verification" which shows that it's 10 chars long or that is contains only uppercase chars helps - so don't help them!
• Calculate the number of potential users! There's nothing bad like if you have to update 9,999 users because you didn't expect that there might be 10,000 of them and have to shoot out a new version which is capable for these Reg#'s...
• If your Reg# is 10 numbers long,.. .. there are 10^10 possible Reg#'s. But since your app might find let's say only 10^4 (10'000) users, you should invent an algorithm that assigns each one of 10^4 users one of 10^10 reg#'s, and does it somewhat uniformly. This prevents people and programs (some .vxd based "macro" players, for example) to be used for brute force approach. If there are only 10^4 users and you allow 10^9 "valid" Reg#s out of 10^10, on average each 10th Reg# tried brute-force will be valid, whereas on the case of 10^4 prospective users, that many valid reg#'s and space of 10^10 Reg#s, on average only each 10^6th Reg# tried brute force will be valid. Ever calculated how much time it would take to brute-force search 10^6 numbers, even using a fast machine and extremenly fast macro player (keystroke generator simulating Reg# entry and checking for results)?
• the assignment operator that assigns User# to Reg# shouldn't be trivial, and it's implementation should be done in Assembler by someone experienced both in Maths and Assembler. Remember that Delphi still allows you to directly use ASM code in your source! Then, check your operator. create graphs of how it works. Understand your own work, especially its drawbacks and vulnerabilities
• Be inventive. Don't use anything that seems simple, quick and effective unless you've come with something like Einstein's relativity theory, your approach is yes, simple, yes, quick, but no, not effective, and yes, easy to crack. I'm sorry, but we aren't geniuses and developing a good protection scheme takes some time.
• Don't have a single registration code. Make the key depend on some user-specific info - have a way to get the user info out of the registration codes. If you find a code on the web, track down the user and harass him. Threaten to do this when you give paying users their codes. [Ch.Losinger]
• Dynamically create accelerator keys in your "register" dialog box. These should be for keys used in the registration number entry (0-9,a-z, for example). Each accelerator could call a different routine, if feasible - this makes breakpointing tougher - and store the flag that the given char was entered somewhere else. Also, each keypress could modify some global variable, in a way that is decodeable for you (and just you, if possible ;). Finally, there should be some kind of 'monitoring' routine that acts accordingly, paining the characters on the dialog box and taking actions upon backspace and enter, for example.
• Encrypt your good code - never decrypt it. And encrypt the User-Code to test against your good code... [Ch.Losinger]

"Timebombs" usually mean runtime limits of any form developers include in their programs to limit the time or number of runs they allow before they quit (all or most) operation - or just opening a registration window anymore. Knowing this FAQ, you will immediately see the weak point of this protection scheme: as long as your application is intended to operate fully during its evaluation period, it must also come with its full code and thus can quite easily be cracked. Beside that, there are dozens of programs on the web which do nothing else than faking the system date so that your app thinks it is still inside the evaluation period.

So, don't just rely on the system date. Get the date of several files, like SYSTEM.DAT, SYSTEM,DA0 and BOOTLOG.TXT and compare them to the system date. Require that the time be greater than the last run.

The best, however, is to simply say "Goodbye" to startup/time-limits! There is simply no way to protect a time-limited demo. You won't believe it - there even exist patched versions of Windows DLL's (!) which will make your demo think it has never run before on this computer. At one point or another, you will have to save your date or program start information on the computer: in a file, in the registry, somewhere - and Windows provides GREAT ways to spy on any changes made to these devices. "This is a war that can never be won." (D.Filion)

• Use the Search engines

Using search engines is one of the best methods. Most software pirates have overboarding self-confidence and even submit their illegal pages to popular search engines on the web. If you search Altavista, Lycos or especially Meta-searchers like MetaCrawler and your software is already present for more than a few months, you'll maybe have "luck" and find some "Warez Pages" which offer cracks or Registration codes for your program.
 
• Search pages using Free Webspace

Software pirates, students which think it's cool to offer "Warez" and "Crackz" and other strange kinda persons especially love the free services offered by sites like GeoCities, Xoom, Tripod and others to offer their stuff. Most of them offer at least 5 MB free webspace, which is enough to provide thousands of cracks. Beside that, those sites are busy like BIG railway stations and like there, criminals feel quite safe to go after their "hobbies" there. Good for us, almost all free webspace providers also offer search features which allow you to search just all pages of their members, which is much more accurate and easier than using the big engines of which some are not kept up-to-date very good. Just connect to their main portal and start your search. If cracks exist for your program, you have very good chances to find them on some of these member pages.
In such a case, you should contact the maintainers of the service (almost all even provide special email addresses for piracy reports (such as abuse@geocities.com).
 
• Search newsgroups

Unlike what polititians are trying to suggest to the public, it's in most cases quite easy to track down who is posting cracks, serial numbers or even full licensed copies of your software in newsgroups like alt.cracks.* and others. Just let your newsreader display all header fields and check carefully where those people are writing from. Since almost any news server requires complete authentication before posting, you have good chances to find out who "hides" hinter strange names like "Hackman" or "Piratez2000". If you have no success, simply contact the webmaster of the server where the message comes from or forward him the posting, requesting action against this person.
 
• Make use of "Crack Search Engines"!

The easiness of CGI and increasing success to powerful webservers leaded to some quite powerful Crack Search Engines during the recent years. They can be of enourmous help for finding cracks for your software and then starting action against the responsible persons providing these pages and cracks. Sorry, I won't provide links for those sites here, but you can't miss them during your "investigations" in those slippy parts of the web.
 
• Use Web-Robots

Sites like http://www.netmind.com offer robots that notify you by email when a page changes. Since you can also define result pages of, for example, AltaVista searches for a crack or key to your program, this is a cool way to get "paged" as soon as some spider hits a website of a child which "-cool, man!-" offers a crack page. You can even do that for newsgroup searches!
 
• Subscribe to mailing lists

Their members watch the activities of most popular cracking groups and have been quite active closing many of them down during the times. They will surely help you if you yourself don't have success. Shareware developers should join forces - it pays!

• Forget about the BSA (http://www.nopiracy.com, http://www.bsa.org) - these are just commercial organizations which just take "orders" for their paying clients. No, they don't work for everybody - usually they only come in to action when the target is a large firm, using software from one of their biggest clients (no prizes for guessing which one). Can you say "M$ Militia" ?
• Do internic queries on the crackers site (www.checkdomain.com or use one of the WhoIs tools linked at the bottom of this page), contact the sysadmin, explain the situation. If the ISP is a fair and serious one, there are chances that the crackers will receive a serious warning to remove all the illegal stuff from their sites or that it will even be closed without delay.
• If the crack was published on on "free" pages like Xoom, Geocities or Tripod, or if the cracker used a redirection service, send a complainment mail to the abuse complainment address of the service - just a matter of a few minutes, but very effective.

I've listed the most important addresses in the next section.
• If this doesn't help (seldom seen, but possible), contact the local authorities of the state where the ISP is located. Most countries even provide email addresses for reporting crime activities (like childporn, but they are also open for pirated software), or at least their police administration can be reached by email. There are good chances that the ISP will be threatened to lose his licence.
• Finally: get yourself a good glass of wine and enjoy it. You have written a good program! (otherwise no one would lose time trying to crack it)

NDT : Les membres de l'aFas peuvent utiliser la section légale en envoyant un message à legal@afas-fr.org en indiquant l'url du site incriminé ainsi que l'url de leur site. En général, les hébergeurs suspendent le site dans les 4 à 8 heures.

..Si vous trouvez un crack sur une page hébergée chez un hébergeur gratuit :

• //members.xoom.com/??? -> envoyez un message ici.
• Geocities.com/??? -> remplissez ce formulaire.
• ???/Freeservers.com/??? -> envoyez un message ici.
• FreeAlways.com/??? -> envoyez un message ici.
• Webjump.com/??? -> envoyez un message ici ou remplissez ce formulaire.
• WebAzn.com/??? -> envoyez un message ici.
• Tripod.com/??? -> envoyez un message ici.
• Yahoo.com (site ou lien) -> envoyez un message ici et recevez les instructions détaillées.
• AcmeCity.com (site ou lien) -> envoyez un message ici.
• PolBox.com (site ou lien) -> envoyez un message ici.
• FortuneCity.com (site ou lien) -> envoyez un message ici.

• http://???.to/??? -> remplissez ce formulaire  ou envoyez un message ici ou ici ou là. L'herbergeur .TO propose aussi des services de redirection d'adresse. Avant d'écrire assurez vous que l'adresse est bien dans leur domain.
• http://???.tsx.org/ -> envoyez un message ici.
• http://???.findhere.com/ -> envoyez un message ici.
• http://???.cjb.net/ -> envoyez un message ici.
• http://???.da.ru -> envoyez un message ici.
• http://???.mainpage.net -> envoyez un message ici.
• http://???.Web-Page.net -> envoyez un message ici.
• http://???.MainPage.net -> envoyez un message ici.
• http://???.GamesPage.com -> envoyez un message ici.
• http://???.Main-Page.net -> envoyez un message ici.
• http://???.MusicPage.com -> envoyez un message ici.
• http://???.SexyPage.net -> envoyez un message ici.
• http://???.Biz-Page.com -> envoyez un message ici.
• http://???.Co-Inc.net -> envoyez un message ici.
• http://???.Co-Ltd.net -> envoyez un message ici.
• http://???.Pty-Ltd.net -> envoyez un message ici.
• http://???.Pte-Ltd.net -> envoyez un message ici.
• http://???.Int-Ltd.net -> envoyez un message ici.
• http://???.Intl-Ltd.net -> envoyez un message ici.
• http://???.TourGuide.net -> envoyez un message ici.
• http://???.Net-Shop.net -> envoyez un message ici.
• http://???.Subdomain.de -> envoyez un message ici.

• ???@my-deja.com -> send mail here.
• ???@email.com -> send mail here.
• ???@mail.com -> send mail here.
• ???@gironet.nl -> send mail here.
• ???@chello.nl -> send mail here (Webmaster might need threatening with authorities).
• ???@hotmail.com -> send mail here

..russian pages:

• the FSB are part of the (former?) KGB and are told to have the power to shut down and hunt "illegal" sites ("illegal" has a special meaning here, it's suggested that - in case you are - you don't tell you're from the States. ;) Mail can be sent here.

Croyance : "Je n'ai aucun logiciel sauvegardé sur mon site. J'ai juste mis des liens sur des fichiers."
Réalité : Vous pouvez être tenu responsable pour votre contribution à la violation du droit de la propriété intellectuelle. Vous pouvez avoir à répondre du chef de complicité par aide et assistance ou fourniture de moyens.
Ceci inclus la mise à disposition de liens sur des fichiers illégaux.

Croyance : "J'ai mis un avertissement sur mon site, çà me protège!"
Réalité : Un avertissement ne vous dégage aucunement de vos responsabilités. Vous avez contribué à la violation du code de la propriété intellectuelle. 

Croyance : "Je pensais que j'avais le droit de télécharger ces programmes pour les essayer si je les détruisais dans les 24 heures."
Réalité : C'est une croyance forte sur l'internet. Vous ne pouvez pas utiliser un logiciel autrement que comme l'a décrit le diffuseur dans le contrat d'utilisateur final.

Croyance : "..Il y a quelque chose qui s'appelle la liberté d'expression dans ce pays ..."
Réalité : La liberté d'expression  vous autorise à exprimer votre opinion sans aucune censure. Mais la liberté d'expression a des limites. Vous ne pouvez pas utiliser ce droit pour violer la loi. Les sites internet qui fournissent un accès à des sites illégaux, qu'il soit ou non sur le même site, violent le code de la propriété intellectuelle.

Croyance : "Et le droit à la connaissance ? J'ai juste fourni un service dans un "but éducatif".
Réalité : Le droit à la connaissance est accepté pour des reproductions partielles, pour une démarche, mais pas pour la copie entière d'un logiciel et encore moins pour l'aide au piratage de logiciel.

Croyance : "J'ai seulement diffusé des numéro de série."
Réalité : Un logiciel qui utilise une protection par numéros de série ou par clés est légal. Vous ne devriez pas les trouver sur l'internet. Fournir à d'autres personnes, ou les mettre à disposition pour d'autres personnes constitue une violation du code de la propriété intellectuelle et est illégal.

Croyance : "Et si j'ai perdu mon numéro de série ou j'ai perdu un disque dur ?"
Réalité : La plupart des éditeurs de logiciels prévoit un remplacement de leurs codes. Contacter les pour résoudre vos problèmes..

Croyance : "Si j'écris un livre sur comment cambrioler un banque et si je cambriole une banque, il y a une différence, non ?"
Réalité : Au lieu de faire la comparaison avec le vol d'une banque, vous devriez faire la comparaison entre "conduire un voiture" et  "prendre la fuite en voiture". Inscrivez une croix sur la vitrine d'une boutique informatique. Dites à une personne de jeter une grosse pierre pour briser cette croix. Ainsi tous les logiciels contenus derrière cette vitrine seront gratuits. Cela reste totalement illégal.

Croyance : "Les logiciels sont chers et j'ai déjà dépensé beaucoup d'argent pour des logiciels sans interêt. Si le logiciel est bon, je l'achéterai, sinon n'esperer aucune compensation."
Réalité : Les voitures sont aussi qualifiables de chères. Mais il n'est pas autorisé des les essayer et d'ensuite voir si on l'achète ou non ensuite. De la même manière vous ne pouvez pas utiliser un logiciel piraté et vous acquitez de la licence plus tard.
NDT : Essayer avant d'acheter, c'est le principe du shareware.

Croyance : "Tout ce qui est sur l'internet est du domain public !"
Réalité : Un auteur ne perd aucun de ses droits en diffusant ses oeuvres sur l'internet. Les logiciels piratés sont diffusés par d'autres personnes et sans la permission explicite de l'auteur.

Croyance : "C'est pas vraiment illégal de distribuer des warez !"
Réalité : Un auteur peut demander des dommages et interêts sur les quantités réelles détournées ou un forfait de $100,000 pour chaque constatation de violation des ses oeuvres. (Notez que certains logiciels sont composés de plusieurs programmes). Les pénalités maximum encourues sont de $250,000 et/ou de 5 ans d'emprisonement. En décembre 1997, le président Clinton (NDT: ex-président des USA) a ratifié la loi NET "No Electronic Theft (Pas de vol électronique)"  qui retient la notion d'infraction sur le copyright, même si celle-ci n'a pas été faite dans un but lucratif, cloturant ainsi une faille dans la loi du copyright aux USA.

Since I've published this FAQ, I've received a number of letters from former and still active crackers which told me their thoughts about my lines.

"Why the hell should a Cracker provide Richey with tips for his page!", you might ask yourself.. ;-)

As already mentioned, I don't believe that Software protection is the answer to all sales-related problems (think of the enourmous -also financial!- success of some popular Freeware products, Open Source projects and not the least weak protected programs like WinZip and so many others!) ... in most cases the main reasons why developers don't see money is because they are producing the 1000'th clone of already popular products, provide poor quality or simply don't have any idea of 1) really innovative products 2) good design and 3) marketing.

However, there ARE reasons why protection might make sense. One of them might be the following: you are investing 2 years (or many months) of hard work in a brand-new product with some new, advanced features or logic no one else on the market has ever offered before. You have a limited number of potential customers for which your product might be of real interest - but want to protect some specific parts of your program from being reengineered or simply copied -> you need a working protection for that...
Well, I have to admit that I've been suprised that at least some crackers accept that and especially that some of them even decided to provide us all with tips how to protect our work in a better way. Let me tell those fair guys a big "THANK YOU" at this place. Note: I'm keeping all letters from Crackers strictly confidential except there's an explicit permission to publish them (or parts thereof).