Securing Software with License

[P1ayboy]

I need advice on how to best to protect software with licenses.

We are developing a windows application that people can purchase and
download off the net, but the software needs to be protected by licensing.

The software is being written in vb.net v1.1.

If anyone knows any beeter places to post this message, please let me know.

Many thanks

Rob

[Frans Bouma [C# MVP]]

P1ayboy wrote:

I need advice on how to best to protect software with licenses.

We are developing a windows application that people can purchase and
download off the net, but the software needs to be protected by
licensing.

The software is being written in vb.net v1.1.

If anyone knows any beeter places to post this message, please let me
know.

I'd go for signed xml files. You can create them at your own server
and add any info you want, like the name of the customer. Signed xml is
easily read with .NET code and checked (it's build in).

Another approach is a key-code but that's less personal to the
customer and you run the risk of having your serial codes end up on
some crack site.

You can also purchase a commercial licensing library, like Xheo
licensing. These typically implement a few different ways of doing
licensing, like signed xml files or serial numbers.

Either way, you have to protect your own code from disassembling and
removal of the protection code. So obfuscate the code, sign your
assemblies, check at random places that the public token on the
assemblies is still yours and if not set a random variable to null so
the app crashes somewhere else.

That said, also read:
http://software.ericsink.com/bos/Transparency.html

about how far you should go in protecting your own software, as the
more you do to protect your software, the more you likely will annoy
your (potential) customers. :)

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[john smith]

Frans Bouma [C# MVP] wrote:

I'd go for signed xml files. You can create them at your own server
and add any info you want, like the name of the customer. Signed xml is
easily read with .NET code and checked (it's build in).
That by itself is hardly what I'd call protection. Even if it's
obfuscated, it's still far too easy to find the
SignedXml::CheckSignature call(s) in the IL and NOP the following
brfalse (or even NOP the entire check altogether, licenses wouldn't even
need to be signed anymore vs no need for a valid signature). It would
probably take all of 5 minutes to crack that app... If your app is known
at all or useful, it'll be on crack sites within minutes. I would call
this more like an annoyance to crackers more than protection really.
Another approach is a key-code but that's less personal to the
customer and you run the risk of having your serial codes end up on
some crack site.

Indeed. That alone is enough either, and that is bound to happen too
(possibly keygens or hand-made "unlimited" licenses too)
You can also purchase a commercial licensing library, like Xheo
licensing. These typically implement a few different ways of doing
licensing, like signed xml files or serial numbers.
Some of those suck, some are great... One has to pick the right one (and
preferably at the right price too). I haven't looked at those
extensively, can't really make recommendations. Chances are you'll find
universal "unlockers" for apps protected with specific protections.

Either way, you have to protect your own code from disassembling and
removal of the protection code. So obfuscate the code, sign your
assemblies, check at random places that the public token on the
assemblies is still yours and if not set a random variable to null so
the app crashes somewhere else.
Obfuscation is obviously a must, but it's not enough in itself (it can
only obfuscate so much; the thing still has to run; and not all
obfuscators are created equal obviously).

Signatures can be removed too (same for checks), it's not that hard...
Useful as an "extra step" to make cracker's lives miserable, but far
from enough either. Encryption can't hurt either (but key management can
be a pain, DPAPI is always an option).

But the "hidden checks" option is a VERY good one indeed (whether it
checks dates/timestamps or such, parts of the serial that isn't normally
checked (more "in depth" checks on parts of the serial), anything goes).
Hide them as well as you can, in places no one would look: called at the
middle of some functions your program does or on some special events,
perhaps only start to use some of the checks X days after install so the
crackers think it works, release it, the crack-addicts download and
install it, only to find out in a couple days it's not working right,
etc. You can also make some of these hidden checks run only sometimes
(5% chance or such), which again will make it harder to find them, but
will cripple the badly-cracked programs. Make the checks work off
non-obvious indirect copies of the licensing data or such kept in RAM
(hard to keep track of a couple dozen memory locations with variants of
the registration info and such) The more hidden checks, and the better
they're hidden the better. Those are the most likely parts to be
missed/troublesome/time-wasting/frustrating to crackers, and the people
using your soft illegally will tire of it, and hopefully see a value in
purchasing your useful program. Make them tired of buggy cracks, and
they may want a stable version enough to pay for it... You can offer
some "perks" to paying members too to make it even more attractive
(newer builds and bugfixes sooner, member advantages like forums or
extra downloads, access to betas of the next versions, dicsounted
upgrades, whatever you want). Of course this is by far the most
complicated and time consuming option to protect your programs, but it's
perhaps one of the most "secure" things you can do (almost impossible to
find all hidden checks) and that annoys those using illegal versions the
most.

That said, also read:
http://software.ericsink.com/bos/Transparency.html

about how far you should go in protecting your own software, as the
more you do to protect your software, the more you likely will annoy
your (potential) customers. :)

FB

The tougher the better, but eventually it can become rather complex and
time consuming (one would rather spend their time add new neat features
to their apps to make people want to purchase it instead and such). And
it's sad to see a protection that you've spent so much time onto be
broken when it happens... The never ending battle :)

