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: Chris Ridd <email@hidden>
- Date: Wed, 25 Sep 2002 15:25:58 +0100
On 24/9/02 4:41 pm, Jeremy Dronfield <email@hidden> 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.
>
>
Is there a way round this?
If I recall, FlexLM needs to store a secret in the binary and it handles
this problem by splitting up the secret into several pieces and making sure
they're scattered around the data segment. It also strips symbols so that if
you step through with a debugger you can't (easily) work out that a
particular function's being called to reassemble the secret. It's
obfuscation, basically.
I'm probably oversimplifying a bit, but that's how I remember it.
Cheers,
Chris
_______________________________________________
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.