c#dll混淆与整个项目混淆

c#dll混淆与整个项目混淆,c#,dll,dotfuscator,C#,Dll,Dotfuscator,对于我的主要软件产品,我创建了一个“keygen”,它显然能够生成密钥并进行验证。这是一个“逻辑”密钥,我不想将其用作web服务(我不想强迫用户通过internet连接来注册软件..)。 出于这些原因,我需要用Dotfuscator之类的东西来混淆它,但如果混淆了,我的项目就会丢失一些很酷的东西,比如与.Net产品捆绑的自动更新(ClickOnce) 然后我的第一个问题是:是否可以将keygen创建为.dll,对其进行模糊处理,并在未模糊处理的软件中使用它 如果是: 我是否能够继续使用Click

对于我的主要软件产品,我创建了一个“keygen”,它显然能够生成密钥并进行验证。这是一个“逻辑”密钥,我不想将其用作web服务(我不想强迫用户通过internet连接来注册软件..)。 出于这些原因,我需要用Dotfuscator之类的东西来混淆它,但如果混淆了,我的项目就会丢失一些很酷的东西,比如与.Net产品捆绑的自动更新(ClickOnce)

然后我的第一个问题是:是否可以将keygen创建为.dll,对其进行模糊处理,并在未模糊处理的软件中使用它

如果是:

  • 我是否能够继续使用ClickOnce和其他非破坏性优势
  • 对单个(和较小的).dll进行模糊处理与对整个项目进行模糊处理相比,是否会使黑客更容易破解keygen
  • 如果否:

  • 对单个(和较小的).dll进行模糊处理与对整个项目进行模糊处理相比,是否会使黑客更容易破解keygen

  • 确切地说,你的种族是什么?非常感谢您的帮助,请原谅我的英语不好:-)

    对于.NET模糊处理的问题是,任何对C#编译成的代码有相当中级理解的人都会发现任何模糊处理都相当容易理解,即使他们无法通过模糊处理,如果内存没有得到适当的保护,他们也可以在整个程序运行过程中监视内存的变化

    任何真正想进入你的课程的人都会。本机应用程序也是如此

    也就是说,如果你想保护自己不受带有反射镜的普通脚本kiddie的影响,那么将keygen编译成dll并单独混淆dll就足以防止有人发现你的密钥生成算法并使用它创建keygen,然而,这仍然让他们有可能修补您的应用程序,这会在一定程度上防止混淆


    总结:如果要防止普通人创建keygen编译并将keygen模糊化为dll,如果要防止keygen和其他人对程序进行修补,请将keygen保留在解决方案中并进行模糊化。

    在模糊化main.exe时,为什么要“松开”ClickOnce支持?您是否尝试过,但失败了?抱歉,是的,可能会失败,但会丢失所有自动功能:页面使用意大利语,但您可以设置“原始语言”以显示英语版本。无论如何,绕过ClickOnce限制,我需要了解更多信息,是最好将keygen代码存储在模糊处理的软件中还是外部模糊处理的.dllIn中。除了回答中所说的内容之外:还要记住,您确实需要再次完全彻底地测试模糊处理的软件。根据我的经验,混淆常常以某种模糊(:p)的方式导致新的bug。这不一定会发生,通常是有效的……有时不会,对客户来说最糟糕的是发现他购买的软件由于“注册问题”而无法工作@Jens这是另一个很棒的问题!如果你这么说,那么我会回到我的决定,我会创建一个.dll模糊,让软件保持清晰。您确定混淆会影响软件的稳定性吗?正如我在网络上读到的,混淆使软件更快,而不是不稳定,但我对此有一个令人生厌的怀疑,你正在证实:-)谢谢,我理解。。我的主要目标是防止创建keygen:我不想将已经售出的代码暴露在一个巨大的黑名单中:-)至于问,你确定一个非常小的.dll,大约有100行代码,在与软件捆绑在一起的成吨行代码前反编译(或者黑客可以做的任何事情)并不容易吗?正如大家所说,这不是尺寸的问题,而是你如何使用它!dll的大小不会影响反射、除臭和修补/窃取的难度,但您使用的混淆和dll的操作肯定会影响。好吧,我理解:这是等效的!现在,由于@peterlillevold发布的问题,我决定混淆整个项目,并将关键验证纳入其中。感谢大家:-)