混淆是一种方法,但它不能防止破坏应用程序的盗版保护安全性。如何确保应用程序不被篡改,如何确保注册机制不会被逆向工程?
此外,还可以将c#应用程序转换为本机代码,而Xenocode的成本太高。
c#提供了很多特性,是编写代码的理想语言,所以用c++重新编写整个代码库是不可能的。
安全证书可以很容易地从. net中的签名程序集中删除。
混淆是一种方法,但它不能防止破坏应用程序的盗版保护安全性。如何确保应用程序不被篡改,如何确保注册机制不会被逆向工程?
此外,还可以将c#应用程序转换为本机代码,而Xenocode的成本太高。
c#提供了很多特性,是编写代码的理想语言,所以用c++重新编写整个代码库是不可能的。
安全证书可以很容易地从. net中的签名程序集中删除。
当前回答
坦率地说,有时我们需要混淆代码(例如,注册许可类等)。在这种情况下,您的项目不是免费的。在我看来,你应该花钱买个好东西。
Dotfuscator隐藏代码,. net Reflector在尝试反编译时显示错误。
其他回答
如果您希望人们能够运行您的代码(如果您不希望,那么为什么要首先编写它?),那么他们的CPU需要能够执行您的代码。为了能够执行代码,CPU需要能够理解它。
由于cpu是愚蠢的,而人类不是,这意味着人类也可以理解代码。
只有一种方法可以确保你的用户不会得到你的代码:不要把你的代码给他们。
这可以通过两种方式实现:软件即服务(SaaS),即在服务器上运行软件,只允许用户远程访问它。例如,这就是Stack Overflow使用的模型。我很确定Stack Overflow不会混淆他们的代码,但是你不能反编译它。
The other way is the appliance model: instead of giving your users your code, you give them a computer containing the code. This is the model that gaming consoles, most mobile phones and TiVo use. Note that this only works if you "own" the entire execution path: you need to build your own CPU, your own computer, write your own operating system and your own CLI implementation. Then, and only then can you protect your code. (But note that even the tiniest mistake will render all of your protections useless. Microsoft, Apple, Sony, the music industry and the movie industry can attest to that.)
或者,您可以什么都不做,这意味着您的代码将自动受到版权法的保护。
还有Salamander,这是一个来自Remotesoft的原生。net编译器和链接器,可以在没有。net框架的情况下部署应用程序。我不知道它是否符合它所宣称的。
您不能完全保护任何应用程序(托管与否)。如果像Playstation和iPad这样的系统都被破解了——厂商甚至控制着硬件——你的应用还有什么希望呢?幸运的是,你并不是真的想这么做。在我看来,你需要确保你的应用程序足够安全,这样别人就不会意外地窃取你的产品。
例如,如果使用每台机器许可证,那么它不应该只在安装到新的第二台机器上时才能工作。你需要一个好的错误消息来防止额外的支持呼叫,但不要花费额外的时间让它难以解决,也不要用它来打击用户。
另一个例子是限时审判。甚至不用担心简单的事情,比如用户是否可以回滚系统时钟。这样做的人知道他们违反了您的许可,只要用户知道他们违反了您的许可,您就做得够多了。
You need to do this much because users don't care about your license. Licenses are made-up things that nobody cares about until they need to. No one reads them, and they really shouldn't have to. Therefore the best way to tell the user where the boundaries are is if the out-of-the-box behavior for your application complies with the license. In this first case that means either failing to install or installing in trial-version mode the second time. For the latter, it might just mean checking a plain-text date in a configuration file. Either way, make sure you handle it in an elegant, helpful, and respectful manner.
So that explains what it means do just that much. But why not go any further? Why not plug every little hole you can find? The answer is in two parts. First, if someone will cross the ethical threshold of consciously breaking your license terms — even in a simple way — they'll also be willing to do something more difficult or dangerous like pull your application from a torrent site — and there is a certain amount of danger involved in running applications downloaded from untrusted sources. Making it any harder is only a minor annoyance for these users and risks causing problems with your paying customers. Keeping it simple may prevent someone from digging into your application and releasing a more comprehensive crack. Second, you have few eyes available to look for flaws; the hackers have many, and they have more practice finding them. You only need to miss one little flaw, and your app will have the same distribution on pirate sites as if you did nothing. You have to be right every time; they only have to be lucky once. So the effort required is very high, and the likelihood of any measure of success is very low.
Ultimately, if someone wants to pirate your application (as opposed to just using it), and that is their main goal, they will. There's nothing you can do to stop them. This is the nature of software; once the files that make up your product are on a user's computer they will be able to do with them as they wish. This is especially relevant in managed environments like Java or .NET, but it definitely applies to native code as well. Time is on their side, and given enough time any digital security can be broken.
Since you can't stop users from pirating your product, your best course of action is to engage this class of user in a way the uses them to your benefit. It is often possible to get them working for you rather than against you. With that in mind, no matter what your application is, it's probably worth it to keep a free version that is almost completely functional and doesn't expire. The difference between even a US$1 price tag and free is huge, if for no other reason than that the customer doesn't have to trust you with their credit card. A free edition of your product will not only effectively kill pirated distribution (why risk a pirated version when you can be legitimate for the same price?), it has the potential to dramatically expand your audience.
结果是,你可能需要提高付费版的价格,这样最终你就有10万免费用户,而不是2000个用户,每人20美元,其中500人愿意为“专业版”支付99美元。这比你花大量时间锁定你的产品赚得更多。不仅如此,你还可以通过多种重要方式吸引这些免费用户并利用这种关系。
一是支持。悲观主义者会借此机会抱怨支持10万免费用户的成本增加,但令人惊讶的事情却发生了:你的产品基本上可以自给自足。在没有资金支持成本的大型开源项目中,您经常会看到这种情况。用户会挺身而出,让它成为现实。
Free users generally have reduced support expectations to begin with, and for good reason. All you need to do is mark the free edition as only qualifying for community support and put up a user-moderated online forum for that purpose. Your support knowledge base is self-generating, and advanced users will shepherd those who need extra hand-holding on your behalf. Even more importantly, this will allow you to identify and correct bugs faster, ultimately improving the quality of your product and lowering total support costs. This wasn't possible before because your user base wasn't large enough, but when you treat the free users as customers it can work very well.
另一个是反馈。通过观察你的论坛,你可以学到重要的改进想法,否则你可能从来没有考虑过。这可以让你最终将更多免费用户转变为付费用户,并创造出更有吸引力的产品,从而吸引更多用户。
最后,你需要考虑市场营销。所有这些免费用户现在都是粉丝,而不是对手,他们会采取相应的行动。不仅如此,当你发布下一个版本时,这些用户都将通过你批准的分发渠道,而不是其他未知的机制。这意味着在你的下一个版本中,你开始与更大的、高度感兴趣和支持你的观众建立联系。
The best features to reserve for the professional edition are tools aimed at making it easy to do corporate deployment and management. A cracker won't see these as a compelling enough reason to hack it for his own use, but for a business looking to buy 300 licenses and push it out company-wide this is a must-have. Of course, the professional edition will be pirated anyway, but again: don't sweat it because you probably wouldn't be able to sell the product to those pirates no matter what you did, so it's not costing you any revenue.
While psychologically it can be hard to give away your product this much, hopefully you can understand how it really is the best way to go. Not only that, it's the only way to go in the long term. I know someone is out there thinking that they don't want to do it this way. After all, they've got by just fine selling their locked-down $20 product for years. But that's just too bad, because if you don't do it this way, eventually someone else will. And their product will be just as good as yours, or close enough they can get away with claiming that. Then all of a sudden your pricing looks outrageous, sales drop dramatically, and there's nothing else you can do. You can opt for an additional middle tier if you must, but it's unlikely to help you.
好吧,你不能完全保护你的产品不被破解,但你可以最大化/增强安全级别,让它有点难以被新手和中级破解者破解。
但请记住,没有什么是不可破解的,只有服务器端的软件受到了很好的保护,无法被破解。无论如何,为了增强应用程序中的安全级别,您可以执行一些简单的步骤来防止某些黑客“不是全部”破解您的应用程序。下面这些步骤会让你抓狂甚至绝望:
Obfuscate your source code, obviously this will make your source code look like a mess and unreadable. Trigger several random checking routines inside your application like every two hours, 24 hours, one day, week, etc. or maybe after every action the user take. Save your released application's MD5 checksum on your server and implement a routine that can check the current file MD5 checksum with the real one on you server side and make it randomly triggered. If the MD5 checksum has been changed that means this copy has been pirated. Now you can just block it or release an update to block it, etc. Try to make a routine that can check if some of your codes (functions, classes, or specific routines) are actually have been modified or altered or even removed. I call it (code integrity check). Use free unknown packers to pack your application. Or, if you have the money, go for commercial solutions such as Thamida or .NET Reactor. Those applications get updated regularly and once a cracker unpack your application, you can just get a new update from those companies and once you get the new update, you just pack your program and release a new update. Release updates regularly and force your customer to download the latest update. Finally make your application very cheap. Don't make it too expensive. Believe me, you will get more happy customers and crackers will just leave your application, because it isn't worth their time to crack a very cheap application.
这些只是防止新手和中级破解者破解应用程序的简单方法。如果您有更多保护应用程序的想法,请不要羞于实现它们。这只会让破解者的生活变得艰难,他们会感到沮丧,最终他们会离开你的应用程序,因为它不值得他们花费时间。
最后,你还需要考虑花时间编写一个好的、高质量的应用程序。不要把时间浪费在编写复杂的安全层上。如果一个优秀的破解者想要破解你的应用程序,无论你做什么,他/她都会做。
现在去实现一些玩具饼干…
. net Reflector只能打开“托管代码”,这基本上意味着“。NET代码”。所以你不能用它来分解COM DLL文件、原生c++、经典的Visual Basic 6.0代码等。编译后的。net代码的结构非常方便、可移植、可发现、可验证等。net Reflector利用了这一点,让你窥探已编译的程序集,但反编译器和反汇编器绝不是。net特有的,它们和编译器一样早就存在了。
您可以使用混淆器使代码更难阅读,但是您不能在不使. net无法读取的情况下完全阻止它被反编译。市面上有一些产品(通常价格昂贵)声称可以将托管代码应用程序“链接”到本地代码应用程序,但即使这些产品真的可以工作,有决心的人总能找到方法。
然而,当涉及到混淆时,一分钱一分货。因此,如果您的代码是如此专有,以至于您必须竭尽全力来保护它,那么您应该愿意在一个好的混淆器上投资。
However, in my 15 or so years of experience writing code I've realized that being over-protective of your source code is a waste of time and has little benefit. Just trying to read original source code without supporting documentation, comments, etc. can be very difficult to understand. Add to that the senseless variable names that decompilers come up with and the spaghetti code that modern obfuscators create - you probably don't have to worry too much about people stealing your intellectual property.