I work for a company selling protected Java software.
I won't comment on the scheme for user authentication, but I can comment on the online license check.
Don't make it even "work for two days": that's how I pirate most software... Virtual Machine set "back in time" and externally firewalled so that it doesn't "phone home" anymore (that is: only allowing it to contact the server once, to get the trial key), always reimaged from the point where the software got freshly installed and bingo, the 30-days trial (or two days trial) has become a lifetime trial. Why do I do this? To learn how to better protect our app of course ;) (ok, ok, I do it just for fun too)
What we do in our commercial Java software is to check the license at every startup.
We've got hundreds of customers and nobody ever bitched about it. Not once. We generate a unique class at each run, which is different at every run, which depends both on things unique for that launch on the client side and on things generated once on the server side.
In addition to that having the app contact your server at every launch is a great way to gather analytics: download to trial ratio, nb average launches per trial, etc. And it's not nasty anymore than having an Urchin/Google JavaScript tracker on each webpage is nasty.
Simply make it clear to people that your software performs the online licence check: we'got a huge checkbox either on or off saying: "Online licence verification: OK/Failed". And that's it. People know there's a check. If they don't like it, they go use inferior competitor products and life is good.
People are used to live in a wired world.
How often can you not access GMail because your Internet connection is down? How often can you not access FaceBook or SO because your Internet connection is down?
Point is: make as much computation as possible dependent on the server side:
licence check
save user preferences
backup of the data generated by your app
etc.
Nobody will complain. You'll have 0.1% of your user complain and anyway you don't want these users: they're the one who would complain about other things and post negative feedback about your app online. You better have them not to use your software at all and complain about the fact that it requires an always-on Internet connection (which 99.99% of your target demographic and hence they won't care about the complain) rather than actually have them use the app, and complain about other things related to your app.
Regarding decompiling, .class can usually be decompiled back to .java unless you're using a code flow obfuscator that produces valid bytecode but that it impossible to be generated from .java file (hence it is impossible to get back a valid .java file).
String obfuscator helps make it harder to figure out.
Source code obfuscator helps make it harder to figure out.
Bytecode obfuscator like the free Proguard makes it harder (and produce faster code, especially noticeable in the mobile world) to figure out.
If you're shipping Windows/Linux only then you can use a Java-to-native converter like Excelsior Jet (not free and kinda expensive for startups, but it produces native code from which you simply cannot find the .java files back).
As a funny side note you'll see people trying to mess with your online server... At about 30 beta-testers we had already people (which we know where part of the trial) trying to pirate our online servers.
I am sorry to turn you down, but first you should have an idea of what you want to build; then you should prove that your idea not only works, but is also loved by users to the point where they want to pirate it. Thirdly, you have to make sure that the time you are investing in making it "secure" is actually worth the value of the application.
If you sell it for a dollar, and you only sell ten copies, and you spent 100 hours making it secure, you do the math and tell me if your time was worth that little money.
The take-home message here is: everything can be cracked or copied. At the end there are much brighter people than us doing this (iPhone cracking, digital TV, games, etc) and nobody found the silver bullet. Only thing you can do is make it harder to crack your application (often at the expenses of usability, ease of installation, and by cutting corners for some use scenarios). Asking yourself if it's worth the hassle it's always a good starting point.
The gaming industry has been battling piracy for decades. Online multiplayer games with a central server typically require a subscription to play. That model is fairly resistant to piracy. Pretty much all other games are heavily pirated, despite innumerable attempts at DRM.
Your app will be cracked and pirated, no matter what language you write it in and what tools you use to prevent it. If your DRM actually works, the people who would have pirated it still won't buy it. Furthermore, legitimate users will prefer other products that don't have intrusive DRM. If there are no competing products and yours has any market to speak of, someone will create one.
Unless your application is specifically web based your users will find it to be a huge hassle to require an internet connection in order that they might access the product. What you are suggesting will work, unless it gets broken, like all DRM systems do. I understand the want to protect your intellectual property, but with many companies as examples, these systems are usually broken or the product does much worse because of them.
首先，如果您担心这个问题，最好选择 Java 之外的语言。这就是为什么 C++ 在商业应用程序世界中仍然活跃并表现良好的原因。除非您打算使用实际的 Java 编译器来生成本机 exe，否则出于 IP 保护的原因，我会重新考虑 Java。
就此而言，即使是 C++ 也不能免受破解，但 IP 保护与破解是两个独立的重要问题。
I have really no idea of how to protect it from being cracked and distributed as warez.
First, you'd be better choosing a language besides Java, if this is a concern. This is why C++ is still alive and well in the commercial apps world. Unless you are going to use an actual Java compiler to native exe, I'd reconsider Java for IP protection reasons.
For that matter, even C++ isn't impervious to cracking, but IP prorection vs. cracking are two separate, important concerns.
That's a really tricky task, especially with something running in a VM. I would say you might be thinking in the right direction. Obfuscating it to make it reasonably hard to modify might prevent people from circumventing the built in licence checks.
However, ultimately, if your application is self-contained, it will always be crackable. If you can build it so that it uses services you provide, than you can probably command it's use.
To paraphrase a Mr Jeff Atwood, it is better to make it easier for your customer to pay you than it is to crack your app. In other words, I think you are attacking the wrong problem. Make buying your product REALLY easy and then your customers won't feel they need to go to the effort of cracking it.
I would have a look at the backlash from the game Spore before deciding on a licensing scheme. They had it phone home, and only allowed so-many installations, etc. etc. etc. Spore was supposed to be their "Killer App" and it really had a hard time simply because of the licensing. You say you are willing to have fewer sales than see people using it for free, but you may want to be careful what you ask for. I was really looking forward to spore (and so were my children) but I never did buy it because of the DRM scheme.
No matter what you do, it'll be cracked in very short order especially if the program really is worth anything.
If you do go with a licensing scheme, make it simple and usable so you are not punishing those that have actually paid for your software. Also, I would avoid any phone-home style checks, that way your customers will be able to continue to use the software even if you don't want to keep paying for that domain 3 years from now.
I see a specific weakness in your example, besides the comment most people already put in that DRM is hard(impossible) to implement and often simple to circumvent.
In your second point:
If everything is fine, the server returns some crucial missing parts of the program bound to that certain pc along with the usage limit of say 2 days
This 2 (or X) days limit will most likely be extremely simple to circumvent, this would just a few minutes to find and patch (crack).
If you really want to have a DRM model the only reasonable way to go is to put at significant part of the application as a web service and require constant connection from the users.
Before you try any of this, be sure to read Exploiting Software and you will think twice before trying to do DRM.
I think, given the context, the most effective form of protection for now would be the limited demo/license key approach: it would give people time to fall in love with your application so that they are willing to pay for it, yet prevent casual copying.
Once you know that your app hit it big, and that crackers provably siphon off a significant portion of your possible earnings, then you can still add additional checks.
Another thing to consider is where your app is going to be used: if it's something people would put on the their laptops to use on the go, network connectivity is not a given.
That is some of the harshest DRM I've ever heard of, your users would hate it.
Also, keep in mind that there are a lot of good Java decompilers out there due to the nature of the language and someone determined enough could just find areas of the program dealing with your DRM and bypass/disable it then recompile it (according to this a recompilation would be unrealistic)... so you would even have to go out of your way to implement your code as complex as possible to prevent a hacker from being successful. (Which could be done with one of those code obfuscation tools they may have out there.)
As long as it's an Internet application, you could restrict it in that manner. Short of cracking the program, this would work fine except for replay attacks.
For example, if I can capture the traffic that is going to your server, and simply replay it back to my program each time, I'm still good. For example, I could create my own "web server" and ensure the program hits that instead of your server.
You should read "Surreptitious Software" from Collberg and Nagra. This book is really good to help you understand how software protection mechanisms work (such as Code obfuscation, watermarking, birthmarking, etc...).
As lorenzog said, total security doesn't exist and software security is like a constant race between software vendors and pirates.
You should use cheap obfuscating transformations (so the overhead they incur isn't killing the performances) to prevent as many attackers (remember most of them are script kiddies) as possible to "steal" your killer algorithms or any secret data.
If you're willing to push the security further you can birthmark your algorithms and watermark your copies in order to find who leaked your creation. But even if you do, this doesn't mean your software is 100% secured. Plus the time you'll spend adding these mechanisms might not be worth the effort.
These concepts are really well explained in the book I mentioned before which is worth reading.
If I had enough reputation points, I'd vote this question down. Commercial software protection is a waste of time, money, and effort for many reasons. Concentrate on making a piece of software worth buying. If your software is popular enough to maintain wide seeding by pirates, you're probably successful enough at that point that you won't even worry about piracy. Anyway, crackers crack software protection mostly for fun. The stronger your protection, the better the challenge it presents and the more they want to crack it. Your best effort will cost you thousands, take months, and be cracked in only days.
发布评论
评论（14）
我在一家销售受保护 Java 软件的公司工作。
我不会评论用户身份验证的方案，但我可以评论在线许可证检查。
甚至不要让它“工作两天”：这就是我盗版大多数软件的方式......虚拟机设置“回到过去”并设置外部防火墙，以便它不再“打电话回家”（即：只允许（它与服务器联系一次，获取试用密钥），总是从新安装软件时重新映像，宾果游戏，30 天试用（或两天试用）已成为终身试用。我为什么要这样做？当然是为了学习如何更好地保护我们的应用程序；）（好吧，好吧，我这样做也只是为了好玩）
我们在商业 Java 软件中所做的是在每次启动时检查许可证。
我们有数百名客户，但没有人对此抱怨过。一次也没有。我们在每次运行时生成一个唯一的类，该类在每次运行时都不同，这既取决于客户端启动时的唯一性，也取决于服务器端生成的内容。
除此之外，让应用程序在每次启动时联系您的服务器是收集分析数据的好方法：下载试用率、每次试用的平均启动次数等。这并不比在每个网页上使用 Urchin/Google JavaScript 跟踪器更令人讨厌。是令人讨厌的。
只需向人们明确表示您的软件执行在线许可证检查：我们有一个打开或关闭的巨大复选框，上面写着：“在线许可证验证：正常/失败”。就是这样。人们知道有一张支票。如果他们不喜欢，他们就会去使用劣质的竞争对手的产品，这样生活就很好了。
人们习惯于生活在有线世界中。
您有多少次因为互联网连接中断而无法访问 GMail？您有多少次因为互联网连接中断而无法访问 Facebook 或 SO？
要点是：尽可能多地依赖服务器端进行计算：
没有人会抱怨。您将有 0.1% 的用户抱怨，无论如何您不希望这些用户：他们会抱怨其他事情并在线发布有关您的应用程序的负面反馈。你最好让他们根本不要使用你的软件，并抱怨它需要始终在线的互联网连接（99.99% 的目标人群，因此他们不会关心抱怨），而不是实际让他们使用应用程序，并抱怨与您的应用程序相关的其他问题。
关于反编译，.class 通常可以反编译回 .java，除非您使用生成有效字节码的代码流混淆器，但不可能从 .java 文件生成（因此不可能取回有效的 .java 文件） ）。
字符串混淆器有助于使其更难弄清楚。
源代码混淆器有助于使其更难弄清楚。
像免费的 Proguard 这样的字节码混淆器使得弄清楚（并生成更快的代码，尤其是在移动世界中尤其明显）变得更加困难。
如果您只提供 Windows/Linux，那么您可以使用像 Excelsior Jet 这样的 Java 到本机转换器（对于初创公司来说不是免费的，而且有点贵，但它生成的本机代码是您无法找到的） .java 文件返回）。
有趣的是，您会看到有人试图破坏您的在线服务器...在大约 30 个 beta 测试人员中，我们已经有人（我们知道试验的一部分）试图盗版我们的在线服务器。
I work for a company selling protected Java software.
I won't comment on the scheme for user authentication, but I can comment on the online license check.
Don't make it even "work for two days": that's how I pirate most software... Virtual Machine set "back in time" and externally firewalled so that it doesn't "phone home" anymore (that is: only allowing it to contact the server once, to get the trial key), always reimaged from the point where the software got freshly installed and bingo, the 30-days trial (or two days trial) has become a lifetime trial. Why do I do this? To learn how to better protect our app of course ;) (ok, ok, I do it just for fun too)
What we do in our commercial Java software is to check the license at every startup.
We've got hundreds of customers and nobody ever bitched about it. Not once. We generate a unique class at each run, which is different at every run, which depends both on things unique for that launch on the client side and on things generated once on the server side.
In addition to that having the app contact your server at every launch is a great way to gather analytics: download to trial ratio, nb average launches per trial, etc. And it's not nasty anymore than having an Urchin/Google JavaScript tracker on each webpage is nasty.
Simply make it clear to people that your software performs the online licence check: we'got a huge checkbox either on or off saying: "Online licence verification: OK/Failed". And that's it. People know there's a check. If they don't like it, they go use inferior competitor products and life is good.
People are used to live in a wired world.
How often can you not access GMail because your Internet connection is down? How often can you not access FaceBook or SO because your Internet connection is down?
Point is: make as much computation as possible dependent on the server side:
Nobody will complain. You'll have 0.1% of your user complain and anyway you don't want these users: they're the one who would complain about other things and post negative feedback about your app online. You better have them not to use your software at all and complain about the fact that it requires an always-on Internet connection (which 99.99% of your target demographic and hence they won't care about the complain) rather than actually have them use the app, and complain about other things related to your app.
Regarding decompiling, .class can usually be decompiled back to .java unless you're using a code flow obfuscator that produces valid bytecode but that it impossible to be generated from .java file (hence it is impossible to get back a valid .java file).
String obfuscator helps make it harder to figure out.
Source code obfuscator helps make it harder to figure out.
Bytecode obfuscator like the free Proguard makes it harder (and produce faster code, especially noticeable in the mobile world) to figure out.
If you're shipping Windows/Linux only then you can use a Java-to-native converter like Excelsior Jet (not free and kinda expensive for startups, but it produces native code from which you simply cannot find the .java files back).
As a funny side note you'll see people trying to mess with your online server... At about 30 beta-testers we had already people (which we know where part of the trial) trying to pirate our online servers.
我很抱歉拒绝您，但是首先您应该了解自己想要构建什么；那么您应该证明您的想法不仅有效，而且还受到用户的喜爱，以至于他们想要盗版。第三，您必须确保您为使其“安全”而投入的时间实际上值得应用程序的价值。
如果你以一美元的价格出售它，而你只卖了十份，并且你花了 100 个小时来确保它的安全，那么你会计算一下并告诉我你的时间是否值得那么一点钱。
这里要传达的信息是：一切都可以破解或复制。最后，有比我们更聪明的人在做这件事（iPhone破解、数字电视、游戏等），但没有人找到灵丹妙药。您唯一能做的就是让您的应用程序更难被破解（通常会牺牲可用性、安装的简易性，并在某些使用场景中偷工减料）。问问自己是否值得这么麻烦，这总是一个好的起点。
I am sorry to turn you down, but first you should have an idea of what you want to build; then you should prove that your idea not only works, but is also loved by users to the point where they want to pirate it. Thirdly, you have to make sure that the time you are investing in making it "secure" is actually worth the value of the application.
If you sell it for a dollar, and you only sell ten copies, and you spent 100 hours making it secure, you do the math and tell me if your time was worth that little money.
The take-home message here is: everything can be cracked or copied. At the end there are much brighter people than us doing this (iPhone cracking, digital TV, games, etc) and nobody found the silver bullet. Only thing you can do is make it harder to crack your application (often at the expenses of usability, ease of installation, and by cutting corners for some use scenarios). Asking yourself if it's worth the hassle it's always a good starting point.
别打扰。
数十年来，游戏行业一直在与盗版作斗争。具有中央服务器的在线多人游戏通常需要订阅才能玩。该模型对盗版具有相当的抵抗力。尽管在 DRM 方面进行了无数次尝试，但几乎所有其他游戏都被严重盗版。
无论您用什么语言编写应用程序以及使用什么工具来防止它，您的应用程序都将被破解和盗版。如果您的 DRM 确实有效，那些想要盗版它的人仍然不会购买它。此外，合法用户会更喜欢其他没有侵入性 DRM 的产品。如果没有竞争产品，而你的产品有市场可言，就会有人创造一个。
Don't bother.
The gaming industry has been battling piracy for decades. Online multiplayer games with a central server typically require a subscription to play. That model is fairly resistant to piracy. Pretty much all other games are heavily pirated, despite innumerable attempts at DRM.
Your app will be cracked and pirated, no matter what language you write it in and what tools you use to prevent it. If your DRM actually works, the people who would have pirated it still won't buy it. Furthermore, legitimate users will prefer other products that don't have intrusive DRM. If there are no competing products and yours has any market to speak of, someone will create one.
除非您的应用程序专门基于网络，否则您的用户会发现需要互联网连接才能访问该产品是一个巨大的麻烦。你所建议的将会起作用，除非它像所有 DRM 系统一样被破坏。我理解保护您的知识产权的愿望，但以许多公司为例，这些系统通常会被破坏，或者产品会因此而变得更糟。
Unless your application is specifically web based your users will find it to be a huge hassle to require an internet connection in order that they might access the product. What you are suggesting will work, unless it gets broken, like all DRM systems do. I understand the want to protect your intellectual property, but with many companies as examples, these systems are usually broken or the product does much worse because of them.
首先，如果您担心这个问题，最好选择 Java 之外的语言。这就是为什么 C++ 在商业应用程序世界中仍然活跃并表现良好的原因。除非您打算使用实际的 Java 编译器来生成本机 exe，否则出于 IP 保护的原因，我会重新考虑 Java。
就此而言，即使是 C++ 也不能免受破解，但 IP 保护与破解是两个独立的重要问题。
First, you'd be better choosing a language besides Java, if this is a concern. This is why C++ is still alive and well in the commercial apps world. Unless you are going to use an actual Java compiler to native exe, I'd reconsider Java for IP protection reasons.
For that matter, even C++ isn't impervious to cracking, but IP prorection vs. cracking are two separate, important concerns.
这是一项非常棘手的任务，尤其是在虚拟机中运行的东西。
我想说你可能正在朝着正确的方向思考。对其进行混淆处理以使其难以修改可能会阻止人们绕过内置的许可证检查。
然而，最终，如果您的应用程序是独立的，那么它将始终是可破解的。如果您可以构建它，以便它使用您提供的服务，那么您就可以命令它的使用。
That's a really tricky task, especially with something running in a VM.
I would say you might be thinking in the right direction. Obfuscating it to make it reasonably hard to modify might prevent people from circumventing the built in licence checks.
However, ultimately, if your application is self-contained, it will always be crackable. If you can build it so that it uses services you provide, than you can probably command it's use.
用杰夫·阿特伍德先生的话来说，让客户更容易向您付款比破解您的应用程序更好。换句话说，我认为你正在解决错误的问题。让购买您的产品变得非常容易，然后您的客户就不会觉得他们需要付出努力来破解它。
To paraphrase a Mr Jeff Atwood, it is better to make it easier for your customer to pay you than it is to crack your app. In other words, I think you are attacking the wrong problem. Make buying your product REALLY easy and then your customers won't feel they need to go to the effort of cracking it.
在决定许可方案之前，我会先看看《孢子》游戏的强烈反对。他们给它打电话，只允许安装这么多次，等等。《孢子》应该是他们的“杀手级应用程序”，但仅仅因为许可问题，它确实遇到了困难。您说您愿意获得比看到人们免费使用它更少的销售额，但您可能需要小心您的要求。我真的很期待《孢子》（我的孩子们也很期待），但由于 DRM 计划，我从未购买过它。
无论你做什么，它都会在很短的时间内被破解，特别是如果该程序确实有价值的话。
如果您确实采用许可方案，请使其简单且可用，这样您就不会惩罚那些实际为您的软件付费的人。另外，我会避免任何回拨式检查，这样即使您不想在 3 年后继续为该域名付费，您的客户也将能够继续使用该软件。
I would have a look at the backlash from the game Spore before deciding on a licensing scheme. They had it phone home, and only allowed so-many installations, etc. etc. etc. Spore was supposed to be their "Killer App" and it really had a hard time simply because of the licensing. You say you are willing to have fewer sales than see people using it for free, but you may want to be careful what you ask for. I was really looking forward to spore (and so were my children) but I never did buy it because of the DRM scheme.
No matter what you do, it'll be cracked in very short order especially if the program really is worth anything.
If you do go with a licensing scheme, make it simple and usable so you are not punishing those that have actually paid for your software. Also, I would avoid any phone-home style checks, that way your customers will be able to continue to use the software even if you don't want to keep paying for that domain 3 years from now.
我在您的示例中看到了一个具体的弱点，除了大多数人已经提出的评论之外，即 DRM 很难（不可能）实施并且通常很容易规避。
在你的第二点中：
这个 2（或 X）天的限制很可能非常容易规避，只需几分钟即可找到并修补（破解）。
如果您确实想要拥有 DRM 模型，唯一合理的方法是将应用程序的重要部分作为 Web 服务，并需要用户的持续连接。
在尝试任何此操作之前，请务必阅读利用软件，您将在尝试进行 DRM 之前请三思。
I see a specific weakness in your example, besides the comment most people already put in that DRM is hard(impossible) to implement and often simple to circumvent.
In your second point:
This 2 (or X) days limit will most likely be extremely simple to circumvent, this would just a few minutes to find and patch (crack).
If you really want to have a DRM model the only reasonable way to go is to put at significant part of the application as a web service and require constant connection from the users.
Before you try any of this, be sure to read Exploiting Software and you will think twice before trying to do DRM.
我认为，考虑到目前的情况，目前最有效的保护形式是有限的演示/许可证密钥方法：它会让人们有时间爱上您的应用程序，以便他们愿意为此付费，但又防止随意使用复制。
一旦您知道您的应用程序大受欢迎，并且破解者可能会吸走您可能收入的很大一部分，那么您仍然可以添加额外的支票。
另一件需要考虑的事情是您的应用程序将在哪里使用：如果人们将其放在笔记本电脑上以便在旅途中使用，则网络连接不是给定的。
I think, given the context, the most effective form of protection for now would be the limited demo/license key approach: it would give people time to fall in love with your application so that they are willing to pay for it, yet prevent casual copying.
Once you know that your app hit it big, and that crackers provably siphon off a significant portion of your possible earnings, then you can still add additional checks.
Another thing to consider is where your app is going to be used: if it's something people would put on the their laptops to use on the go, network connectivity is not a given.
这是我听过的最严厉的 DRM，您的用户会讨厌它。
另外，请记住，由于语言的性质，有很多好的 Java 反编译器，并且有足够决心的人可以找到处理 DRM 的程序区域并绕过/禁用它
然后重新编译它< /strike> （根据此重新编译是不现实的）...所以你甚至必须不遗余力地实现尽可能复杂的代码，以防止黑客得逞。 （这可以使用他们可能拥有的代码混淆工具之一来完成。）That is some of the harshest DRM I've ever heard of, your users would hate it.
Also, keep in mind that there are a lot of good Java decompilers out there due to the nature of the language and someone determined enough could just find areas of the program dealing with your DRM and bypass/disable it
then recompile it(according to this a recompilation would be unrealistic)... so you would even have to go out of your way to implement your code as complex as possible to prevent a hacker from being successful. (Which could be done with one of those code obfuscation tools they may have out there.)只要是互联网应用程序，就可以通过这种方式对其进行限制。如果不破解程序，除了重放攻击之外，这一切都可以正常工作。
例如，如果我可以捕获流向您的服务器的流量，并且每次只需将其重播回我的程序，我仍然可以。例如，我可以创建自己的“网络服务器”并确保程序命中该服务器而不是您的服务器。
As long as it's an Internet application, you could restrict it in that manner. Short of cracking the program, this would work fine except for replay attacks.
For example, if I can capture the traffic that is going to your server, and simply replay it back to my program each time, I'm still good. For example, I could create my own "web server" and ensure the program hits that instead of your server.
您应该阅读 Collberg 和 Nagra 的“秘密软件”。这本书非常适合帮助您了解软件保护机制的工作原理（例如代码混淆、水印、胎记等）。
正如洛伦佐格所说，完全的安全并不存在，软件安全就像软件供应商和盗版者之间的一场持续的竞赛。
您应该使用廉价的混淆转换（因此它们产生的开销不会影响性能）来防止尽可能多的攻击者（记住他们中的大多数都是脚本小子）“窃取”您的杀手算法或任何秘密数据。
如果您愿意进一步提高安全性，您可以在您的算法上添加胎记并在您的副本上添加水印，以便找到谁泄露了您的创作。但即使您这样做，也不意味着您的软件是 100% 安全的。另外，您花在添加这些机制上的时间可能不值得。
这些概念在我之前提到的书中得到了很好的解释，值得一读。
You should read "Surreptitious Software" from Collberg and Nagra. This book is really good to help you understand how software protection mechanisms work (such as Code obfuscation, watermarking, birthmarking, etc...).
As lorenzog said, total security doesn't exist and software security is like a constant race between software vendors and pirates.
You should use cheap obfuscating transformations (so the overhead they incur isn't killing the performances) to prevent as many attackers (remember most of them are script kiddies) as possible to "steal" your killer algorithms or any secret data.
If you're willing to push the security further you can birthmark your algorithms and watermark your copies in order to find who leaked your creation. But even if you do, this doesn't mean your software is 100% secured. Plus the time you'll spend adding these mechanisms might not be worth the effort.
These concepts are really well explained in the book I mentioned before which is worth reading.
如果我有足够的声誉点，我会否决这个问题。由于多种原因，商业软件保护浪费时间、金钱和精力。专注于制作一款值得购买的软件。如果您的软件足够流行，足以维持盗版的广泛传播，那么您可能已经足够成功，甚至不必担心盗版。不管怎样，破解者破解软件保护主要是为了好玩。你的保护越强，它带来的挑战就越大，他们就越想破解它。你的最大努力将花费你数千美元，花费数月时间，并且在短短几天内就被破解。
If I had enough reputation points, I'd vote this question down. Commercial software protection is a waste of time, money, and effort for many reasons. Concentrate on making a piece of software worth buying. If your software is popular enough to maintain wide seeding by pirates, you're probably successful enough at that point that you won't even worry about piracy. Anyway, crackers crack software protection mostly for fun. The stronger your protection, the better the challenge it presents and the more they want to crack it. Your best effort will cost you thousands, take months, and be cracked in only days.