小型供应商的软件保护 [英] Software protection for small vendors
问题描述
这是我们所有人都必须在某个时候考虑的问题.
经过多年和许多方法后，我总体上倾向于同意以下声明:对于几百人使用的任何受保护的软件，你都可以找到一个破解版.到目前为止，每个保护方案都可以被篡改."您的雇主是否强制使用反盗版软件?
此外，每次我发帖讨论这个主题时，都会有人提醒我；首先，无论你采用什么样的保护措施，一个真正敬业的破解者最终都会通过所有的保护屏障."什么是最物有所值的c# 单个开发者的代码保护
因此，尽管有这两个广泛的真实免责声明，让我们谈谈保护"！
我仍然认为，对于不太可能吸引熟练破解者的时间和注意力的较小应用程序，保护是值得的.
很明显，无论你做什么，如果破解者可以通过修补应用程序来切换 IF 语句 (jmp) 的结果，那么世界上所有的密码和加密狗都无济于事.
所以我的方法是使用以下产品通过虚拟化来混淆代码:http://www.oreans.com/codevirtualizer.php我对这个产品非常满意.据我所知，它从未被击败过.我什至可以用 PEcompact 压缩可执行文件有其他人有这方面的经验吗?
只有 EXEcryptor 有问题http://www.strongbit.com/news.asp甚至网站使用起来也很头疼.执行任何 WMI 调用时，编译的应用程序都会崩溃.
这种方法允许您用混淆包围更小的代码段，从而保护安全检查等.
我使用在线授权方式，因为应用程序需要定期从服务器获取数据，因此用户长时间离线使用它是没有意义的.根据定义，该应用程序在那个时候毫无价值，即使它被破解了.
所以一个简单的加密握手就足够了.我只是偶尔在混淆保护中检查它.如果用户将应用安装在不同的机器上，则启动时会上传新 ID，服务器会禁用旧 ID 并返回新授权.
我还使用已编译应用程序的哈希值并在启动时检查它以查看是否有任何更改，然后从应用程序内将应用程序作为文件(带有读取锁定)打开，以防止任何人在启动后更改它.
由于所有静态字符串在 .exe 文件中都清晰可见，因此我尝试使用错误消息等进行通用.您不会在任何地方找到字符串授权失败".
为了防止内存转储，我使用了一种简单的文本混淆技术(例如 XOR 每个字符)，这使得内存中的纯文本数据更难与变量等区分开来.
当然，任何真正敏感的数据都有 AES.我喜欢文本的计数器模式，因为这不会导致重复序列显示底层数据，如一系列空格.
但是使用所有这些技术，如果可以从内存中转储 Key 或 Initialization 向量，或者绕过 IF 语句，那么一切都将被浪费.
我倾向于使用 switch 语句而不是条件语句.然后我创建了第二个函数，它基本上是一个死胡同，而不是实际执行所需任务的函数.
另一个想法是编写带有变量的指针.该变量是授权的结果(通常为零).这将不可避免地在某个时候导致 GPF.我只在一些较低级别的授权失败后才将此作为最后的手段，否则真实用户可能会遇到它.那么你的软件的声誉就会降低.
你使用什么技术?
(这不是一个讨论实施某事的优点的线程.它是为那些决定做某事的人设计的)
我不同意 xsl.
我们保护我们的代码，不是因为我们想保护我们的收入 - 我们接受那些在没有许可证的情况下使用的人可能永远不会为此付费.
相反，我们这样做是为了保护我们的客户对我们软件的投资.我们相信，使用我们的软件使他们在市场上更具竞争力，如果其他公司无需付费就可以使用该软件，他们将获得不公平的优势 - 即，他们在无需支付许可费用的情况下变得具有竞争力.
我们非常谨慎地确保保护 - 这是自家种植的 - 对有效用户尽可能不引人注目，为此，我们绝不会考虑购买"可能会影响这一点的现成解决方案.
This is a problem we all have to consider at some point.
After many years and many approaches I tend to agree in general with the staterment: "For any protected software used by more than a few hundred people, you can find a cracked version. So far, every protection scheme can be tampered with." Does your employer enforce the use of anti-piracy software?
Further, every time I post about this subject, some one will remind me; "First of all, no matter what kind of protection you'll employ,a truly dedicated cracker will, eventually, get through all of the protective barriers." What's the best value for money c# code protection for a single developer
So not withstanding these two broadly true disclaimers, lets talk about "protection"!
I still feel that for smaller apps that are unlikely to warrent the time and attention of a skilled cracker, protection IS a worthwhile exercise.
It seems obvious that no matter what you do, if the cracker can switch the outcome of an IF statement (jmp) by patching the application, then all the passwords and dongles in the world anre not going to help.
So My approach has been to obfuscate the code with virtualization using products like: http://www.oreans.com/codevirtualizer.php I have been very happy with this product. To my knowledge it has neve been defeated. I can even compress the executable with PEcompact Does anyone else have experience with it?
Had nothing but problems with EXEcryptor http://www.strongbit.com/news.asp Even the site is a headache to use. The compiled apps would crash when doing any WMI calls.
This approach allows you to surround smaller sections of code with the obfuscation and thus protect the security checking etc.
I Use the online authorization approach, as the application needs data from the server regularly so it makes no sense for the user to use it off line for extended periods. By definition, the app is worthless at that point, even if it is cracked.
So a simple encrypted handshake is plenty good. I just check it occasionally within the obfuscation protection. If the user installs the app on a different machine, a New ID is uploaded upon launch and the server disables the old ID and returns a new authorization.
I also use a hash of the compiled app and check it at launch to see if a single bit has changed, then open the app as a file (with a read LOCK) from within the app to prevent anyone changing it once launched.
Since all static strings are clearly visible in the .exe file, I try to be generic with error messages and so forth. You will not find the string "Authorization failed" anywhere.
To protect against memory dumps, I use a simple text obfuscation technique (like XOR every character) This makes plain text data in memory harder to distinguish from variables and so forth.
Then of course there is AES for any data that is really sensitive. I like counter mode for text as this results in no repeating sequences revealing underlying data like a sequence of white spaces.
But with all these techniques, if the Key or Initialization vector can be dumped from memory, or the IF statement bypassed, everything is wasted.
I tend to use a switch statement rather than a conditional statement. Then I create a second function that is basically a dead end instead of the function that actually performs the desired task.
Another idea is to code pointers with a variable added. The variable is the result of the authorization (usually zero). This will inevitable lead to a GPF at some point. I only use this as a last resort after a few lower level authorizations have failed otherwise real users may encounter it. Then the reputation of your software is lowered.
What techniques do you use?
(this is NOT a thread debating the merits of implementing something. It is designed for those that have decided to do SOMETHING)
I disagree xsl.
We protect our code, not because we want to protect our revenue - we accept that those who would use if without a license probably would never pay for it anyway.
Instead, we do it to protect the investment our customers have made in our software. We believe that the use of our software makes them more competative in their market place and that if other companies have access to it without paying they have an unfair advantage - ie, they become as competative without having the overhead of the licensing cost.
We are very careful to ensure that the protection - which is home grown - is as unobtrusive as possible to the valid users, and to this end we would never consider 'buying in' an off the shelf solution that may impact this.
这篇关于小型供应商的软件保护的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
