>Changing the system time introduces all kinds of problems, so most >potential license abusers won't do it. A two-line shell script with a >6-line C program is a very cheap attack on a dynamically-linked >license manager daemon. Attacking a statically-linked license manager >binary is quite a bit more expensive, and should greatly reduce the >incentive for an attack. License managers really only protect you again honest customers using more (cconcurrent copies of) software than they paid for. In that context, tamper proofing is perhaps ill advised because of both the drawbacks and the ease of circumventing them: - statically linked binaries require you to release a new version of your product each OS release, if you're unlucky. I've seen statically linked license daemons break going from Solaris 2.5.1 to 2.6 (-lsocket) Solaris 2.3 or 2.4 changed the way gettimeofday() worked, so statically linking that also broke. - in some cases (flexlm), you need to statically link both the licensemanager and all products using it. And the 3rd point: it's really not much more difficult to write an LD_PRELOAD than it is to write a program that uses /proc or ptrace() on system calls and substitutes return values of its liking. (I've done that for hostids on SunOS 4.x) Statically linking raises the bar only a little; the maintenance costs, however, may soar and customer satisfaction may very well decline. (What do you mean, I need a different version of your product for each of the four Solaris releases I'm currently using? Can I have a version with libc bug X fixed?) Casper
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:45:54 PDT