🚀 go-pugleaf

henderso@netcom.com (Mark C. Henderson) wrote:

>In article <4j7pge$9ga@xanadu.io.com>, Casey Claiborne <mskc@io.com> wrote:
>>Hello,
>>	I have a question that I am hoping someone out there can
>>help me with. I have a binary that was generated using "C" code.
>>Is there any way that I can ensure that the binary generated will
>>run on one machine? I have heard that some vendors use licensing
>>but I am not exactly sure how this works. Any advice, help or
>>hints on the matter would be *greatly* appreciated :)

>Well, the trick is to have some sort of key based upon a unique identifier
>for the machine. Most commercial UNIX systems give you a call to get
>some sort of serial number which, in theory, is unique to the machine.

>One simple way to do this is to build yourself a hash function based
>upon MD5, SHS, or something similar. Then make a licence file with
>the serial number and the hash.

>e.g.
>123456912     CB5870B1FBA4E4E24392

>The program can check the serial number of the machine it is running on,
>calculate the hash, and validate the key.

>Of course, this is completely insecure. Folks can just modify the binary
>so that the licence checker is not called. Worse, they can generate
>a valid key by spying on the program with a debugger. But the expensive
>commercial schemes generally also have these flaws. You also need to
>trust the operating system (something not under the programs control)
>to report the correct serial number. This assumption can be fatal
>(e.g. see http://www.squirrel.com/squirrel/sun-stuff/change-sun-hostid.tar.gz
>for Sun/Solaris examples which allow you to alter this serial number as 
>reported by the OS).

>Of course, you could do a lot better. Perhaps use an encryption function
>to generate the key, and don't embed it in the code for the binary. This
>way our cracker has to try to reverse your decryption function. Also
>initialise a few critical constants in your licence verification routine. 
>This way, if someone tries to bypass it, the program will malfunction.

>See, 
>ftp://utopia.hacktic.nl/pub/replay/pub/cracking/license.asc.gz
>for some information on how to make such a scheme harder to crack.

>There are no guarantees, but if you are willing to put some work into
>making this sort of thing more secure, you can, at least, make it so that
>the potential crackers has a few hours of work ahead of him/her.

>The other alternative is to go with a dongle. People also have ways of
>getting around them, and they are generally very annoying, especially if
>your customer has to use more than one.

What I used to do is read the CMOS and other eproms (looking for a
serial number or something that made it unique) and then encrypt that
code in a program.  The program (when run) would verify this
information.  It kinda sucks because you will be the one to get a call
if they change their hardware.  I used to use the lower memory block
in dos to see what hardware they had and build that into the program
also.  Another trick I used to use was using tracks on a floppy that
didn't technically exist (track 81) and that only worked with very
low-level programming (I used assembler to access the track).

Hope this helps