🚀 go-pugleaf

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

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

Larry Motylinski <larry@pronet.mpro.net> wrote:
>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.

	And if the system is a hospital's database, or something
mission critical and life-threatening, and they change their
hardware, you'll get a call from their lawyers if it was your
stupid copy protect that caused downtime. Think carefully before
you do something that will put your customers out of business
as a means of protecting your software against them!

mjr.
-- 
Chief Scientist, V-ONE Corporation  --  "Security for a connected world"
work            http://www.v-one.com
personal        http://www.clark.net/pub/mjr/mjr-top.html

In article <4jbpkj$eo5@clark.net>, Marcus J. Ranum <mjr@clark.net> wrote:
>Larry Motylinski <larry@pronet.mpro.net> wrote:
>	And if the system is a hospital's database, or something
>mission critical and life-threatening, and they change their
>hardware, you'll get a call from their lawyers if it was your
>stupid copy protect that caused downtime. Think carefully before
>you do something that will put your customers out of business
>as a means of protecting your software against them!

As a systems administrator for company with a lot of software which 
is node locked (or where the licence servers are node locked), having 
software and/or techniques for keeping mission critical software 
running temporarily in the event of a hardware change is an essential 
part of a disaster recovery plan. 

I probably don't need to say it, but many vendors take two or three 
business days to issue new keys (forms need to be filled out and 
faxed to the vendor).  The thought of having to do this in a rush for 
two dozen applications, and having MY customers wait to be able to 
use the applications they need until all of these companies send me 
new keys, is just frightening. Of course, servers can fail on weekends
or during the night, when the licence key issuing folks are unavailable.

If you have Sun workstations and servers, you can use my software for
short term hostid spoofing, as part of a disaster recovery plan.

ftp://ftp.netcom.com/pub/he/henderso/change-sun-hostid.tar.gz
ftp://ftp.wimsey.com/pub/crypto/sun-stuff/change-sun-hostid.tar.gz
http://www.squirrel.com/squirrel/sun-stuff/change-sun-hostid.tar.gz

Please don't use change-sun-hostid to steal software. But DO use it 
to keep your critical applications up and running in the event of 
server failure, while you contact vendors for new licence keys. 

-- 
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

In article <hendersoDoxuAu.7uv@netcom.com>,
Mark C. Henderson <henderso@netcom.com> wrote:
 >In article <4jbpkj$eo5@clark.net>, Marcus J. Ranum <mjr@clark.net> wrote:
 >>Larry Motylinski <larry@pronet.mpro.net> wrote:
 >>	And if the system is a hospital's database, or something
 >>mission critical and life-threatening, and they change their
 >>hardware, you'll get a call from their lawyers if it was your
 >>stupid copy protect that caused downtime. Think carefully before
 >>you do something that will put your customers out of business
 >>as a means of protecting your software against them!
 >
 >As a systems administrator for company with a lot of software which 
 >is node locked (or where the licence servers are node locked), having 
 >software and/or techniques for keeping mission critical software 
 >running temporarily in the event of a hardware change is an essential 
 >part of a disaster recovery plan. 

How about not putting any stupid funny business into the software? What a novel
idea that is. Or maybe even selling the poor users a source code
license! Imagine that...

Viewing a customer as a hostile turns him into an enemy.

-- 

 +---- mjr@clark.net wrote (27 Mar 1996 11:16:19 -0500):
 | Larry Motylinski <larry@pronet.mpro.net> wrote:
 | >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.
 | 
 | 	And if the system is a hospital's database, or something
 | mission critical and life-threatening, and they change their
 | hardware, you'll get a call from their lawyers if it was your
 | stupid copy protect that caused downtime. Think carefully before
 | you do something that will put your customers out of business
 | as a means of protecting your software against them!
 +----

I have a fuzzy memory of cripple tactics like the above being
illegal.  But it might have been specific to consultants and
time bombs (used to ensure a clients timely accounts payable).

-- 
Gary Johnson     "I'd a done sumpin too, but I ain't no Peckerton Ditinctive."
gjohnson@season.com
                            CAMPAIGN '96: Juck 'em if they can't fake a toke.

In article <slrn4ljapj.ar.gjohnson@dream.season.com>,
Reality is a point of view <gjohnson@dream.season.com> wrote:
>
>I have a fuzzy memory of cripple tactics like the above being
>illegal.  But it might have been specific to consultants and
>time bombs (used to ensure a clients timely accounts payable).

So many people implement schemes to try to "enforce" licence agreements,
that it would surprise me if it were illegal.

I'd rather there were no licence managers, and that vendors trusted
their paying customers.

On the other hand, the licence managers do play one important role, 
that is, tracking of licence usage. In that sense they help a company 
keep track of what licenses it is using, and avoid the situation 
where a company inadvertently is pirating software, because they only 
have a certain number of licenses for a certain feature, and they 
have exceeded it. 

So, what I'd really like is the best of both worlds. A licence 
tracking scheme that would allow the users to continue to use the 
application if too many licenses were being used, but one that would 
notify me of the situation so that the appropriate corrective action 
can take place. In the case of too many users, either we buy more 
licenses or ensure that their are fewer users.

The essential problem with most licence managers is that their 
default, if they can't verify that there is a valid licence available 
for the application in question, is to deny someone access to the 
application. Better, let the user run the application and notify the 
user and/or the systems administrator that there is a problem with 
the licensing. 

Licence tracking without denial of service in the case of licensing 
problems would provide a service both to the vendor and the customer. 

-- 
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

In <4ja11e$e1m@mpro1.mpro.net> larry@pronet.mpro.net (Larry Motylinski) writes:

[snip]
>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

And how portable would this be to UNIX systems in general?
-- 
Jonathan Chen <jonc@pinnacle.co.nz>
--
~/.signature: Permission denied

In article <4jc6kpINN3m3@mayne.ugrad.cs.ubc.ca>,
c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku) wrote:

 >Viewing a customer as a hostile turns him into an enemy.

Amen.

---
The above are my own opinions, and not those of my employer.