software protection and licensing question

[Howard]

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

 

[Arthur J. O'Dwyer]

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.

Your question has nothing to do with the C++ language, and is
off-topic in comp.lang.c++.

We need to apply software encryption/protection to achieve:

1) Time-limited versions (e.g software expires after X days)

Trivially circumvented by a user who controls the system clock
(as most Microsoft OS users do).

2) Machine-locking (once activation key entered, software will only
run on the machine it was installed on)

Trivially circumvented by a user who controls his hardware
(which unfortunately very few users do, IME, especially in the
desktop mass-market).

3) Anti-debugging/reverse-engineering protection

Trivially circumvented by a user who has read access to the code
in question (e.g., most users on Microsoft OSes, and admins or
the moral equivalent thereof on OSes that support that kind of thing).

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!

God forbid anyone should try to debug *your* DLL! Debugging is
the work of the devil and should be prevented at all costs.

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

Yes, I can see that. But are you sure that the programmers'
inability to debug their own code stems from their use of PCGuard,
or is it a more deeply-rooted problem, perhaps due to lack of
education or practice? I know a few people who can't debug their
own code, and they don't even *use* PCGuard.

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?

A good license agreement would help. For example, you could
insert a clause that said essentially, "Thou shalt not attempt to
reverse-engineer the contents of this DLL, unless given permission
by the creators thereof." That would keep all law-abiding intruders
out. Then you could even compress or encrypt the code, thus keeping
out the less-persistent debuggers.
That should be enough -- you're never going to stop the persistent,
intelligent debuggers who don't care about laws, anyway. The CPU
knows what the code does, and the programmer can talk to the CPU.
That just about sums it up, doesn't it?

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.

I think it would be a nice gesture if you allowed the programmer
to find bugs in your code, as well as in his own. Certainly it
would make your life a hell of a lot simpler.

-Arthur

 

[Gerry Quinn]

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

I would recommend you take a look at Armadillo from
www.siliconrealms.com . I know it has some restrictions relating to
debugging and DLLs, but I suspect it can be configured suitably. You
can download a trial version and check it out.

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.

If all else fails, an alternative option you might consider is to issue
two separate DLLs, with the same general functionality. One would be
the distributable DLL, protected but not debuggable. The other would be
debuggable, but would have undesirable behaviours that prevent it being
used in a distributed program. Of course, care would have to be taken
to make this hard to crack.

- Gerry Quinn

 

[Randy Howard]

If all else fails, an alternative option you might consider is to issue
two separate DLLs, with the same general functionality. One would be
the distributable DLL, protected but not debuggable. The other would be
debuggable, but would have undesirable behaviours that prevent it being
used in a distributed program. Of course, care would have to be taken
to make this hard to crack.

Why would you want to debug code that is NOT what your customer will be
using? You're assuming that the changes in behavior (unspecified) will
not impact bugs, races, or add new bugs or mask off those in the
production DLL.

 

[Gerry Quinn]

Why would you want to debug code that is NOT what your customer will be
using? You're assuming that the changes in behavior (unspecified) will
not impact bugs, races, or add new bugs or mask off those in the
production DLL.

The point was that his current protection system correctly prevented
customer 'debugging' his proprietary DLL, but also prevented them
debugging their own stuff.

I was suggesting that customers wanting to debug their own code could be
substitute an alternative DLL which would (for example) pop up messages,
or quit after an hour's running.

I suspect another protection system will allow a better solution,
though.

- Gerry Quinn

 

[Bill Unruh]

(e-mail address removed) (Gerry Quinn) writes:

]>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)

Impossible. The software has no way of knowing what the time is.

]>2) Machine-locking (once activation key entered, software will only
]>run on the machine it was installed on)

Possible but extremely inconvenient to your users.

]>3) Anti-debugging/reverse-engineering protection

Impossible. ( Well, write it in Forth, and you will have pretty good
protection).

]>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 machine MUST load the dll into memory to use it. At that point the
code can be captured and analysed.

 

[Gerry Quinn]

(e-mail address removed) (Gerry Quinn) writes:
]>
]>1) Time-limited versions (e.g software expires after X days)

Impossible. The software has no way of knowing what the time is.

That's what they said about black holes, and yet they seem to be able to
evaporate on schedule ;-)

Software can read the computer clock, and store data in sufficiently
obscure ways that user tampering between runs will be difficult to hide
from it.

]>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 machine MUST load the dll into memory to use it. At that point the
code can be captured and analysed.

That is easier said than done. For example, the protection system may
include a separate process that decrypts portions of the dll on demand,
and will also attempt to detect debugging attempts and shut down if any
occur.

- Gerry Quinn

 

[Howard]

Thanks for the info. Armadillo is one of the packages I have come
across while searching the web, and I will definitely be checking it
out.

The other posts/comments etc have been interesting reading, but as my
original post said, I'm mainly interested whether it's possible to
allow debugging for the application code written by users of our SDK,
whilst still preventing them from seeing/debugging our own code.

There are clearly different philosophies on the pros and cons of
giving people access to your source code, but this choice has already
taken by our company.

I'm also well aware that code protection can never be perfect - people
will always be able to find a way to break into your code. However, we
want to put in some measures that will at least mean it takes a
reasonable amount of time and effort to do this. This should prevent
all but the most determined hackers.

I like the locks/keys analogy. I know that I cannot prevent someone
from breaking into my house and stealing my possessions, and I know
that locks can be broken, but I still put locks on the doors and
windows to stop the less determined thieves!

Howard

 

[Karkucus]

Looking toward CompTIA Security+ Certification , Here is greate Link
for Excellent Security+ Certification Guide,

http://www.studyexam4less.com/mb.asp

Also here is another Money saving idea for Security+ Testing exam fee. buy voucher
and Scheduale the exam using Security+ voucher for Only US $165.00 saving of
US $ 60
http://www.getcertify4less.com/mb.asp

 

[Karkucus]

Looking toward CompTIA Security+ Certification , Here is greate Link
for Excellent Security+ Certification Guide,

http://www.studyexam4less.com/mb.asp

Also here is another Money saving idea for Security+ Testing exam fee. buy voucher
and Scheduale the exam using Security+ voucher for Only US $165.00 saving of
US $ 60
http://www.getcertify4less.com/mb.asp






(e-mail address removed) (Howard) wrote in message