更新： 2011 年 9 月 1 日 Embarcadero 发布 Rad Studio XE2。该版本在已经强大的 delphi 开发环境中添加了 64 位编译、实时绑定、本机 Mac OSX 编译、IOS（通过 XCode）以及更多功能。
Delphi is not dying, it is alive and well.
As is the community, at delphifeeds. You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.
Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.
Update: On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.
I'd suggest the language of business and economics can protect your program.
If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.
If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.
Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.
If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.
No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.
As Dominic said, if you can run it, it can be decompiled.
That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.
For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.
It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.
You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.
I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.
Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.
And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.
The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.
As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.
If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.
The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.
No Programminglanguage,No Programm can Protect your Software. The Software Cracker will reversengine your App till it is just asembler and will crackt it.
This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.
Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.
On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.
发布评论
评论（20）
德尔福并没有消亡，它还活得很好。
与社区一样，位于 delphifeeds。
您还可以在 Delphi Wikia 上查看更多 Delphi 项目、免费软件、共享软件和商业软件。
因此我认为 Delphi 是软件开发的一个非常好的选择。免费软件、共享软件或商业软件。
更新：
2011 年 9 月 1 日 Embarcadero 发布 Rad Studio XE2。该版本在已经强大的 delphi 开发环境中添加了 64 位编译、实时绑定、本机 Mac OSX 编译、IOS（通过 XCode）以及更多功能。
Delphi is not dying, it is alive and well.
As is the community, at delphifeeds.
You can also see more delphi projects, Freeware, shareware and commercial at the Delphi Wikia.
Thus I'd say Delphi is a very good choice for Software Development. Freeware, Shareware or Commercial.
Update:
On September 1st 2011 Embarcadero released Rad Studio XE2. This released adds 64 Bit Compilation, Livebindings, Native Mac OSX compiling, IOS (via XCode) and a whole lot more to the already powerful delphi Dev environment.
如果你的 CPU 能够看到代码并运行它，根据定义，一个足够有才华的人也可以做到。
但是，您可以通过混淆器运行代码来使其变得更加困难。
If your CPU is able to see the code and run it, by definition, a sufficiently talented person can do it too.
You can, however, make it harder by running your code through an obfuscator.
我建议商业和经济学的语言可以保护你的程序。
如果你的目标消费者是消费者，定价为 10 美元，那么几乎所有人都会发现付给你 10 美元比进入你的程序并对其进行逆向工程更容易。
如果您的目标客户是企业，并且定价为 10,000 美元，那么让采购部门批准付款要比对您的代码进行逆向工程更容易。对于真正购买您产品的公司来说，运行未经许可的代码不值得冒审计风险。
最后，保护代码的成本/好处是什么？如果您用汇编语言而不是 C# 编写程序，您的生产成本可能会高得多，同时也会减少逆向工程的机会。然而，这个成本是否超过了潜在的销售损失？这次是否可以更好地花在为购买该产品的人增加价值上？一般来说，试图将你的产品卖给那些从不支付软件费用的人并不是一种经济策略。
I'd suggest the language of business and economics can protect your program.
If you are targeting consumers, and price it at say $10, almost all people would find it easier to pay you the $10 vs going into your program and reverse engineering it.
If you are targeting corporations, and say pricing it at $10,000, it just has to be easier to get the purchasing department to approve the payment than to reverse engineer your code. For real companies who would purchase your product, it's not worth the audit risk to have unlicensed code running.
Lastly, what are the costs/benefits of protecting your code? If you write your program in assembly instead of C#, you might have far higher production costs, while reducing the chance of reverse engineering. However, does this cost outweigh the potential lost sales? Could this time be better spent adding value for people who will buy the product? Generally, trying to sell your product to people who are never pay for software is not a economic strategy.
你可以用 Perl 编写它。
（我开玩笑，我开玩笑！放下干草叉！）
You could write it in Perl.
(I kid, I kid! Put down the pitchforks!)
但其他人没有说的是：
But what the others didn't say is:
跟着我重复一遍：“默默无闻并不意味着安全。”
您最好使用硬加密算法（其中“硬”并不意味着“困难”，而是“不是双向的；不容易逆转”。
Repeat after me: "Obscurity is not security."
You would be better off using a hard encryption algorithm (where "hard" doesn't mean "difficult", but "not bi-directional; not easily reversible".
这在逻辑上不是不可能吗？
如果你可以运行代码，你就可以获得CPU正在执行的指令。那时，对于某些可读的定义，您的算法是可读的。
Isn't this logically impossible?
If you can run the code, you can get the instructions being executed by your CPU. At that point, your algorithm is readable, for some definitions of readable.
没有语言能够做到这一点，据我所知..因为这是不可能的，因为它总是可以被逆向工程..尽管如果你在brainfvck中编码，很多开发人员会哭泣。
No language is capable of that AFAIK.. since it's impossible as it can always be reverse engineered.. though a good number of developers would cry if you coded it in brainfvck though.
“我正在寻找只能反编译为汇编的东西。”
尝试用汇编语言编写程序。这是最好的解决方案。
"I'm looking for something that can be only decompiled into assembly."
Try writing your program in assembly. That is the best possible solution.
如果您真的担心人们反汇编您的软件，请将您的软件作为服务 (SaaS) http://en .wikipedia.org/wiki/Software_as_a_service
if you really concern about people disassemble your software, make your software as a service (SaaS) http://en.wikipedia.org/wiki/Software_as_a_service
尝试找到一个混淆器。顾名思义，它对代码进行了足够的混淆，以至于对其进行逆向工程并不容易。
或者使用C/C++。这些可以拆卸，但仅此而已。
当然，这足以防止能力不足的人理解和逆向工程代码。
Try finding an obfuscator. As the name suggests it obfuscates the code enough that reverse-engineering it will not be trivial.
Or use C/C++. Those can be disassembled, but that's it.
Of course, this is just enough to keep the not-sufficiently-competents from understanding and reverse-engineering the code.
正如Dominic所说，如果你能运行它，它就能被反编译。
也就是说，我相信有一些工具可以混淆编译的代码，并使某人更难反汇编、逆向或分解注册过程。
例如，我相信像 Adobe 和 Microsoft 这样的大公司都使用这样的产品，以便让人们更难反汇编和破解他们的程序。
这就像安全或密码学，甚至你的汽车/房子上的锁 - 拥有足够时间和资源的人可能可以破解任何东西。
你只需要把曲线倾斜得足够大，使其对任何人都没有吸引力去真正尝试，这样他们就更有可能转向更容易的目标。
As Dominic said, if you can run it, it can be decompiled.
That said, I believe there are tools that obfuscate the compiled code and make it more difficult for someone to disassemble and reverse or take apart a registration process.
For example, I believe that major companies like Adobe and Microsoft use products like this, in order to make it much more difficult for folks to disassemble and crack their programs.
It's like security or cryptography or even the locks on your car/house - someone with enough time and resources can probably break through anything.
You just need to tilt the curve enough to make it sufficiently unattractive for anyone to really try, so that they'd be more likely to move onto easier targets.
我将做出这样的假设：因为您正在编写共享软件并且您提到了注册算法，所以您希望保护您的软件免受绕过试用版限制的注册机或补丁的影响。
事实上，你最多能做的就是阻止。就像其他人提到的那样，有可用的混淆技术，但它们不是预防性的。有一些商业软件打包程序可以压缩文件并使其最初无法读取。但程序必须在某个时刻被解压缩，以便机器可以运行它，因此它仍然是可逆的。
这几乎是对抗您将看到的任何防逆转技术的拐杖。它必须在某个时刻被机器解释。更现代的加壳程序使用反调试技术来阻止新手逆向者。但这些技术最终很快就被记录在流行的逆向网站上。只需一个简单的调试器插件就可以绕过许多技术。
我能想到的保护您的可执行文件不被任意逆转的唯一方法是在您控制的服务器上运行整个程序，并将输出通过管道传递给用户。但这并不总是可行的。
至于您的语言选项，请访问此。我无法真正说出它有多完整，但我确信其他人可以添加他们想到的语言。
I am going to make the assumption that because you're writing shareware and you mention a registration algorithm you are wanting to protect your software from a keygen or patch that bypasses the restrictions on your trial versions.
Really the most you can do is deter. Like others have mentioned there are obfuscation techniques available, but they are not preventative. There are commercial software packers available which compress the file and make it initially unreadable. But the program has to be decompressed at some point so the machine can run it, so it's still reversible.
And that is pretty much the crutch against any of the anti-reversing techniques you'll see. It has to be interpreted by the machine at some point. More modern packers use anti-debugging techniques to deter the more novice reversers. But these techniques end up being documented rather quickly on popular reversing sites. Many of the techniques are bypassed with nothing more than a simple debugger plugin.
The only way I can think of to protect your executable from being arbitrarily reversed is to run the whole thing on a server you control and just pipe the output to users. But that's not always feasible.
As far as your language options go, take a loot at this. I can't really speak to how complete it is but I'm sure some others can add languages they think of.
如果您正在寻找“只能反编译为汇编的东西”，这本质上意味着您想要使用直接编译（或汇编）为本机代码可执行文件的语言。
通常的主要嫌疑人是 C、C++、Delphi、VB6。当然，汇编也符合您的标准，尽管我怀疑您是否想在其中编写任何规模合适的项目。
If you're lookig "for something that can be only decompiled into assembly", that essentially means that you want to use a language that gets compiled (or assembled) directly into a native code executable.
The usual prime suspects then are C, C++, Delphi, VB6. Of course, also assembly meets your criteria, although I doubt you'd want to write any project of decent size in it.
非常简单：
没有编程语言，没有程序可以保护您的软件。
软件破解器将对您的应用程序进行逆向工程，直到它只是组装并破解它。
Very simple:
No Programminglanguage,No Programm can Protect your Software.
The Software Cracker will reversengine your App till it is just asembler and will crackt it.
所有代码都可以在汇编中读回。有人可以对您的应用程序进行逆向工程并查看机器正在做什么。
All code can be read back in assembly. Someone can reverse engineer your application and see what the machine is doing.
这与其说是选择正确语言的问题，不如说是找到一个可以为您进行代码混淆的工具的问题。没有什么是万无一失的，但人们正在努力实现这种目标。
例如。请参阅此有关 Java 代码混淆的研究项目。
This is not so much a matter of choosing the right language as it is finding a tool that will do code obfuscation for you. Nothing is bulletproof, but there are efforts to accomplish this sort of thing.
Eg. see this research project about Java code obfuscation.
你不能 100% 确定没有人能够阅读你的代码，但你可以让它变得非常困难。您可以加密代码并在运行时修改它。
例如，我还没有听说过任何对 Skype 进行逆向工程的成功尝试。
You can't be 100% sure nobody will able to read your code, but you can make it very hard. You can encrypt your code and modify it during run time.
For example I have not heard of any successful attempts to reverse engineering Skype.
您始终可以用 APL 编写它。你可以提供源代码，但仍然没有人能够理解它。
You could always write it in APL. You could deliver the source and still no one would be able to understand it.
任何在客户端运行的代码都可以通过足够的试验和错误进行逆向工程。在我看来，让客户端代码仅包含 GUI 代码，同时在服务器端运行需要身份验证等的实际安全性。
另一方面，如果您的应用程序是在客户端运行的服务，例如游戏、CAD、POS 或任何需要在客户端具有高质量代码的内容，我建议将流程输出存储在您的应用程序中。服务器端使用加密上传工具，然后每次在发回数据之前验证客户端的密钥/帐户数据？但对于大多数项目来说，这有点过大了。
Any code running on client-side can be reverse engineered with enough trial and error. In my opinion, make the client-side code contain only the GUI code, while running the actual security requiring authentications etc. on serverside.
On the other hand, if your app's a service which runs on the client-side, such as a game, CAD, POS or anything that needs to have high quality code on the client-side, I'd recommend storing process outputs on your server-side with an encrypted upload tool, then authenticate the client's key/account data every-time before sending their data back? It is an overkill for most projects though.