Licensing source code.

[Scrag Meister]

Many years ago, I wrote a small app that was used by 5 or 6 clients, with a few users each.

I actually got the app to edit itself and inject data and licence information into the string table in the .EXE that I had previously setup, when it was compiled.

i.e. Initially the string was something innocuous like "Gopher00000000000000000000000", I would then look for Gopher in the EXE and update the zeroes bit to be the licence date, licence id, PC name.

So that once it was running it would be "Gopher" + 4 ascii chars for the expiry date + "HTH0001WLDNPC004"

It would self check whenever it was invoked, or certain functionality was run within the app, worked a treat for many years.

Would pop a screen starting 14 days from renewal and they needed to contact us to renew it, with some code we generated.

Stopped them copying it to other machines to run cos the PC name had to tie up, stopped the app when it expired.

 

[SupremeSpod]

Many years ago, I wrote a small app that was used by 5 or 6 clients, with a few users each.

I actually got the app to edit itself and inject data and licence information into the string table in the .EXE that I had previously setup, when it was compiled.

i.e. Initially the string was something innocuous like "Gopher00000000000000000000000", I would then look for Gopher in the EXE and update the zeroes bit to be the licence date, licence id, PC name.

So that once it was running it would be "Gopher" + 4 ascii chars for the expiry date + "HTH0001WLDNPC004"

It would self check whenever it was invoked, or certain functionality was run within the app, worked a treat for many years.

Would pop a screen starting 14 days from renewal and they needed to contact us to renew it, with some code we generated.

Stopped them copying it to other machines to run cos the PC name had to tie up, stopped the app when it expired.

I like it.

 

[d000hg]

Isn't that the kind of thing which gets anti-virus software a bit overexcited?

 

[Scrag Meister]

Isn't that the kind of thing which gets anti-virus software a bit overexcited?

You may well be right in this day and age, but I think our main company file server had 117Mb drive in it at the time.

Just an idea. Which may inspire SS with a solution to his problem. Self contained licence monitoring.

Unless there is some nosey techie user, or the general public would be interested then it is really unlikely that someone is going to bother to go hex-dumping and checking string tables etc..

Depends on the type and size of the user-base.

 

[Platypus]

Unless there is some nosey techie user, or the general public would be interested then it is really unlikely that someone is going to bother to go hex-dumping and checking string tables etc..

A few years ago I did something similar. However I had a long randomly generated string and I injected the data I was interested in, byte at a time, into this long string. So I would find my licence key by getting the characters at positions 7,23,99,123,47,22,44 and so on (I pre-selected these random numbers). And also a checksum in case someone went hacking. Because the whole string looked totally random, there was no chance that someone could dump the string table (or file, in my case) and see the licence info.

mystr[0] = randomstr[7];
mystr[1] = randomstr[23];
mystr[2] = randomstr[99];
etc.

EDIT: in my case, the string was in a file, not the exe. And I used the machine's IP address, not nodename, to tie it.

 

[doodab]

It's quite possible to implement a challenge / response activation system that works offline, so I wouldn't rule that out altogether. Nearly all of the online one's I've seen offer an offline fallback.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

Whatever scheme you use for the licensing, the bigger problem is writing licensing checks into the code in such a way that it doesn't degrade performance and it isn't trivially easy to circumvent or replace the license checks with a stub. If you are supplying source code then you make this method of avoidance much easier, to the point where I'd say you're more or less wasting your time unless you are going to turn your product into unreadable difficult to maintain spaghetti.

 

[SupremeSpod]

It's quite possible to implement a challenge / response activation system that works offline, so I wouldn't rule that out altogether. Nearly all of the online one's I've seen offer an offline fallback.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

Whatever scheme you use for the licensing, the bigger problem is writing licensing checks into the code in such a way that it doesn't degrade performance and it isn't trivially easy to circumvent or replace the license checks with a stub. If you are supplying source code then you make this method of avoidance much easier, to the point where I'd say you're more or less wasting your time unless you are going to turn your product into unreadable difficult to maintain spaghetti.

Yep. A toughy, init?

Thanks for all your suggestions though, keep 'em coming.

 

[AtW]

This thread is more appropriate in Accounting / Legal.

 

[Sysman]

EDIT: in my case, the string was in a file, not the exe. And I used the machine's IP address, not nodename, to tie it.

I prefer nodename, simply because the "network nazis" can and sometimes do impose IP changes on you. There's also the impending switch to IPv6 to think of here: stick to nodenames and you can neatly avoid any hassles that will bring.

I've used the MAC address as a hardware ID and public/private key signing of a hash of the license info i.e. the license file contains mac address, serial no, optional expiry date and a key that is just a digital signature of a hash of the other info. The key thing here is that they can see the license info but they cannot edit it without rendering the license key invalid. Of course when you can manually set the MAC address on a network adapter it doesn't work very well.

I think it's a useful exercise to look at this from the customer point of view.

As a customer I definitely do not want anything tied to a MAC address. Network cards die and I don't want to have to deal with software licensing issues on top of any other network reconfiguration I may have to do as the result of a new MAC address because a NIC was replaced. As you say, doodab, they can be faked anyway. Also what happens in your scheme if an extra NIC is added to a system? Incidentally if a VMS machine running DECnet is in the equation (yes they still exist), DECnet itself knobbles the MAC address before TCP/IP sees it (and while it's unique for a given network, it is not necessarily unique across all customers).

I have also come across licencing schemes which hide things in file headers. With one product a simple backup and restore of the system disk lost that and whoops, the software refused to start. The supplier made it easy to get a new licence key in this event, but they were abroad so we could only call them from certain phones. See the problem? What made this worse was that this product was a scheduler which kicked off jobs on a bunch of other systems. Oops. (We promptly migrated our sysadmin jobs such as backups back to using standard OS schedulers.)

My plea from the customer point of view is to make it easy for the customer to comply with licencing. Make your licencing scheme a pain in the neck to administer and folks will be tempted to look for workarounds. A simple tool to help the customer manage multiple licences might be appropriate, especially if it gives them a nice printout to give to auditors, and you can use this as a selling point too.

And please don't force me to type long sequences of gibberish into a box where pasting isn't allowed.

Maybe consider omitting ambiguous characters from licence keys too. For example, the VMS licence checksums were completely unambiguous - no struggling to distinguish between zero and "O", "1" and "l" etc.

13. Enter 1-BGON-IAMA-GNOL-AIKO for the checksum.

Note

The checksum string always begins with a number. The other 16 characters are always alphabetic characters from A through P.

 

[VectraMan]

IMO attempting any kind of licencing always costs more in support and development hassle than it would cost in lost revenue from the small number of customers that are likely to try to cheat you. But management types don't tend to see it that way. And if you're supplying code than that suggests a much higher degree of trust with the customer anyway. Paying for a source code licence for a library and then having to deal with additional licencing issues would just piss most people off.