john said:
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.
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)
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.
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
--
