«

I am currently looking at the various packages that are available for
software protection. I have a particular question that I'd welcome
your feedback on.

Background info:
I work for a company that develops software, and typically releases
software SDKs. Development is in C++ using MS Visual C++. We need to
apply software encryption/protection to achieve:

1) Time-limited versions (e.g software expires after X days)
2) Machine-locking (once activation key entered, software will only
run on the machine it was installed on)
3) Anti-debugging/reverse-engineering protection

We had been using PCGuard, which can cover all these aspects. However,
we have a particular problem due to the fact that our software is
released as an SDK.

3rd party developers using our SDKs access the core functions using a
supplied dll, and it is the dll which needs to be protected. We do not
want them to be able to debug the dll we supply, but we *do* want them
to be able to debug the code that they write!

The encryption/anti-debugging employed by PCGuard means that they are
not able to debug their own code, which is a major problem.

My question is: is it possible (using another package) to apply
protection which covers all 3 aspects above yet still allows 3rd-party
developers who use our SDK to debug their own code?

My feeling is that protection options 1+2 (time limited versions,
machine locking) can be achieved without blocking the debugging of
3rd-party code, but I'm not sure if protection option 3 can also be
included without blocking all debugging.

Any thoughts or info on this greatly appreciated. Comments on the
pros/cons of the various protection packages available also welcome!

(please post replies to newsgroup *not* via email)

many thanks,

Howard Wright

Howard wrote:
> I am currently looking at the various packages that are available for
> software protection. I have a particular question that I'd welcome
> your feedback on.
>
> Background info:
> I work for a company that develops software, and typically releases
> software SDKs. Development is in C++ using MS Visual C++. We need to
> apply software encryption/protection to achieve:
>
> 1) Time-limited versions (e.g software expires after X days)
> 2) Machine-locking (once activation key entered, software will only
> run on the machine it was installed on)
> 3) Anti-debugging/reverse-engineering protection


This kind of stuff sucks, and many people will refuse to use it.
Fortunately, for every time someone tries to make a method to restrict
and own and regulate everything there is someone who makes a tool to
brake it.

It's not software protection, it's software policing.

"Howard" <do_not_use_this_address_@hotmail.com> wrote in message
news: om...
> Background info:
> I work for a company that develops software, and typically releases
> software SDKs. Development is in C++ using MS Visual C++. We need to
> apply software encryption/protection to achieve:
>
> 1) Time-limited versions (e.g software expires after X days)
> 2) Machine-locking (once activation key entered, software will only
> run on the machine it was installed on)

You might want to look at how Microsoft handles this with their latest
software. They develop a "fingerprint" for the machine based on
various bits of hardware and if that fingerprint changes too quickly,
the software has to be reactivated. Different pieces of hardware
affect the fingerprint to a greater or lesser extent depending on how
likely the change is to imply a different machine rather than a simple
upgrade: motherboards count more than hard drives, for example.

What makes it less painful to the user than it might be is that you
can pretty much upgrade the whole system without triggering the
reactivation if you do it slowly enough.

If you do a google search you'll probably find a lot of details about
it, along with, I'm sure, plenty of hacks to defeat it. -Wm

do_not_use_this_address_@hotmail.com (Howard) seems to think in
news: om:

> I am currently looking at the various packages that are available for
> software protection. I have a particular question that I'd welcome
> your feedback on.
>
> Background info:
> I work for a company that develops software, and typically releases
> software SDKs. Development is in C++ using MS Visual C++. We need to
> apply software encryption/protection to achieve:
>
> 1) Time-limited versions (e.g software expires after X days)
> 2) Machine-locking (once activation key entered, software will only
> run on the machine it was installed on)
> 3) Anti-debugging/reverse-engineering protection
>
> We had been using PCGuard, which can cover all these aspects. However,
> we have a particular problem due to the fact that our software is
> released as an SDK.
>
> 3rd party developers using our SDKs access the core functions using a
> supplied dll, and it is the dll which needs to be protected. We do not
> want them to be able to debug the dll we supply, but we *do* want them
> to be able to debug the code that they write!
>
> The encryption/anti-debugging employed by PCGuard means that they are
> not able to debug their own code, which is a major problem.
>
> My question is: is it possible (using another package) to apply
> protection which covers all 3 aspects above yet still allows 3rd-party
> developers who use our SDK to debug their own code?
>
> My feeling is that protection options 1+2 (time limited versions,
> machine locking) can be achieved without blocking the debugging of
> 3rd-party code, but I'm not sure if protection option 3 can also be
> included without blocking all debugging.
>
> Any thoughts or info on this greatly appreciated. Comments on the
> pros/cons of the various protection packages available also welcome!
>
> (please post replies to newsgroup *not* via email)
>
> many thanks,
>
> Howard Wright


Look into .NET code-level access security. You can control security down
to the module level and with a little ingenuity, you can probably invent
a licensing structure with expiration date. Of course, you have to be
using the .NET model.

I think your perception may be colored by your experience with PCGuard.
There's no fundamental reason for this restriction.

We offer the EasyLicenser license manager (www.easylicenser.com):

(a) Today, for both C++ and Java: our digital signature mechanism will
prevent tampering and spoofing but won't prevent read-only reverse
engineering. Will work in SDK deployment environments.

(b) Coming up, for Java only: jar encryption will prevent reverse
engineering as well. Will allow applications using the encrypted jars to be
debuggable.

Also, on anti-debugging of C/C++ DLL's: usually, this is achieved by doing a
"production" build which strips the binary of debug symbols. That is,
usually, reverse-engineering of C/C++ binary isn't a concern.

Best of success with your product.


Regards,



Dominic Haigh

Agilis Software

"Howard" <do_not_use_this_address_@hotmail.com> wrote in message
news: om...
> I am currently looking at the various packages that are available for
> software protection. I have a particular question that I'd welcome
> your feedback on.
>
> Background info:
> I work for a company that develops software, and typically releases
> software SDKs. Development is in C++ using MS Visual C++. We need to
> apply software encryption/protection to achieve:
>
> 1) Time-limited versions (e.g software expires after X days)
> 2) Machine-locking (once activation key entered, software will only
> run on the machine it was installed on)
> 3) Anti-debugging/reverse-engineering protection
>
> We had been using PCGuard, which can cover all these aspects. However,
> we have a particular problem due to the fact that our software is
> released as an SDK.
>
> 3rd party developers using our SDKs access the core functions using a
> supplied dll, and it is the dll which needs to be protected. We do not
> want them to be able to debug the dll we supply, but we *do* want them
> to be able to debug the code that they write!
>
> The encryption/anti-debugging employed by PCGuard means that they are
> not able to debug their own code, which is a major problem.
>
> My question is: is it possible (using another package) to apply
> protection which covers all 3 aspects above yet still allows 3rd-party
> developers who use our SDK to debug their own code?
>
> My feeling is that protection options 1+2 (time limited versions,
> machine locking) can be achieved without blocking the debugging of
> 3rd-party code, but I'm not sure if protection option 3 can also be
> included without blocking all debugging.
>
> Any thoughts or info on this greatly appreciated. Comments on the
> pros/cons of the various protection packages available also welcome!
>
> (please post replies to newsgroup *not* via email)
>
> many thanks,
>
> Howard Wright
>