c# - 保护我的代码免受逆向工程

标签 c# obfuscation reverse-engineering

如类似问题中所述herehere我想保护我的代码免受逆向工程。

我的情况是Simucal在他的(优秀)回答中描述 here :

Basically, what it comes down to is the only chance you have of being targeted for source theft is if you have some very specific, hard to engineer, algorithm related to your domain that gives you a leg up on your competition. This is just about the only time it would be cost-effective to attempt to reverse engineer a small portion of your application.

我正好遇到这种情况。一种难以设计的算法,对我们的特定领域来说是优雅且有值(value)的。

经过几个月的微调和开发,最终结果非常紧凑(大约 100 行代码)和优雅。我想保护代码的这个特定部分免受逆向工程的影响,或者至少让它变得合理困难。

该场景是一个用 C# 编写的富客户端应用程序,我必须部署这部分代码 - 我无法从网络服务执行它。

我认为,出于性能原因(和跨界问题),提取代码并在非托管 native 二进制文件中重写它不是一种选择。

最初我想做简单的混淆,但考虑到代码量很小,我认为这不会提供太多保护。

理想情况下,我想保护我的整个应用程序,但有两个主要问题似乎使普通混淆器和第 3 方打包器难以使用:

  1. 应用程序提供了一个插件接口(interface),因此不应混淆和打包一些程序集(和接口(interface)/类)

  2. 我们仍然希望在收到错误报告时能够获得真实的堆栈跟踪 - 可能这可以通过我对真实代码的映射混淆来完成。

将这些问题搁置一旁(尽管我也希望对此提出任何意见),保护我的一小部分代码免受逆向工程影响的好方法是什么?我不担心任何人更改或破解代码,但想让它变得难以理解和逆向工程。

最佳答案

这是不可能的。如果您的代码可以运行,那么它就可以被读取和逆向工程。你所能做的就是让它变得更难一点,相信我,它只会更难一点。你可能不喜欢这个事实,但大多数破解者在破解方面比其他任何人都更擅长让事情变得难以破解。为保护您的代码付出的努力通常是不值得的,尤其是当它对您的付费客户不利时。见证 DRM 的惊人失败。

我的建议是不要担心。如果你的算法真的很新颖,那就申请专利(尽管 Bilski 的决定让这变得有点困难,除非你将它与特定的硬件实现联系起来)。依赖商业 secret 也是无用的,除非您只将您的软件分发给那些签署契约(Contract)以确保他们不会允许不受限制的访问的人。然后,你必须有办法对此进行监管。一旦您将二进制文件发布到互联网上或在没有契约(Contract)的情况下分发它们,我相信您将被视为失去商业 secret 身份。

依赖许可也充满危险 - 您可能认为您可以在许可中插入禁止逆向工程的条款,但世界上许多司法管辖区明确禁止这些条款。无论如何,对大部分破解负责的俄罗斯黑帮都不太可能遵守上述规定。

您为什么不专注于使您的产品达到最佳状态呢?目标是保持领先于人群,而不是将他们完全拒之门外。在竞争激烈的群体中率先交付并始终拥有最好的产品,远比将大量精力浪费在无用的保护上更能确保您的繁荣(恕我直言)。

这只是我的看法。我可能是错的。我以前就错了,你只需要问我的妻子:-)

关于c# - 保护我的代码免受逆向工程,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/584828/

相关文章:

c# - 如何在 viewmodel 中访问 mvvm 模型中的控件?

c# - 在 xaml 中编写嵌套类型时出现设计时错误

obfuscation - 有没有像JavaScript的小工具(deobfuscator)这样的东西?

c - 从汇编代码和骨架 C 导出数组的大小

c# - WPF TreeView 中的 "Link"项

c# - ASP.NET 中的倒计时

c - IOCCC 1984/decot.c - 可以在 21 世纪编译吗?

obfuscation - 小型供应商的软件保护

c++ - 裸函数原型(prototype)声明

c# - 将委托(delegate)转换为表达式树