[grant]

I agree with pretty much everything John said above. There are really
two aspects to consider. The first is generating customer unique
license keys that can't be reverse engineered by inspecting your code.
For this you really need a system that uses some form of public key
encryption. Our company, Infralution, offers a low cost licensing
solution that does this (www.infralution.com/licensing.html).

The second aspect is preventing crackers simply bypassing your license
checks by nulling out statements or simply recompiling your whole
application. Unfortunately there is bullet proof way to do this. If
you visit some of the crack sites you will see that just about all of
the protection/obfuscation products have themselves been cracked - so
your best insurance is the sort of approach that John recommended where
at least the cracker will have to put some effort in understanding your
particular code.

There is also really good article on Code Project
(http://www.codeproject.com/gen/desig...tialWisdom.asp) about
the balance between protecting your code and making life difficult for
your legitimate customers.

Grant Frisken
Infralution
www.infralution.com

[Frans Bouma [C# MVP]]

john smith wrote:

Frans Bouma [C# MVP] wrote:

I'd go for signed xml files. You can create them at your own server
and add any info you want, like the name of the customer. Signed
xml is easily read with .NET code and checked (it's build in).
That by itself is hardly what I'd call protection. Even if it's
obfuscated, it's still far too easy to find the
SignedXml::CheckSignature call(s) in the IL and NOP the following
brfalse (or even NOP the entire check altogether, licenses wouldn't
even need to be signed anymore vs no need for a valid signature). It
would probably take all of 5 minutes to crack that app... If your app
is known at all or useful, it'll be on crack sites within minutes. I
would call this more like an annoyance to crackers more than
protection really.

No it's not :)
I agree the license check is found in 5 minutes, though that's not the
point. The point is that to remove it, you have to remove the signature
as well, as the code is signed.

To do that is a little harder. Ildasm -> file, remove signature ->
ilasm
And if the app consists of multiple assemblies, you have to do that
with all assemblies.

And now comes the fun part, by removing the signature, you have to
remove the public token of the original signer. And _THAT_ can be
checked in 1 line of code with obscure byte checking code you
definitely won't find easily, even in non-obfuscated code.

Because that check is so simple yet very effective, you can add it to
a lot of routines. There a failed check simply sets a reference to null
or clears some collection or whatever. A crash will follow later on.
It's a tactic used by many applications and works very well, because
it's very hard to track down where the test actually was, because it
doesn't display a popup with "LICENSE VIOLATED", but sets up a bomb
which goes off later.

Furthermore, you can't win from professional crackers who spend days
if not weeks to find the protection. You simply cant. So that's a
given. What it does however is protecting you from the large group of
wannabe crackers in a random office, you know the guy in the corner who
likes to give it a try over lunch. It gets a drag and they lose
interest if it takes them hours to find all the public token checks, if
they even find one.

The signed license file with a name of the customer has another
purpose: it stops your customer for spreading their license file to
others, because their name is in the file. A serial number is
anonymous, the signed license file isn't. So if that ends up on a
cracksite, the vendor knows immediately who spread the license.

You can also purchase a commercial licensing library, like Xheo
licensing. These typically implement a few different ways of doing
licensing, like signed xml files or serial numbers.

Some of those suck, some are great... One has to pick the right one
(and preferably at the right price too). I haven't looked at those
extensively, can't really make recommendations. Chances are you'll
find universal "unlockers" for apps protected with specific
protections.

The older xheo licenser wasn't that good as it was easy to find the
trial installation date holder (the object (file/regkey whatever) which
holds the installation date to check how long a trial is running). Now
they're pretty good, as in: it will take the random office 'I'll give
it a try'-cracker too much time to break it. (IMHO)

Either way, you have to protect your own code from disassembling
and removal of the protection code. So obfuscate the code, sign your
assemblies, check at random places that the public token on the
assemblies is still yours and if not set a random variable to null
so the app crashes somewhere else.

Obfuscation is obviously a must, but it's not enough in itself (it
can only obfuscate so much; the thing still has to run; and not all
obfuscators are created equal obviously).

- make all types, properties and methods in the .exe at least internal
and if possible private.
- don't use popups in the check routine but create a long trail of
calls/routines which in the end lead to the result if the license is
valid or not.

Especially the first step is essential. Because of that, a LOT is
obfuscated, much more than you'd get with public
types/methods/properties.
Signatures can be removed too (same for checks), it's not that
hard... Useful as an "extra step" to make cracker's lives miserable,
but far from enough either. Encryption can't hurt either (but key
management can be a pain, DPAPI is always an option).
But the "hidden checks" option is a VERY good one indeed (whether it
checks dates/timestamps or such, parts of the serial that isn't
normally checked (more "in depth" checks on parts of the serial),
anything goes). Hide them as well as you can, in places no one would
look: called at the middle of some functions your program does or on
some special events, perhaps only start to use some of the checks X
days after install so the crackers think it works, release it, the
crack-addicts download and install it, only to find out in a couple
days it's not working right, etc. You can also make some of these
hidden checks run only sometimes (5% chance or such), which again
will make it harder to find them, but will cripple the badly-cracked
programs. Make the checks work off non-obvious indirect copies of the
licensing data or such kept in RAM (hard to keep track of a couple
dozen memory locations with variants of the registration info and
such) The more hidden checks, and the better they're hidden the
better. Those are the most likely parts to be
missed/troublesome/time-wasting/frustrating to crackers, and the
people using your soft illegally will tire of it, and hopefully see a
value in purchasing your useful program. Make them tired of buggy
cracks, and they may want a stable version enough to pay for it...
You can offer some "perks" to paying members too to make it even more
attractive (newer builds and bugfixes sooner, member advantages like
forums or extra downloads, access to betas of the next versions,
dicsounted upgrades, whatever you want). Of course this is by far the
most complicated and time consuming option to protect your programs,
but it's perhaps one of the most "secure" things you can do (almost
impossible to find all hidden checks) and that annoys those using
illegal versions the most.

It's time consuming indeed, but well worth it. I once read on the blog
of the author of Feeddeamon rss reader that he got complaints from
people that the software crashed in several parts, though that was on
purpose, because they used a cracked copy :).

Though as I said in my previous post: keep in mind for whom you're
protecting your software. Don't try to outsmart the professionals,
these have too much time on their hands. Try to outsmart the random
office hacker. That won't take too much time, and in general you'll be
fine.

In general, if your protection is quite good, you'll see another
phenomenon: people using illegally obtained creditcard numbers to
purchase your software, with that get a license and be done with it. No
protection helps you avoid those attempts, except one:
sell a temp license to the customer, which is then used after 60 days
to obtain a real license on the website. In that period, the legal
owner of the creditcards often spotted odd payments and blocked the
card and you can then block the license.

Though this is an annoyance to users, and it's therefore perhaps not
worth the effort, but it's an idea to keep in mind. :)

That said, also read:
http://software.ericsink.com/bos/Transparency.html

about how far you should go in protecting your own software, as the
more you do to protect your software, the more you likely will annoy
your (potential) customers. :)

