Re: Reading Executable Files [was Re: Licences 101 - Copy Protection for Newbies]
Re: Reading Executable Files [was Re: Licences 101 - Copy Protection for Newbies]
- Subject: Re: Reading Executable Files [was Re: Licences 101 - Copy Protection for Newbies]
- From: Eric Dahlman <email@hidden>
- Date: Tue, 24 Sep 2002 12:05:43 -0500
On Tuesday, September 24, 2002, at 10:41 AM, Jeremy Dronfield wrote:
I've gained some very good pointers from this Copy Protection thread -
thanks. There's one thing I still don't understand, however, and it's
illustrated by this:
On Monday, September 23, 2002, at 04:08 pm, Peter Sichel wrote:
(1) If you use a key checking algorithm (some hash of the users
name, organization, date, etc...) do not include the code
needed to generate valid keys within the software you supply to
customers. You can avoid this by encrypting the generated key
and then decrypting it in your application before applying
your key checking algorithm.
With encryption, however many layers of encoding, ciphering and
hashing you use to obscure the values you're working with, there's got
to be a fixed final key somewhere in the program code. And as far as I
can tell, that key will be there for all to see in the executable
file. I mean, you don't need any specialist software - just open up
the executable in TextEdit and there it is, all your obj-C code, all
jumbled-up to be sure, but there nonetheless, including the
holy-of-holies, your decryption key(s). How can you avoid this?
Switching off debugging symbols and setting the compiler to More
Optimized, Less Debuggable has no effect. And even if you disguise it,
the key is still going to be present. And even if it isn't, because
you've hidden it in a file somewhere else, the code that knows where
to find it is.
Your key does not need to be present if you are using a public key
encryption algorithm. Then your program just needs to include the
public key. Then when creating the license you would sign that with
the private key and send it to the user. The client program then only
needs to use the public key to verify the voracity of the license. The
point being that the private key need not ever be on the user's
computer and you could present them the public decryption keys in big
flashing lights and have nothing to fear.
If you are up against someone with a debugger and a hex editor though
you really can only make things annoying for them. Ultimately, in you
code there will need to be a check to see if the license is valid. All
it takes to crack your program is to identify that check and change the
branch comparison. Computing a hash on the executable or some such
thing is just an instance of the same problem so they have to do twice
the work, big deal. Adding multiple checks is just and extensions of
this but don't be fooled by the idea that ten checks are ten times
harder to crack, they have search and replace to ;-).
One thing that works a little better is to include a bit of "code"
(like an array for redirecting function calls) in the license which is
encrypted and needed for full operation of the application. The
problem with that is that this is secure only until you have your first
customer. The decrypted information can then be pulled from a running
licensed copy of the program and "injected" into the cracked version.
Until all processors are licensed and the Thought Police (tm) are
empowered to raid your home and arrest you for running a debugger the
fact of the matter is that the crackers are mathematically guaranteed
to win in the end. Your goal should not be total security since it is
unattainable, instead you should look at the cost/benefit of the
deterrents you are including. Remember your time is valuable! If
you invest a month in making SuperFrobber 1.4 harder to crack and get
200 more customers as a result would that time have been better spent
version 2.0 or implementing Quuxter 1.0? As my father would say "Don't
step over dollars to pick up dimes!"
I guess my point is that I have seen lots of shareware programs where
the author would have been clearly better served by spending more time
on the app than the copy scheme, don't fall into that trap.
-Eric
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.