问题
I have an encryption/copy protection question.
I'm writing an application for a company that uses a dongle. Please don't tell me that software protection is useless, or that I should just let it fly free into the air, or that any time I spend doing this is a waste; this isn't a philosophical question about the validity of software protection, more like a how-to.
As I understand it, the first step in cracking a dongle-protected piece of software is to remove all the calls to the dongle from the code (ie, patch the executable). Also as I understand it, I can create 'strong names' in .NET in order to protect the application and the assembly, as explained in this MSDN article.
Is strong naming enough to ensure that my application can't be easily patched? Or do I need to use some sort of encryption library? If I need to use a library, which one, or where can I get information about setting this up?
The next step, of course, is to put important algorithms on the dongle. I realize that these are just speed bumps to the dedicated cracker, but as our market share grows, the speed bump will help us get to the point where the sting of piracy is not so keenly felt (I hope).
Thanks!
回答1:
Assembly strong naming was never designed to protect against an attacker who is in control of the machine. From the msdn entry on delay signing:
The following example turns off verification for an assembly called myAssembly.dll.
sn –Vr myAssembly.dll
The design goal of strong names is to provide name uniqueness and to protect the user (not the publisher) against an attacker. If the user wants to disable all strong name checks, or maybe even strip out your signature and re-sign the assembly with his own key then there is technically speaking nothing to prevent him from doing so.
Simply loading your assemblies from an encrypted file is also not very useful because the decryption code itself cannot be encrypted and is therefore an easy target for reverse engineering.
As mentioned by other posters, what you are looking for is obfuscation. You probably already have such a tool: Visual Studio (at least 2005 and 2008) comes with the community edition of PreEmptive Solutions’ Dotfuscator. Microsoft also has its own "Software Licensing and Protection Services" product.
Obfuscation has some technical disadvantages however:
- it may complicate your build process. You need an unobfuscated and an obfuscated build, because the latter is not debuggable.
- I like to have an error dialog for unexpected exceptions where the user can click "copy details" and send me a mail with some technical information including the stack trace. With obfuscation however, you can forget about getting anything useful from Exception.StackTrace.
- if your code makes use of reflection then there is a good chance that things will break in the obfuscated build, because internal type and member names are not preserved.
回答2:
Signing your assembly will make it impossible to alter it without altering the signature, and hence its reference. The consequence of this is that a (strong named) reference to the assembly will fail to resolve against the altered version. And that's guaranteed against ridiculous odds.
That doesn't solve your problem, though. Not completely, anyway. If you pack your dongle calls, say, into a strongly named assembly, then reference that assembly from your application, the application will not work without your unaltered assembly, and hence not without the dongle. But the application itself can be altered!
Another means available to you is obfuscation. There's a free version of an obfuscator shipped with Visual Studio, which can be upgraded to industrial strength. Obfuscation renders code incomprehensible without altering it's behaviour, and hence presents a real barrier to reverse engineering.
I'd say the solution lies in some clever combination of these two techniques.
And that's the extent of my knowledge, I'm afraid. Someone else will have to provide the actual answer here (and it's probably embarassingly much shorter than mine ;-)
回答3:
If they are patching your executable a strong name does not help. It will however help you ensure that a dll you reference is the correct version and has not been tampered with.
you might check
Salamander orpreemptive for obfuscation.
Encryption you might look at Assembly Lockbox, CodeVeil,
or ThinApp
回答4:
If you want to use a dongle and encrypt your program, this article may be useful to you: http://www.gironsec.com/blog/2012/02/dongles-how-do-they-work/
Here is a pertinent quote from that article:
There are 2 ways to implement a dongle. The right way and the wrong way. The right way would be to encrypt your programs and store the encryption key on the dongle and decrypt at run time depending on whether the device is connected or not.
回答5:
To some extent, Obfuscation may be useful for you. But it is not a 100% secure way. IN fact, there is not any 100% secure way to protect any software module. At its best, obfuscation merely makes it time-consuming to reverse-engineer a program. .NET Reflector is a reverse engineering tool which regenerates the source code from any .NET assemblies. Using Dotfuscator will make it difficult for the intruder to understand the original source code but one can effort to have a good estimation of that source code if the reward is big.
来源：https://stackoverflow.com/questions/494211/encrypting-a-net-application-and-assemblies