Article View: comp.os.linux.misc
Article #58Re: binaries (generated from "C" code)
From: Mark C. Henderson
Date: Tue, 26 Mar 1996 16:43
Date: Tue, 26 Mar 1996 16:43
56 lines
3244 bytes
3244 bytes
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. -- Mark Henderson -- markh@wimsey.bc.ca, henderso@netcom.com (personal accounts) ViaCrypt PGP Key Fingerprint: 21 F6 AF 2B 6A 8A 0B E1 A1 2A 2A 06 4A D5 92 46 http://www.squirrel.com/squirrel/ - change-sun-hostid, unstrip for Solaris, computer security, TECO, FGMP, Sun NVRAM/hostid FAQ, Wimsey crypto archive
Technical Details
Message-ID:
<hendersoDovvs3.20G@netcom.com>Path:
arc1-ca.pugleaf.net!netcom.com!hendersoReferences:
<4j7pge$9ga@xanadu.io.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.os.linux.misc,comp.lang.c,comp.unix.admin,comp.security.unix Path: arc1-ca.pugleaf.net!netcom.com!henderso From: henderso@netcom.com (Mark C. Henderson) Subject: Re: binaries (generated from "C" code) Message-ID: <hendersoDovvs3.20G@netcom.com> Organization: Netcom References: <4j7pge$9ga@xanadu.io.com> Date: Tue, 26 Mar 1996 16:43:14 GMT Sender: henderso@netcom16.netcom.com