To all those who have experience with marketing their own software, do you
have any suggestions on how I can protect a software package I just wrote?
I will definately not sell more than 1000 copies and more likely, not more
than a couple hundred.
It's a front-end for another software package made by Johnson Controls that
is a HUGE time-saver. If it becomes popular, I'm wondering if I'll have any
way of keeping Johnson from just duplicating it's function and integrating
it into their own product without any compensation for my efforts in
developing it.
Also, I'm working on a limited use version that I can freely distribute and
allow the user to use either for a certain number of times or for a certain
length of time before it requires purchase. Any thoughts on the best way of
doing this? I thought of using the registry, but that's too easy to hack,
unless it's encoded somehow and the user doesn't know what their looking
at... Or, maybe doing something simliar to Microsoft in requiring online
registration, but I hate having to do that with M$'s crap, so I'd rather not
do it with my own software.
In all likelihood, if they want it, they'll get it. There isn't much out
there that can't be cracked. It's hard when you're a small fish swimming in
a big ocean - I've developed software that got picked up (without
compensation to me) by another company and what am I supposed to do? Take
them to court?
There are trial ware tools out there, i.e. DLL's that you incorporate into
your software that are pretty cheap... nothing comes to mind at the moment,
but just do a search on it.
NOW, if you want to know what the crackers are doing to people's software,
go to http://astalavista.box.sk/ and look around that website. I used it to
develop my own software protection scheme (which took me 3 months to develop
and hackers 3 minutes to disable).
My final suggestion... sell as many as you can before you get ripped off!
OR maybe talk with Johnson and see if they'll buy the idea off you... I did
that and made a pretty penny and I passed on the software protection problem
to them! You WILL be spending way too much time developing a scheme. Is it
really worth it? My experience tells me no.
Sell man, sell!!
I visit astalavista periodically, which is why I wanted to ask here before
developing an elaborate protection scheme. I'll probably do some simple
challenge/response type thing where they can use a temporary code e-mailed
to them upon download, but they have to e-mail in a locally generated code
that will be use to generate a key that is e-mailed back. Then store that
key somewhere deep in the registry. The only problem is, before I re-invent
the wheel, is there some information already out there on what kind of math
to use for generating these keys? I've been doing searches on Google about
authorization codes, but after sifting through debates on Microsoft's
methods, I've gotten nowhere.
> Barry,
>
> In all likelihood, if they want it, they'll get it. There isn't much out
> there that can't be cracked. It's hard when you're a small fish swimming
in
> a big ocean - I've developed software that got picked up (without
> compensation to me) by another company and what am I supposed to do? Take
> them to court?
> There are trial ware tools out there, i.e. DLL's that you incorporate into
> your software that are pretty cheap... nothing comes to mind at the
moment,
> but just do a search on it.
> NOW, if you want to know what the crackers are doing to people's software,
> go to http://astalavista.box.sk/ and look around that website. I used it
to
> develop my own software protection scheme (which took me 3 months to
develop
> and hackers 3 minutes to disable).
> My final suggestion... sell as many as you can before you get ripped off!
> OR maybe talk with Johnson and see if they'll buy the idea off you... I
did
> that and made a pretty penny and I passed on the software protection
problem
> to them! You WILL be spending way too much time developing a scheme. Is
it
> really worth it? My experience tells me no.
> Sell man, sell!!
>
> S. Wright
> "Why is everyone else so insecure?"
>
>
>
> {Original Message removed}
You have to accept that what ever you do CAN and WILL be broken - there is
no way around it. This is a natural consequence of not having absolute
control over the hardware your software is executing on. The user can do
anything they like and so can break your system.
Having said that, you have to look at it and say how much effort is really
worth it?
You can with reasonable ease develop a system that will stop the average
user from copying your program and giving it to their friends. With a little
extra work, you can make something that you can't write a "key gen" for
(unless they can break a public key crypto system), but you can always write
a patch to remove the protection.
I used a combination of cryptographic Hashes and RSA Public Key crypto. The
basic idea is that you create a block of data containing all the settings
for your program security and the user identification. This is hashed and
digitally signed - this signature is your key. You store this where ever
takes your fancy along with the security information used to generate the
hash. When you start up to check that the signature (the licence key)
matches the information stored and if it does you run, if not then the
license is invalid.
Its a little more complex than that, but that is essentially how I did it.
A word of warning: NEVER AUTO GENERATE keys from a web site. It is far too
easy for someone to just enter a false name etc and the distribute that
perfectly valid key to the world.
I have code (C++) that does this and manages it all if your interested in
licensing it for a small fee. Or I'm happy to discuss how to do it off list
if you like.
Thanks for the info! I would like to do this myself (not using someone
elses code) so I can learn how it's done. But, I would like to discuss the
methods of how hashes are created.
> Hi Barry,
>
> I've done some software protection code before..
>
> You have to accept that what ever you do CAN and WILL be broken - there is
> no way around it. This is a natural consequence of not having absolute
> control over the hardware your software is executing on. The user can do
> anything they like and so can break your system.
>
> Having said that, you have to look at it and say how much effort is really
> worth it?
>
> You can with reasonable ease develop a system that will stop the average
> user from copying your program and giving it to their friends. With a
little
> extra work, you can make something that you can't write a "key gen" for
> (unless they can break a public key crypto system), but you can always
write
> a patch to remove the protection.
>
> I used a combination of cryptographic Hashes and RSA Public Key crypto.
The {Quote hidden}
> basic idea is that you create a block of data containing all the settings
> for your program security and the user identification. This is hashed and
> digitally signed - this signature is your key. You store this where ever
> takes your fancy along with the security information used to generate the
> hash. When you start up to check that the signature (the licence key)
> matches the information stored and if it does you run, if not then the
> license is invalid.
>
> Its a little more complex than that, but that is essentially how I did it.
>
> A word of warning: NEVER AUTO GENERATE keys from a web site. It is far too
> easy for someone to just enter a false name etc and the distribute that
> perfectly valid key to the world.
>
> I have code (C++) that does this and manages it all if your interested in
> licensing it for a small fee. Or I'm happy to discuss how to do it off
No problem. That's also why I wrote my own :) But I had done some crypto
stuff before..
If you can find it, get a copy of "Applied Cryptography" by Bruce Schneier.
ISBN 0-471-11709-9. This is a wealth of information about all kinds of
crypto and explains why/how/when to use it very well. It as sample code for
most of the common Hash functions and a lot of crypto systems. Also there
are many web sites that have code for RSA (and its patent has expired now)
to use.
If you aren't sure what a Hash (also called a message digest) is, it is
basically a way to take the contents of a message and compute a unique
(large) number. The idea is that no two messages will give you the same
number and you can not recover the message from the number. They are often
used to verify that the contents of a message have not been altered. Almost
like a CRC.. but MUCH bigger and better. Look for "SHA" (sometimes called
"SHS") and "MD5". These are the most common. I used SHA. SHA generates a 160
bit number, MD5 a 128 bit number.
You then take this number and sign it with a private key that you and you
alone keep. You distribute the public key with the application. To verify
the license code (the signed hash) you compute the hash of the registration
information (as was submitted for registration) then "decode" the key using
the public key. If they match all is well.
This works because the encryption (signing) of the key is not symmetric -
just because you have the public key, you can't compute the private key. And
the public key only decrypts what was encrypted by the private key (and
visa-versa).
Hope that helps a bit.. Contact me off list as this is pretty off topic if
you want to know more.
At 01:32 PM 5/9/02 +1000, you wrote:
>If you aren't sure what a Hash (also called a message digest) is, it is
>basically a way to take the contents of a message and compute a unique
>(large) number. The idea is that no two messages will give you the same
>number and you can not recover the message from the number. They are often
>used to verify that the contents of a message have not been altered. Almost
>like a CRC.. but MUCH bigger and better. Look for "SHA" (sometimes called
>"SHS") and "MD5". These are the most common. I used SHA. SHA generates a 160
>bit number, MD5 a 128 bit number.
Hi Ash,
I don't think you really mean unique, do you? If the number is shorter than
the message then there MUST be more than one message that gives you the
same number.
Yes, your "kind" of correct.. My explanation was a little simplified. But
for all practical purposes with a good hash you can just about say the
number is unique.
The hash lengths are commonly 128 bit (MD5) or 160 bit (SHA). With that
number of bits I'm pretty sure you can assign a unique number to EACH and
EVERY particle in the universe and still have some left over! I remember
reading this about UUIDs (Universal Unique IDentifiers, used in software
like COM and other object broker systems) which are 128 bit if I remember
correctly.
The "strength" of a Hash can be measured by the number of different messages
that hash to the same key and also how many of the bits change for each bit
of the message. How they determine this I don't know - I just use the
algorithms :)
It is possible to several messages to map to the same hash, but the hash
function is specifically designed so that the only possible way to workout
the "collisions" is by brute force. It is also far more improbable that two
"useful" messages will map to the same hash.
>I visit astalavista periodically, which is why I wanted to ask here before
>developing an elaborate protection scheme. I'll probably do some simple
>challenge/response type thing where they can use a temporary code e-mailed
>to them upon download, but they have to e-mail in a locally generated code
>that will be use to generate a key that is e-mailed back. Then store that
>key somewhere deep in the registry. The only problem is, before I re-invent
>the wheel, is there some information already out there on what kind of math
>to use for generating these keys? I've been doing searches on Google about
>authorization codes, but after sifting through debates on Microsoft's
>methods, I've gotten nowhere.
>
>
The best method would probably be to use RSA signatures.
You don't say what language you use. If it is VB then try http://www.activelock.com. It is an ocx file which you integrate with your
application. It is free. You may be asked to fill in your details - it is
not compulsary. Is there a catch? I don't know, but I've used it sucessfully
to deter casual theft. I've no idea how good it really is against a
determined hacker. The source code is now available so mayb someone who
knows about this stuff can tell us all.
As it is a limited market, your best bet is to make a deal with the company.
They would save themselves some development time if they haven't already
started on a new version.
Barry,
I'd suggest looking at the Diffie-Hellman protocol for the generation of
the key - it may give you what you need.
The key, or a subset of it, can then be used with whatever encryption
algorithm you choose.
For obvious reasons I cannot elaborate further but I'd suggest reading the
reknowned "Applied Cryptography" for a good explanation and examples.
John
>You don't say what language you use. If it is VB then try
>http://www.activelock.com. It is an ocx file which you integrate with your
>application. It is free. You may be asked to fill in your details - it is
>not compulsary. Is there a catch? I don't know, but I've used it sucessfully
>to deter casual theft. I've no idea how good it really is against a
>determined hacker. The source code is now available so mayb someone who
>knows about this stuff can tell us all.
>
>As it is a limited market, your best bet is to make a deal with the company.
>They would save themselves some development time if they haven't already
>started on a new version.
>
>Hope this helps
>
>Joe
>
>
according to the howto at
www.internetion.net/ActiveLock/activelock.asp
it's a 5 seconds job to remove the thing with IDA.
the code to use it is like :
*If .UsedDays <21 Then*
frmRegister.Show 1
Calculator.Show
Else
' If the evaluation period has expired...
MsgBox "Your evaluation period has expired!"
Unload frmRegister
Unload Calculator
End If
which, to patch, only requires a basic "nop the test out" patch.
in my opinion, it would only stand with joe shmoe, not the determined
cracker.
Another great value reference:
A. Menezes, P. Oorschot and S. Vanstone, "Handbook of applied cryptography," CRC Press, 1996
All chapters are available for free download at http://cacr.math.uwaterloo.ca/hac/.
See http://www.mindspring.com/~pate/C for the implementations in C language of most of the algorithms.
Regards
Romeo Costanzo
> For obvious reasons I cannot elaborate further but I'd
> suggest reading the
> reknowned "Applied Cryptography" for a good explanation and examples.
> John
>
-- http://www.piclist.com hint: The PICList is archived three different
ways. See http://www.piclist.com/#archives for details.
>Your opinion is quite valid, but even hardware dongles don't withstand the
>determined hacker...........
>
>Joe
>
>
of course, this depends on how the dongle is implemented.
Most dongle-based systems are badly implemented.
The properly implemented dongle systems (for instance the leich
videoguard system is such a system, even if it does not protect
software, but video programmings) perform most of the protection
procedure through the decryption of data by the dongle itself (keys are
stored inside).
properly done, this is virtually uncrackable.
I understand your dilemma however I must point out that with Soft Ice,
anybody can find the code that verifies any authorization code.
For example, you set up an elaborate email/code scheme. I try it out and
find I can't get past the prompt without entering a valid code... hmmm.....
so I go into softice, locate the routine, find the 'cmp' and 'jne' codes and
simply NOP them out.
I've just bypassed your protection routine.
Again, I say that if they really want it without having to pay for it,
they'll get it. I'm no condoning hacking, it's just that I've gone through
all this frustration before.
I've followed this thread with great interest. I'm just wondering... If
crackers and hackers are so good, why then have I not heard of someone being
able to crack Windows XP / Office XP (not wait... this has been done, if I'm
not mistaken)... OK. So, I've never heard of someone being able to write a
keygen for Microsoft's new 25 character CD key system. Does anyone have an
idea what kind of encoding/encryption they use? If I could do the same, then
maybe my software will also be protected as well (or not).
My idea of making money with software is (as previously said by someone
else) to write the program as bug-free as possible, and then immediately
sell it to a bigger company that can take the developement further.
As Amaury said, replacing the protection code by NOP's is an easy way around
protection and can easily beat tough CD protection systems such as safedisc.
In my opinion, if the software must be THAT secure, Hash the user's
registration details along with the processor serial number and let the
program mail the user details (and CPU serial number) to a registration
e-mail address(This must be automated so that the user can't conveniently
change the reported CPU serial number before sending). Then have a mail
processor/registration program on the software developer's side also hash
the same details. Use RSA encryption to encrypt the resulting hash value and
keep the user details on record!. The encrypted hash value and public key
should then be returned to the user, who feeds it into the program. The
program then decrypts the received encrypted hash value using the public key
and compare this to the original hash value. If the two hash values are the
same, then voila! Registration successfull. The limit would be however that
if the user wants to reload the software on a new computer, they will have
to reregister.
Does this scheme make sense, or am I talking nonsense?
I'm no expert, but I'm afraid I have to disagree. Once you lose physical
control over the hardware key the user/attacker can bring any technology
they like to bear against it with little chance of being discovered.
I agree that some hardware dongles are not well implemented but the point is
mute when talking about computer software as other posters have also pointed
out - you just remove the checks from the program code and game over.
The video protection systems also suffer because there is no way to stop a
sufficiently determined attacker with even a modest budget attacking the
dongle physically. They could just micro-probe the CPU in the dongle to
extract the keys and again your protection is worth nothing.
This has happened with numerous satellite broadcast systems already. You can
find people on the Net that sell home-made smart cards using PICs that
decode the broadcasts. There are also web sites describing how these attacks
are done and also incidentally using the same techniques to extract code
from copy protected microcontrollers including PICs.
I can not condone this activity, but one must be realistic - at best your
going to slow them down a little, but these people thrive on that challenge.
It is something of a game to them; the more difficult or "interesting" you
make it the more they will try to break it.
Its depressing, but that is the way things are.. You can only do so much.
The honest people will pay for your program, the dishonest would never have
bought it anyway..
At 12:23 PM 5/9/02 +0100, you wrote:
>Your opinion is quite valid, but even hardware dongles don't withstand the
>determined hacker...........
And things like node-locking, dongles, and software that uses disk related
protection schemes invariably inconveniences the legitimate user. Protel's
demo (not sure about the final version) can lock itself out if you defrag
your disk, for example. Physical dongles can be damaged, fail or get lost.
I get the impression that skilled hackers can get past most any kind of
protection very quickly. And, they give their work away, a terrible kind
of competition under the capitalist system.
In my experience, the software that gets cracked is the SW that's in
demand by a lot of users - the smaller the number of users, the less
chance of somebody going to the trouble to crack it. Cost of the SW
is also important - the cheaper, the less reason to crack.
At the moment my scheme works like this:
1. When the user installs the SW, a control file gets written in the
working directory.
2. An installation request is sent to me by e-mail.
3. Once I authorize the user - even a shareware one - I send a release
code back by e-mail.
4. The user is allowed to fill in registration details, and a file is
e-mailed to me.
5. I update an on-line database with the number of times/date of
validity.
6. Every time the user starts the SW, it validates over the 'net. If
no connection, it can be used for 24 hourse before time-out.
7. In the SW is a CRC embedded that checks that the JNE etc does not
get changed.
8. It also checks the control file to check illegal changes
Being a specialist package, it is not worth it for a cracker to try
and gippo the SW, although I do not proclaim it to be impossible. It
is just not worth the effort, and the market is not big enough that a
demand exist for it to be cracked.
Some people crack SW to prove they can. Some because they do not like
you, and will flood the market with cracks for your SW. If the price
is right, the support great, updates when promissed etc. the
protection is a registration rather than protection.
> The only solution that I have come up with is NOT actually
> running the program on their computer! It may seem strange,
> but if the problem is that you can't trust the user, then
> simply don't!
>
Agreed :-)
I actually work in antivirus and am pretty sure I could hack almost
anything. My front end software at virtualbreadboard.com is protection free
(Version 2 BETA has just been released) but the core technology under the
hood, which is the micro-java 'just in time compiler' will be delivered as
an internet service. Still doesn't protect from hacking the chip but is a
pretty good start.
Fortunately, I'm working with people that are generally not considered
hackers. Also, the market is very small, but the package cost is going to
be kinda high in order to make the development time worthwile. But, it is
also justified by the amount of time this tool saves. That high cost
($800-$1000) is quickly compensated after just a few uses of the software.
Also, when considering that the average building automation system projects
are bid in the tens to hundreds of thousands, it only takes a few jobs to
absorb that initial cost. I assume hacking will not be a problem, but I
don't want it to be spread around for free, so I gotta put something in
there for basic copy protection.
I've decided to make it runnable immediately after download, but with a 7
day limit. If a valid key isn't detected, it will show the register splash
and update the registry with the last run date/time. Upon exit, if the
clock has changed to a time prior to starting the software, it will warn the
user that the rest of their demo time will expire on the next run unless
their clock is restored to normal time. At the end of 7 days, it will
require a key that will be provided by e-mail after payment is received.
One nice thing I just found out is that Visual Studio .NET has cryptography
routines included. So, I may be able to get this to our first customers by
next week.
My biggest concern is if Johnson Controls decides that they like it, what's
to stop them from just duplicating the functionality of my program and
integrating it into their own product without compensation? We are planning
on offering it to them, but if they turn down the offer, we're going to do
our own marketing. They may see how much time is saved after their branches
start using the product and change their mind.
>My biggest concern is if Johnson Controls decides that they like it, what's
>to stop them from just duplicating the functionality of my program and
>integrating it into their own product without compensation?
I guess they will pay you what they think it would cost them to duplicate
it.
>My biggest concern is if Johnson Controls decides that they like it, what's
>to stop them from just duplicating the functionality of my program and
>integrating it into their own product without compensation? We are planning
>on offering it to them, but if they turn down the offer, we're going to do
>our own marketing. They may see how much time is saved after their branches
>start using the product and change their mind.
>
That you have virtually no chance of preventing, unless you want *and*
can get a patent for your software.
There is no way you can prevent a blank page implementation of your
software by some other person.
as you said, duplicating is not using your software, which would be
copyright violation, but, as explained above, blank page implementation.
VAX2.CONCORDIA.CA>
