Anti Cracking FAQ
How to make cracking your programs a little harder
1. How to make cracking your app a little bit harder...
2. More tips you might take into consideration...
3. Advanced tips given by Assembler freaks...
4. Special on Delphi VCL cracking...
5. Some notes on registration numbers...
6. How to find cracks for your apps...
7. What to do if you found a crack for your app...
8. Facts and Myths about Software pirating...
9. Thoughts and letters from crackers
10. Links of interest...
Finding out that the program on which you worked for months or years has been cracked can
really hurt and demotivate.
For me as a Shareware programmer, the reason has never been that I've lost a few cents (I don't
want to do propability calculations here, it might hurt even more..), no, it was simply that I've
always tried to hold my programs as cheap as possible to make them affordable for everyone,
even for students or freeware programmers.
Somehow I can understand the fascination of cracking programs (if you are absolutely intolerant
about software crackers and hackers, please excuse, but one of my educations is Psychotherapy,
and I'm always searching for reasons...) - cracking a restricted software program must be like
solving a (sometimes very tricky) riddle, and you might get addicted to the feeling of solving
them (I've found that when I saw my grandmother doing crossword puzzles all over the time for
some months). The problem is (but at the latest, now we come to the undoubtedly illegal part of
the "game"): it doesn't really satisfy the cracker if he is the the only one who knows about his
"genius"...thus, he has to spread the news. He has to publish his "crack" (just see most crack
packages: in most cases they just consist of: 1. the cracking utility 2. a short description 3. a big
file containing claims that the producers are nothing less than the greatest ones on Earth and that
the cracked program is another one which could not stop them with "its lame protection
But now the fun is completely over: by giving out this (let's try to be fair: "study of feasibility")
to other people, by spreading it via Websites, newsgroups, mailing lists, anonymous FTP,
CDROM "abonnements" and whatever, they clearly damage the business of everyone who puts
time and energy in their software product. Even if we assume that typical crackers wouldn't have
bought your product under normal circumstances: spreading the "crack" IS criminal and no one
could claim that none of the receivers or downloaders would never have bought it. It's just like if
someone hands out copies of the key to your car on the marketplace - and it doesn't really matter
if he does that for money or not.
In earlier days, I have never put real energy in protecting my programs against cracking, but after
finding several cracks for them around, I thought to myself: why make it too easy? As a
programmer, of course I know that no - really: NO! - program can ever be crack-safe, and I know
that of every interesting program sooner or later cracks (or at least pirated or illegally copied
versions) will be around, but at least I could try to avoid the worst mistakes. Crackers are not
super-geniuses .. they are simple programmers who have learned some techniques to counteract
common protection schemes - and if you know where and how crackers are searching, you can
make them lose *much* time! And that's what it is about: there is no bullet-proof way to protect
your programs, but you can dance on the nerves of those people until they decide for an easier
target to "get the feeling"... or even go outside to enjoy the nature instead of sitting in front of the
monitor the whole day. ;-)
Most of the typical 'high language' programmers don't know Assembler anymore, so the
'protection ideas' they use are in most cases quite weak.
I don't know much about Assembler myself, so I decided to open my eyes and started to collect
anti-crack protection tips wherever I found them. Also I did my best to "learn from the other
side" .. many of the tips you can find here I've found by studying the typical cracking techniques,
the various "cracking guides" around the web and by reading protection tips given even by
professional crackers themselves (some of them generously give us tips to increase their
challenge). Well, I hope I've learned my lessons well enough, but also want to share my
experiences with you on this page.
Some rules given here were already stated in various essays on other sites, but are listed here for
completeness. Many of these apply especially to windoze, but can be "ported" to other OS'es or
This FAQ is just as good as the experiences that are webbed into it. If you think that I've
missed some points or useful tips a typical Delphi programmer could easily add to his/her
programs to improve protection, please let me know. If you allow it, I'll add it here,
otherwise I'll inform you about my experiences with it.
Don't ask me questions - might be that I'm simply too overburden to answer.
1) As mentioned, I don't have much knowledge of the low-level stuff.
2) I can't send you demo sources, since I don't have anything ready for a publication. If I
have something, you will read it here.
3) Finally, I will not provide anyone with any of the URLs where I've found (or found
out) some of these tips. Please understand, but this is a site dedicated to programming,
but not to provide "step-in's" to available cracks or even to "Cracker hunting".
But finally, here is ..
How to make cracking your app a little bit harder:
(tips are not sorted by importance)
Never use meaningful procedure names such as
function RegistrationOK: Boolean;
How intelligent and complex your code inside this function might ever be - an
experienced cracker will just take about 10-20 seconds to remove it. Believe it or not.
Alternatively, place some required code for your program in such a function. If the
cracker disables the function, your program would produce incorrect results, for example.
Avoid nagscreens or "Gotcha!" messages - this is what crackers are searching first.
They will never dig through the 300K ASM instructions of your program - instead, they
are first searching the location of nagscreens or your "Your evaluation time has expired!"
message and start cracking there (see below for more tips about that). In some cases, it's
even enough to remove the form resource from the EXE and it will show no nagscreen
anymore - without any bug showing up! If you really need such a nagscren, you should
build it dynamically at runtime, and generally, the only method to show the user that he is
unregistered should be in the "about" dialog (some programmers also have the
philosophy that nagscreens might cause your users to hate your app which would then
also be very stupid).
Never use meaningful file names such as License.Dat. Why, you say? Please start
reading here. :)
Play with asymetric encryption. Just using unusual filenames is often not enough. Good
encryption, of course, could keep the cracker busy for months (if he likes).
Add long delays. Don't warn the user right after a violation is made. Wait later, maybe
until the next day or two (crackers hate that).
Add short delays. Pause a second or two after a password entry or to your other
checking routines to make brute force cracking unfeasible. Simple to do, but rarely done.
Use checksums in DLL's and in the EXE. Have them check each other. Far away from
"safe", but it just makes it harder to crack.
Self-heal your software. You know, things like the error correction modems and hard
drives use. The technology has been around for years, and no one uses it on their
software? The best thing about this is that if the cracker used a decompiler, they may be
looking at a listing that is no longer valid.
Patch your own software! Change your code to call different validation routines each
time. Beat them at their own game.
Store serial numbers in unlikely places like as a property of a database field. Often
heard and read: "..give it a DLL file name and store it in the System directory." Too often
heard, don't use it. ;-)
Store serial numbers in several places.
Don't 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 (but keep in mind that many users might do Y2K-
checks these days).
Don't use literal strings that tell the user: "Sorry, but... (whatever)." These are the first
things to look for. Build strings dynamically or encrypt them.
Flood the cracker with bogus calls and hard-coded strings. Decoys are fun.
Have fun with Spaghetti-Code simply eats his time and nerves..
Don't use a validation functions. Every time you validate the user, write your validation
code inline with the current process. That just makes more cracking for the cracker and
bewares of just NUL'ing out your routine.
Use "reserved" names. When using hard-coded keys or passwords, make them look like
program code or function calls (i.e., "73AF" or "GetWindowText"). This actually works
very well and confuses some decompilers.
No "disabled" features. If your program doesn't save data in "crapware" edition, don't
include a "grayed" menu item. No saving means no saving - the code should not be
included in the EXE - that's it. Most programming languages offer you a really easy way
to maintain several versions of your code by simply doing the following:
... no action here ...
... advanced functionality for registered user ...
Say "Goodbye" to startup/time-limits! This belongs close to the tip above - especially,
since 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)
Update often. Frequent updates mean: frequently changing code, so the typical (simple)
crack which is just patching hard-coded byte positions, will possibly already be outdated
when published. Also prevent uploading them to public servers, so that you have better
control about where your app sits around and people don't find older versions the cracks
can still use. Yes, this doesn't prevent pirates from including the version to the crack
package, but IF they do so, you can at least contribute to filling up their harddisks.
Use strong encryption. Just XORing is not really strong - use something with an
algorithm that isn't easily reverse-engineered, and don't put both encryption and
decryption code in your app.
Finally, take some time to think about protecting your software. Is it really worth the
protection? Wouldn't it be better to improve your software, rather than improving
protections? The problem of protecting software vanishes if no one will use your
software. Don't overestimate your work's "importance to the world".
More tips you might take into consideration:
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.
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 - to list the most popular ones) there's an uncompressor
around, so compressors capable for software-protection should at least support
configurable encryption. Unpackers for the above (and other) tools are not very wide-
spreaded, however, don't rely on them as your program's (one and only) "protection" -
organized 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
Control your own distribution! Avoid putting your apps on compilation CDs. If a crack
is developed for a version that is on 30,000 CDs, that version is likely to be pirated. [by
Advanced tips ..given by assembler freaks.
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
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
Don't loose too much time on writing anything that will kill disassemblers or
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.
Special on Delphi VCL cracking
Quoted from a helpful cracking tutorial*) - just read and learn from it!
"Let's learn something about the innards of new Borland's programming tools. This knowledge
will allow us to speed up cracking sessions, as will teach shareware programmers who use
Delphi to be more careful and not to happily expose their 'secrets' to curious eyes B) [..]
VCL stands for "visual component library", a library used by recent Borland visual languages as
Delphi and BC++ Builder.
These environments use a proprietary resource format, that appear as 'RCDATA' when listed by
Resource Workshop. These resources contain 'forms'. In Delphi jargon, forms are the windows
of the program. All the info about their design is stored there. When a typical Delphi app is
starting, the initialisation code creates the forms, loading the required information from the
resources. Sometimes this loading is deferred - forms that aren't used very often are created and
destroyed as needed.
This system is the best and the worst of Delphi. It allows a very fast way of programming but,
for full-length apps, it can slow down the loading.
The really interesting part of this information is that the address of the routines - called in
response to user interactions with the elements of the form - are bound at run time by name. So
knowing these names we can find the appropriate addresses!
If you have cracked any Delphi apps, you have surely experienced the long chain of calls inside
the library, from the breakpoints on the API calls to the "do something" code. I hoped that these
addresses could help in pinpointing the relevant code."
[..describes his installation of a quite well-known Delphi-writen application..] I cracked it
completely and without problems, as you are about to see :=) After first installation the weeks
passed and I hadn't had the time to work on it... when I started it, I found a nasty 'Your
evaluation period has expired' message :-(
The first step is to gather the information about the target exe with a resource or form spy tool.
You may be tempted to investigate TVALIDATORDLG, the form where the user name and
registration key is obviously input. But all you'll find is a mere dialog. The real work is
accomplished from its caller: TSPLASHFORM. This is the nag window that appears at the
beginning of the program, as well as when it's shutting down and from the Help->About menu.
You can select TSplashForm and look at the text representation of it. A lot of information about
the buttons and labels will appear. Let's concentrate on the following part, near the end:
object RegButton: TButton
Left = 200
Top = 176
Width = 97
Height = 25
Caption = 'Register'
TabOrder = 1
OnClick = RegButtonClick
What's that? This is the button with the caption "Register". You can see its size, position... and
something with a suggestive name: "OnClick". "OnClick" tells us the name of the routine
invoked when the user presses this button. Once we have the name (yes, "nomen est omen" :) we
can search for the address of this routine. This is because the routine is bound to the button at run
time by name.
Using a hex editor, I looked for "RegButtonClick" and I found it twice. The second occurrence is
the resource itself, the first is within an address table:
000A4990 ____ ____ ____ BC57 4A00 0E52 6567 4275 ______.WJ..RegBu
000A49A0 7474 6F6E 436C 6963 6B__ ____ ____ ____ ttonClick_______
Now look at the magic numbers before the name. There is a byte ('0E') indicating the length of
"RegButtonClick" (14 characters) and before that an address: 004ABC57.
Some disassemblers seem to think that file is too long and it doesn't disassemble this portion of
the exe correctly - however, with a special tool we can bpx on this and... right! It stops at the
point just when we push the button.
A couple of instructions forward you'll find a CALL. Tracing into it you'll find a "standard stack
frame" in 44ECC8:
0044ECC8 55 push ebp
0044ECC9 8BEC mov ebp, esp
This is the kind of thing expected at the beginning of a high level routine, made by the
application programmer. We have avoided the whole chain of library calls through the VCL
from Windows notifications, and landed in the right place!
From this point, there are some calls you can easily test by setting breakpoints on them - you'll
find that their purpose is to show the dialog asking for the user name and registration key. Then,
the key is calculated from the user name and compared with the one the user entered. You can
enter the name you choose, and anything as the key, after BPXing 44ED69. Here, a call to a
routine compares two strings. D EDX will show the fake key you entered and D EAX will show
the correct calculated key. Easy, isn't it? A ten minute crack by a beginner!!
[description about spying the key generator routine comes next. It's been an average routine of
about 10-20 Object pascal code lines.]
How this way of cracking can be avoided?
Read my tips above. The basics are: don't use automatic methods created by double clicking on
the button or the object inspector. Write your code somewhere else in your program, preferably
in another module, and bind it to the button using code such as:
RegButton.OnClick := RegButtonClick;
Of course you'll need to enter this code after the form is created and before it's called. Best if it's
rounded by a lot of unrelated stuff. This won't necessarily prevent your program from being
cracked of course, but things will not be as easy as you have seen in the lines above O:)
Notes on registration numbers
(if you can't avoid them)
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]
Encrypt your good code - never decrypt it. And encrypt the User-Code to test against
your good code... [Ch.Losinger]
How can I find out if cracks exist for my program?
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 firstname.lastname@example.org).
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
Here is a link to a crack search engine - try it! Since it is not providing or linking to any
cracks by itself, I decided to list it here just to show you how many cracks actually exist.
If you can't find your app, don't be too happy: it's just one of a number of existing search
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
If you don't know how to go on, ask in the Anti-Warez Mailing-list or other, Shareware-
related mailing lists (see my Delphi Tips pages for more links).
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!
What to do if you found a crack for your app "Blow the whistle!"..
I've heard and read many programmers telling "you can't do everything against them, there are
too many crackers around, too many warez sites on the Net, so that few people ever get caught."
Fact is, however, that you as a software author would have excellent chances to win any lawsuit
against operators of ISP's awaringly keeping crack/warez sites online or against the crackers
themselves. Hundreds of sites have been closed down during the last years due to offering or
linking to pirated software. In some cases, computers were confiscated, and the operators are still
So, you don't have just to accept if you find pirated copies or cracks for your software around ..
try to detect where it comes from and get into action against the source!
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), 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 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)
Facts and Myths about Software pirating
Provided by the Business Software Alliance
Myth: "None of the software offered was stored on my site - I only had links to the files."
Fact: You could be liable for anything that you do that contributes to the infringement of
copyrighted works. This includes facilitating a download by linking to remote files.
Myth: "I have a disclaimer on my site that protects me."
Fact: A disclaimer cannot shift your liability to someone else. You are still contributing to
Myth: "I thought it was okay to download programs to try them out if I delete them within 24
Fact: This is a common Net Myth. You may only use the software as described in the end-user
license provided by the software publisher.
Myth: "..there is something called 'freedom of speech' in this country..?"
Fact: Free speech refers to your right to provide opinions and original content without censure.
Even so, free speech has limits. You cannot use this right to break the law. Internet sites that
provide access to others' copyrighted materials - whether it's on the same site or a remote site -
violate the author's right to control distribution of their works, which is against the law.
Myth: "What about "fair use"? I am only providing a service for "educational purposes."
Fact: Fair use is widely accepted to mean the reproduction of a part of a copyrighted work, not
the wholesale copying of an entire program or contributing to software piracy.
Myth: "I only post serial numbers."
Fact: Legal software comes with required numbers or keys to install the software. It should not
be necessary to get these off the Internet. Providing them for others to use with pirated software
contributes to copyright infringement and is illegal."
Myth: What if I lose my serial number or one of my disks is trashed?
Fact: Most software publishers have provisions for replacing media. Contact them to resolve
Myth: Writing a book about robbing banks and robbing them yourself are two different things,
Fact: A better analogy is "robbing the bank" vs. "driving the getaway car." Or, another analogy
is stealing software vs. marking the computer store window with an big X and telling people that,
if they throw a brick at the X, they can steal the software in the store window. Both are illegal.
Myth: Software is so expensive, and I've wasted a lot of money just to find out that an expensive
program is worthless! If it's any good, then I'll reward the authors. If not, forget the
Fact: Cars are expensive, too, but society doesn't allow people to use them and decide later if
they want to pay for them or not. In the same way, you cannot use pirated software and pay for it
only if you want to at some later date.
Myth: Isn't everything on the Internet in the public domain?
Fact: An author does not waive copyrights by publishing on the Internet. Pirated software is
published on the Internet by someone other than the author or without the author's explicit
Myth: It's not really illegal to distribute warez.
Fact: An author can seek civil damages in the amount of their actual value, or statutory
damages of $100,000 per work infringed. (Note that some "programs" are actually bundles of
more than one copyrighted work.) Criminal penalties include fines of up to $250,000 and jail
terms up to 5 years, or both. In December 1997, President Clinton signed a law called the "No
Electronic Theft" (NET) Act that allows for criminal prosecution of copyright infringement, even
where there is no profit motive, closing a loophole in U.S. copyright law.
Thoughts and comments from Crackers
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.
Links of Interest
"Contributory Copyright Infringement Lawsuit Settled Against Internet Pirate" (SPA
How to battle Warez Anti-Warez Mailing List and -Tips
Anti Crack Information by Vitas Ramanchauskas
The "Sam Spade" whois tool find out who publishes Cracks for your Applications
Tracking Down Warez Sites how to find the responsible persons (page provided by Rob
from Cat-Soft, the link above)
Report Software Piracy (BSA / NoPiracy.com)
Report Software Piracy (SPA)
Decompilation page provided by the University of Queensland
efg's CRC Lab good explanation of the "Cyclic Redundancy Check" algorithm and
Just some thoughts..
Thanks to Fravia+ (a cracker), who allowed me to quote some of his experiences and knowledge
on this page.
Again: please e-mail me if you have tips or suggestions !
If you want to support my work on this page or simply say "thanks" for opening my treasure
box to you, I'd be happy if you would register one of my apps!
Based on your support, page will be updated frequently. Last update: 22-Apr-99