Happy new year, etc. USENET has roped me back into my favorite discussion: How shareware authors are doomed, DOOMED! More seriously, there is no perfect solution for protecting shareware written in interpreted languages, and it appears it's worth talking about again. So with the magic of cut & paste, here's what I had to say! Yay!

Peter Olcott wrote:
> "Nick Hebb"  wrote in message
> news:1136626317.968074.44360@z14g2000cwz.googlegroups.com...
> > Another option is to use a traditional license protection tool (e.g.
> > Armadillo). Put some critical bits of functionality in a COM DLL called
> > through interop. The COM DLL can then be wrapped with the protection
> > tool.
> >
>
> This is the only one that I could find that works with .NET. It also seems to
> work with everythig else.
>
> http://www.ionworx.com/SerialShield.html
>
> This product seems to have all the features of an excellent copy protection /
> trialware maker. It has one feature that I was not even aware was possible. It
> apparently can prevent itself from being reverse engineered through
> anti-debugging.
...


There seem to be a number of issues here. For the first quoted post, if you put your license check in a DLL, it'll be hard to decompile that, but still just as easy to decompile the portion of your .NET program that accesses it. ย At some point, .NET code is still going to be your weak link, and your "protection" is still toast.

For the second, I went to the site for the SerialShield to see what "antidebugging" is. Here's a quote:

"The main purpose of SerialShield is to make the crackers job more difficult should they attempt to crack your program(s). "

I believe the key phrase is "more difficult". As best I can tell, this feature is code obfuscation. This is a good thing to use, and strips out much of the info that would make decompiled code easier to understand, but still isn't much protection from ultimately being cracked.

Perhaps I've missed something, however. Anybody know exactly what this feature is trying to do if it's not obfuscation? ย The rest of the features seem interesting, but I wonder how you'd implement without adding a check for the, eg, Machine ID, somewhere in .NET and then *poof*, .NET is your weakest link again.

I released a shareware app in Java some years back, which is also an interpreted language, and started having some of the same questions. There's a relatively interesting (well, to me anyhow) and detailed thread on the same subject from the point of view of Java developers here:
[click me]

I asked pretty much the same questions, and the answers were every bit as disheartening as I'd suspected.

The key to remember is that you need to go in thinking not, "How do I remove any possibility to crack my program?" but "How do I maximize my returns by making my app more difficult to crack?" ย I wax prolific on this one too, I'm afraid. This URL:
[click here]

Good luck,

mfn