FB

The tougher the better, but eventually it can become rather complex
and time consuming (one would rather spend their time add new neat
features to their apps to make people want to purchase it instead and
such). And it's sad to see a protection that you've spent so much
time onto be broken when it happens... The never ending battle :)

yeah :). I still remember the feeling I had when someone broke my
'unbreakable' protection in 5 minutes back in 2003. I was shocked. It
turned out I made a dozen mistakes in a row and luckily the guy was
quite friendly and helped me with a lot of hints to look into. One was
for example to make the main form sealed and internal, as you can
rename a .exe to .dll and reference it from another .exe assembly and
instantiate code from there. THe sealed part was necessary so you
couldn't create a subclass and do license voodoo with reflection.

Often it can be pretty simple to avoid these kind of mistakes, so it's
not that hard to close those holes. Though to protect you from every
cracker is simply too time consuming, and IMHO not worth the effort:
they will crack it anyway, IF they're interested. I mean, if you can
crack the modern cdrom protection schemes, you aren't a small guy as
these protection schemes are very tough (even in the old days when I
did 68000 assembler coding on an amiga and knew the disk IO hardware
inside/out I sometimes couldn't follow the schemes some people were
able to cook up to protect their code, but there was always a guy who
was able to crack it): illegal instructions, selfmodifying code etc.
etc.

FB

--
------------------------------------------------------------------------
Get LLBLGen Pro, productive O/R mapping for .NET: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------