事实核查：.NET 应用程序有多容易被反编译？
我在 MSMobiles.com 博客上看到这篇文章，其中包含以下内容事物：
.Net 在很多方面都很出色，但对于 商业应用程序？ 决不！ 任何人都可以 只需查看您的源代码即可。 高 结束混淆器会有很大帮助，但任何 确定的黑客将修复您的代码 不到一天的时间。 我从 尽管花费了 1000 美元，但还是经历了悲伤的经历 关于反盗版和混淆工具。
然后，它介绍了以下有关在 .NET 中开发商业 Windows Mobile 应用程序的信息：
做好延迟 1 天的准备 你的竞争对手会复制你的 功能并放置自己的应用程序 具有相同的功能 天空市场
对于那些熟悉 .NET 的人来说：这是真的还是无稽之谈？ 此问题是否特定于 Windows Mobile，或者也适用于 Windows 上的 .NET？ 这对我来说似乎很令人惊讶，因为我知道 Microsoft 用 .NET 编写了大量自己的客户端软件（而且许多供应商用 Java 编写昂贵的应用程序，显然也有同样的问题），而且他们的IP很容易被盗。
I came across this post on the MSMobiles.com blog that says the following, among other things:
.Net is great in so many ways but for
commercial apps? No way! Anybody can
just look at your source code. A high
end obfuscator will help a lot but any
determined hacker will fix your code
in less than a day. I know this from
sad experience despite spending $1000s
on anti-piracy and obfuscation tools.
It then says the following about developing commercial Windows Mobile apps in .NET:
be prepared for 1-day delay after
which your competitors will copy your
functionality and place their own apps
with the same functionality in the
Skymarket
For those familiar with .NET: is this truth or nonsense? Is this issue somehow specific to Windows Mobile, or does it apply to .NET on Windows as well? This just seemed surprising to me because I know that Microsoft writes a good amount of its own client-side software in .NET (and that many vendors write expensive apps in Java, which apparently has the same problems), and it seems strange that their IP could be stolen so easily.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我认为这在很大程度上是无意义的，原因很简单，如果你的竞争优势和业务成功取决于代码中的某些算法，那么你已经完蛋了。 成功的应用程序不仅仅是代码，它只是众多部分之一。
如果这是你真正担心的事情，那么我会投资混淆并预付费用一些法律顾问（不管你信不信，价格相当便宜），他们会代表你向你认为窃取了你的代码的竞争对手发送停止和终止信。 虽然这在法律上几乎没有任何进展，但采取行动的威胁却是最有效的工具。
I would argue it is largely non-sense for the simple reason that if your competitive advantage and business success is dependent on some algorithm in your code then you are screwed already. Successful apps are about so much more than just the code, it is one of many pieces.
If this is something you really fear then I would invest in obfuscation and pre-pay for some legal counsel (pretty cheap believe it or not) who will send cease and desist letters on your behalf to a competitor who you believe stole your code. While this is going almost nowhere legally - the threat of action is just about your most effective tool.
关于反编译 .NET 应用程序的容易程度，还是有一定道理的。 （这适用于任何 .NET 应用程序，而不仅仅是在 Windows Mobile 上运行的应用程序。）
使用免费和商业工具相对容易获得已编译的程序集并获取源代码。 （只需看一下 Reflector。）话虽这么说，您可以使用混淆器，它会阻止大多数人，但只会减慢坚定的黑客的速度。
尽管如此，几乎所有语言都有反编译器，如果一家公司（或个人）决心了解您产品的内部结构，无论如何他们都会找到一种方法。
阅读您引用的帖子确实听起来像是由在 Microsoft、.NET 和/或 Windows Mobile 方面有过非常糟糕体验的人所写，并且其中的一些陈述充其量是不正确的。 （特别是这在 iPhone 上不是问题，因为它是用“本机”代码编写的。）
There is some truth in yet around the ease of decompiling a .NET application. (This applies to any .NET application, not just ones running on Windows Mobile.)
It is relatively easy to take a compiled assembly and get the source code using both free and commercial tools. (Simply take a look at Reflector.) That being said, you can use an obfuscator, which will stop the majority of people but will only slow down a determined hacker.
Despite all of that, there are decompilers for almost any language and if a company (or person) is determined to see the internals of your product they will find a way no matter what.
Reading the post you reference really sounds like it was written by someone who had a very bad experience with Microsoft, .NET, and/or Windows Mobile and some of the statements made are incorrect at best. (Particularly the point about this not being a problem on an iPhone because it's written in "native" code.)
虽然使用中间字节码语言可能会稍微容易一些，但事实是您可以使用任何语言来做到这一点。
可执行代码可以轻松地反汇编和浏览。 IDA-Pro 可以加载本机可执行文件，反汇编它们，并且使用 Hex-Rays 插件可以甚至提供类似 C 的伪代码来进行检查。 即使没有 Hex-Rays，单步执行汇编代码并推断发生了什么也不是非常困难。 这就是为许可产品制作注册机的方式。 它们被反汇编，程序员研究负责生成和验证产品密钥的相关汇编代码。
然而，从应用程序中撤消任何主要功能的成本相当高。 因此，除非它是一些涉及商业秘密算法的高度竞争的功能，否则简单地雇用程序员从头开始编写它几乎总是比逆向工程更容易且更具成本效益。
如果您正在寻找更高级别的保护，您可以混淆代码并使用商业加壳器，这使得反汇编程序更具挑战性（并防止在应用程序加壳时使用任何反射器）。 然而，这些可以被规避，解压和混淆的代码根本不会减慢一个好的 RE 的速度。 因此，不要过分强调，在我看来，.NET 与任何其他非字节码语言一样合适。
While it might be slightly easier with intermediate bytecode languages, the fact of the matter is you can do this with any language.
Executable code can be disassembled and gone through with ease. IDA-Pro can load native executables, disassemble them and with the Hex-Rays plugin it can even provide C like pseudo-code to go over. Even without Hex-Rays it isn't terribly difficult to step through the assembly code and deduce what is happening. This is how keygens are made for licensed products. They are disassembled and programmers study the relevant assembly code responsible for generating and verifying the product keys.
However, the cost of reversing any major feature out of an app is pretty high. So unless it is some highly competitive feature that involves trade-secret algorithms it is almost always easier and more cost effective to simply hire programmers to write it from scratch than reverse engineer it.
If you are looking for a higher level of protection you can obfuscate your code and use a commercial packer which makes disassembling the program more challenging (and prevents any reflectors from being used while the application is packed). However, these can be circumvented and unpacked and obfuscated code doesn't really slow down a good RE at all. So, don't stress over it too much, .NET is just as suitable as any other non-bytecode language in my own opinion.
您唯一的选择是拥有一个网络应用程序 - 您只分发查询主服务器的客户端。 这样，努力工作的源泉就是你的秘密。
Your only option is to have a network app - you distribute just clients who query a master server. This way the source that does hard work is your secret.
它也适用于 Windows 上的 .NET。 它也适用于 Java。
你可以对代码进行混淆，有些混淆器很好（你可以通过谷歌轻松找到一个好的混淆器），但最终，你必须警惕保护你的IP，因为混淆器并不是一项完美的技术。 混淆器击败了反编译器，后者变得更聪明，又击败了混淆器，后者变得更聪明，等等。
从技术上讲，您可以通过查看编译后的代码来弄清楚 C++ 程序或任何程序的工作原理。 只是它编译到的级别比 IL（.NET 应用程序编译到的级别）复杂得多。
It applies to .NET on windows as well. It also applies to Java.
You can obfuscate the code, and some of the obfuscators are good (you can easily find a good one through google), but in the end, you will have to be vigilant in protecting your IP, as obfuscators are not a perfect technology. The obfuscators beat the decompilers, which get smarter, and beat the obfuscators, which get smarter, etc, etc.
Technially, you can figure out how a C++ program works, or any program works by looking at the compiled code. It's just that the level it is compiled down to is much more complex than say, IL (which is what .NET apps are compiled to).
去 google 一下 Reflector。 是的，它是真实的，是的，它发生了，是的，你的混淆可以有所帮助，但并不完美。 然后再去反思Reflector本身。 不确定 Redgate 是否仍在混淆它，但原作者使用不可打印的字符来混淆它，这些字符很难处理。
然而，Java 也存在同样的问题，所以请选择你的位置。 哦，一个真正坚定的黑客会破解任何平台上的任何应用程序，因此请选择一个适合其功能且适合您的问题和技能的平台。
使用工具来帮助提高安全性并提高标准。
Go and do a google on Reflector. Yes it is real, yes it happens, and yes you obfuscation can help but is not perfect. And then go and reflect on Reflector itself. Not sure if Redgate is still obfuscating it but the original author obfuscated it using unprintable characters preety nasty to work through.
The same problem exists with Java however, so pick your posion. Ohh and a true determined hacker will crack any application on any platform so pick a platform for its functionality and that is geard to your problem and your skill set.
Use tools to help increase your security and raise your bar.
IL 的好处之一是它可以通过全名完全限定所有类型。 因此，当您查看 Reflector 中的混淆代码时，您可能会在同一个类中拥有十几个具有相同名称的变量，但由于它们在 IL 中是完全限定的，因此运行时对它们没有任何问题。
One of the nice things about IL is that it fully qualifies all types by their full name. So when you look at obfuscated code in, say, Reflector, you could have a dozen variables in the same class with the same name, but since they are fully qualified in the IL the runtime has no problem with them.
阅读 .Net 程序集非常容易。 您可以自己尝试：
http://www.codeproject.com/KB/dotnet/ NetDasm.aspx
http://www.shutterspeaks.com /2006/08/27/how-to-disassemble-net- assembly-files/
有一些混淆器可以使工作变得更加困难。 使用 Mono（.Net 的开源实现），还可以将 .net 代码编译为可执行文件，这应该会使反汇编变得更加困难。
It is very easy to read a .Net assembly. You can try by yourself:
http://www.codeproject.com/KB/dotnet/NetDasm.aspx
http://www.shutterspeaks.com/2006/08/27/how-to-disassemble-net-assembly-files/
There are obfuscators available to make the job harder. With Mono (Open source implementation of .Net), it is also possible to compile .net code into an executable, taht should make disassembly a lot harder.
是的，casper 肯定是对的，你总是可以只看机器代码。 尽管在查看汇编代码级别时很难辨别更复杂的面向对象关系（例如多态性）。
但在我看来，整个保护源代码的心态是有缺陷的。 开源理念是，将代码开放给公众审查有助于使您的软件变得更好，因为更多的人会发现错误和安全缺陷。 此外，Linus 定律正在被越来越多的大公司所接受，例如 Sun、Google、 ETC。
Yes, casper is certainly right, you can always just look at the machine code. Though the more complex object-oriented relationships like polymorphism are hard to discern when looking at the assembly code level.
But in my opinion, the whole protecting source code mentality is flawed. The open source philosophy is that opening up your code to public scrutiny helps make your software better because more people are there finding bugs and security flaws. Also, Linus's law is being embraced by more and more major companies like Sun, Google, etc.
软件的知识产权实际上不仅仅存在于代码本身，还存在于开始生产产品的想法、在开发、测试和部署产品时获得的知识，以及涉及修复、维护和增强产品的基础设施。
拥有应用程序的代码就像拥有一辆汽车一样。 当然，你可以把它拆开，看看它是如何组装在一起的，但是你能因为有了这些知识而在下周开始生产汽车吗？ 几乎不。
Intellectual property of software really isn't just in the code itself, it's in the idea that started to product, the knowledge gained while developing, testing and deploying the product, and the infrastructure involved in fixing, maintaining and enhancing the product.
Having the code to an application is a lot like having a car. Sure, you can take it apart and see exactly how it was put together, but can you start turning out cars next week just because you have that knowledge? Hardly.
我已经有一段时间没有使用它了，但 Salamander.NET 会将 .NET 应用程序转换为 Win32 本机应用程序（没有框架依赖项）。 不确定它是否升级到 .NET 2.0 或更高版本，但早在 2005 年，它就可以在 1.1 中运行。
I have not used it in awhile, but Salamander.NET will convert .NET apps to Win32 native apps (with no framework dependencies). Not sure if it ever got upgraded to .NET 2.0 or higher, but it worked in 1.1 back in 2005.