|
Советы по
защите программного
обеспечения.
(Временно
на английском в ближайшее
время будет переведено)
Contents
- How to make cracking your
app a little bit harder... [upd:06-Aug-99]
- More tips you might take
into consideration... [upd:06-Aug-99]
- Advanced tips given by
Assembler freaks... [upd:06-Aug-99]
- Special on Delphi VCL
cracking...
- Some notes on registration
numbers... [upd:06-Aug-99]
- How to find cracks for your
apps...
- What to do if you found a
crack for your app... [upd:19-Aug-99]
- Facts and Myths about
Software pirating...
- Thoughts and letters from
crackers
- Links of interest... [upd:06-Aug-99]
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 psychological
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 text
file or even animation containing claims that the
producers are nothing less than the most brilliant
individuals on Earth and that the cracked program is
another one which could not stop them due to "its
lame protection scheme".)
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 anywhere
else.
PLEASE:
- 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
developer could easily add to his/her programs to
improve protection, please let me know. If you
allow, then 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 generic "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:
{$IFDEF trial}
... no action here ...
{$ELSE}
... advanced functionality for registered user ...
{$ENDIF}
- Release several, slightly
modified versions.
{$IFDEF Anticrack_Method36}
..protection code #36 comes here..
{$ENDIF}
By doing
the an adapted variation of the tip mentioned
before, you can easily vary your code and
enable/disable it (by defining or undefining the
related DEFINE variable) to create slightly
different versions of your program executables.
This will keep the crackers busy since many of
their fellow fans will repeatedly tell them that
"crack xy is not working!!!" if they
just downloaded the program from somewhere else
than the cracker himself did it. Either the
software pirates would now be forced to create a
number of cracks for each "build", to
fill up their server space with a complete setup
package of one of your builds along with the
crack which works on it or simply to give up on
your program.
btw., this is also a cool method to make a special
build for your registered users or preventing
"registered" code to be compiled into
the officially downloadable demo release (which
crackers can often "enable" with just a
few minutes of works as explained elsewhere on
this page).
- 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.
- Some thoughts about
hardware-based protection: Many tips
concerning software protection include retrieving
hardware information from the user's machine
(like the harddisk number, checksums of certain
BIOS areas or other system variables). Once
calculated, you could save these numbers and just
run your program or enable certain features if
they match on the computer. Or you could create
an encrypted/mangled list of data containing this
data and let the user send it to you, then create
a machine-specific unlocking code and send it
back to the user. Everything quite nice from a
protection point of view (if you also keep the
other tips on this page in mind, of course: not
even the best technique protects against weak
validity checks), however, it requires continuous
contacts with your end-users and might not be the
preferred method especially of developers who
have a bigger number of users. Every time your
user changes his harddisk, buys a new computer or
upgrades his system in another way you would have
to interact with him, or - if he purchased your
program already some months ago - he might even
send you an angry mail "why your program
doesn't work anymore" .. you should take
this into consideration before deciding for
hardware-based protection.
- 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.
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
- 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 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?
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 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.
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
end
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]
- 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]
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 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.
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 about
50 existing search engines.
- 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
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
paying settlements.
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 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)
Where
to report cracking pages found thru' free services
..if you found a crack on a page hosted by Freespace
Providers:
- //members.xoom.com/???
-> send mail here.
- Geocities.com/???
-> fill out this form.
- ???/Freeservers.com/???
-> send mail here.
- FreeAlways.com/???
-> send mail here.
- Webjump.com/???
-> send mail here or fillout this online form.
- WebAzn.com/???
-> send mail here.
- Tripod.com/???
-> send mail here.
- Yahoo.com
site or link: mail here and receive
detailled instructions.
- AcmeCity.com
site or link: mail here.
- PolBox.com
site or link: mail here.
- FortuneCity.com
site or link: mail here.
..if you found
a crack on a page forwarded by a redirection
service:
- http://???.to/???
-> send mail here or here or here.
- http://???.tsx.org/
-> send mail here.
- http://???.findhere.com/
-> send mail here.
- http://???.cjb.net/
-> send mail here.
- http://???.da.ru
-> send mail here.
- http://???.mainpage.net
-> send mail here.
- http://???.Web-Page.net
-> send mail here.
- http://???.MainPage.net
-> send mail here.
- http://???.GamesPage.com
-> send mail here.
- http://???.Main-Page.net
-> send mail here.
- http://???.MusicPage.com
-> send mail here.
- http://???.SexyPage.net
-> send mail here.
- http://???.Biz-Page.com
-> send mail here.
- http://???.Co-Inc.net
-> send mail here.
- http://???.Co-Ltd.net
-> send mail here.
- http://???.Pty-Ltd.net
-> send mail here.
- http://???.Pte-Ltd.net
-> send mail here.
- http://???.Int-Ltd.net
-> send mail here.
- http://???.Intl-Ltd.net
-> send mail here.
- http://???.TourGuide.net
-> send mail here.
- http://???.Net-Shop.net
-> send mail here.
- http://???.Subdomain.de
-> send mail here.
..if you found
mailing list or newsgroup messages
offering or linking to cracks posted from:
- ???@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).
Where
to report cracking pages found at asean sites
..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.
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 copyright
infringement.
Myth: "I
thought it was okay to download programs to try them out
if I delete them within 24 hours."
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 your problems.
Myth: Writing
a book about robbing banks and robbing them yourself are
two different things, not?
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 compensation!
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 permission.
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
Programming-related
stuff
- efg's CRC Lab good explanation
of the "Cyclic Redundancy Check"
algorithm and coding examples
Just some thoughts..
:-)
Richey
Thanks to
Fravia+ and BuLLeT (both of them crackers), who allowed
me to quote some of their experiences and knowledge on
this page.
|
|