IntelliLock + Activation Code

[Denis]

From time to time I get a feature request regarding software
activation via activation codes / serial numbers. I would like to know
your thoughts on this. :)

Some background information... In contrast to license files, serial
numbers are supposed to be relative short. This means symmetric
encryption must be used in this case as secure asymmetric encryption
requires a large signature.

-License File = Asymmetric Encryption = Keygen Bulletproof
-Serial Number = Short String = Symmetric Encryption = Decryption key
must be included in protected assembly

Thank you.

Denis

[Glen Harvy]

1. Will a serial number/code weaken the the piracy protection provided by .Net Reactor? In this regard I guess a key file is distributed almost as feely as a serial number.

2. Presumably it will take less time to 'break' a shorter code but I have no real idea what I'm talking about - that's, after all, why I bought your product :-)

3. I embed a value in the key file enabling me to match the end user's business name with the original purchaser's business name so I presume that I would not have this ability with a code only system. I figure that if the end user is content to see the original purchaser's business name in all their reports etc then there's not much I can do about that unless I go as far as HID.

I expect this really boils down to an ease of use decision. If I am right then as far as you are concerned then it boils down to whether you  are losing business - not us. I've never been asked for a refund because they can't unlock their software :-D

The only 'problem' I have ever had with a key is some purchasers don't understand how to save the thing to a directory. I have not yet written the app to do it for them because if they can't do that then they probably won't allow downloads of .exe files let alone know what a zip file is. My previous attempt at self-extracting zip files created trojan alerts.

OK.... Now having said all the above I would love to be able to have BOTH a key and a code. In fact, I will shortly be forced to devise some sort of code system because an end user will eventually have to enter their code to login to our website and download their software updates etc. I haven't given this a lot of thought yet because I guess it would be very easy to do myself. {Thinking aloud: dream up suitable key, embed in keyfile, user enters code in my program, compare code/key at startup - yes that would work}

Summary:
I don't see it as high on the to-do list but you probably are losing some business because you don't give this as an option.

Warm regards,

Glen Harvy,

[raven]

My opinion is you should focus on protection and not soften it by
reintroducing weak shemes of the past (serial numbers) as long as they
can't be as secure as public key encryption (and as you said: they
will never be). It should not be that hard to write a webservice that
joins both worlds, essentially handing a short serial number to your
customers which enables the software to download a valid key file from
your server.

Maybe you want to include some code examples or a genereal howto that
explains custom activation via webservices. In the end I think that
would be more beneficial to your customers as it does not weaken
overall protection.

raven

[Pauldy1000]

Hi.

My view is that the license files are still the way to go. I read on
this forum an excellent tip for protection which was to embed a
constant or some information vital to the actual execution of your
application in the file, so if the file and information were missing
the application would fail in a graceful fashion. This protected us
against a cracker somehow (although I don't know how) bypassing the
license-check-mechanism and simply returning "Licensed". I have
implemented that suggestion and think it is really clever - credit to
the original author of this point within this forum (sorry can't
remember who).

I could write a web service which checked a simple serial number sent
in by the application and downloaded appropriate license/values based
upon a serial and only allow the serial to be used twice or thrice,
but, that means every license could be used several times and in my
opinion the serial would absolutely be shared publicly. I could also
make the activation only work once and then have to deal with an
increased number of "my machine died and I need a new license" emails,
which I am less than keen on.

I really do like the license file concept such that I can embed
information into it. I make a lot of use of this as incremental
information in the license such that when the user purchases another
10 thingies they get a new license with all the original thingies in
it plus the ones they just bought.

I would prefer to stay with the license file vs. serial number.

Cheers,

Pauldy1000

[raven]

Pauldy1000 you reminded me of something and I hope you don't mind me
Denis, posting it here as this thread is somehow about suggestions.

It would be _so nice_ if you could implement code protected areas
in .Net Reactor.

What I mean by this is that I can mark passages of code to be
encrypted when I protect the app with .Net Reactor, which can only be
decrypted again when a valid license file is present.
This way it is impossible for a cracker to just make the license check
pass.
He _has_ to get hold of a valid licensed version, extract the
formerly encrypted code portions and re-insert them in the cracked
version which makes things much more complicated.
I think WinLicense or SoftwarePassport offer a similar feature and
perform very well in the unmanaged code world.
I know that the whole code is encrypted by .Net Reactor however, you
have to store the decryption key in the executable itself to allow
code execution. The difference with these code sections would be that
they are encrypted _with_ the license key and effectively unusable for
a cracker.

The suggestion of Pauldy1000 is also great but has to rely on
constants. To be able to protect actual code would take this type of
protection to a whole new level :)

raven

[James Deane]

I think that including serial authentication is definitly a plus. Personally i would use it combined with a license, just makes it an extra thing that a cracker would have to bypass.

[Denis]

Thanks for all your comments! :)

Actually you can't store additional data in a short license number
with fixed length. In best case you can only store the hash of the
user name and the hardware ID. But in case the user want to activate
the software over phone it would be probably the easiest solution. At
least a phone activation system must always include the whole
encryption key, it doesn't matter which licensing scheme you use in
this case.

Embedding an extra serial number in a license file makes only sense if
you want to identify customers on the server etc. but it would not
really improve the protection.

>>I read on this forum an excellent tip for protection which was to embed a constant or some information vital to the actual execution of your application in the file, so if the file and information were missing the application would fail in a graceful fashion.<<

I agree in this point. In case of IntelliLock / .NET Reactor it can't
be easily implemented as the functionality of the protected assembly
must be completely preserved, except the corresponding license
restrictions. Storing product specific vital information in the
license file is very useful in case the full version provides more
functionality.

>>What I mean by this is that I can mark passages of code to be encrypted when I protect the app with .Net Reactor, which can only be
decrypted again when a valid license file is present.

I could do this but only for whole methods. In case no valid license
is available you should not try to call them. :)

Greetings,
Denis

[raven]

Hi Denis,

> I could do this but only for whole methods. In case no valid license
> is available you should not try to call them. :)

that would be realy, realy great. It's a common case that the full
version has some functionality that the trial has not and embedding
this functionality into their own methods is realy not a problem (if
that's not the case already). So please go for it!

As for the serial system if you are going to implement it please do it
in a way that we can decide if we want to use it (what would mean that
the private key has to be included in the assembly) or not. And if we
decide to not use it then do not include the private key by any means.
I now that I don't have to tell you this but I feel better now ;)

raven