数据绑定和代码混淆
我的雇主在我们所有的 .Net 生产软件上使用 Dotfuscator。因此，我们绝对禁止使用任何内置数据绑定或任何反映属性/函数名称的内容 - 因为 dotfuscator 会更改它们，因此任何绑定都会立即且不可挽回地中断。
我不断地在脑海中盘旋这个逻辑，它开始让人受伤。 必须有一种方法可以避免这种僵局，这是一个范围太广、太根本的问题，我们不可能没有一个明显的解决方案。
那么，如何进行反射与混淆呢？有什么窍门呢？据推测，必须有足够智能的商业混淆器来解决这个问题。我们的版本有哪些选项？
My employer uses Dotfuscator on all our .Net production software. Because of this, we are absolutely forbidden to use ANY built-in databinding or anything that reflects on property/function names - because dotfuscator changes them and therefore anything bound instantly and irredeemably breaks.
I keep rolling this logic over in my mind and it's starting to hurt. There must be a way of avoiding this deadlock, it's too wide-ranging and fundamental a problem to not have an obvious solution that has escaped us.
So, how does one do Reflection with Obfuscation? What's the trick? Presumably there must be commercial obfuscators which are intelligent enough to work around the problem. What are the options for our version?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我们对 Dotfuscator 进行了许多改进，这应该有助于缓解与数据绑定相关的问题。 2008 年 3 月的 4.3.100 版本中添加了智能混淆功能，用于静态分析程序集并自动从重命名/删除中排除已知会导致运行时错误的项目。我们不断扩展和增强此功能，今天的 Dotfuscator 围绕标准数据绑定场景工作，通常不需要或最少的额外配置。
即使智能混淆不能捕获所有场景，也可以非常轻松地定义自定义规则，通过使用自定义排除规则（包括通过正则表达式模式匹配类型）来排除某些类型或继承层次结构的属性。您还可以使用 System.Reflection.ObfuscationAttribute< 来装饰项目/a> 属性，以确保在通过 Dotfuscator 运行时将它们排除在重命名或删除之外。
如果您从 XAML 标记绑定到代码隐藏中的类型，则最近几个版本支持重命名 XAML/BAML 以匹配隐藏的代码。这改进了整体强化，并且还消除了标记中的符号与代码定义不匹配时出现的一系列问题。
我建议使用与您想要在应用程序中使用的数据绑定类似的数据绑定来开发一些简单的概念验证应用程序，并通过 Dotfuscator 运行这些应用程序以查看其处理它们的效果。如果您发现智能混淆不会自动排除数据绑定目标的任何情况，请将其发送至 [电子邮件受保护]。我们一直在寻找明确的场景来改进产品。
We have made a number of improvements to Dotfuscator that should help alleviate issues related to databinding. Smart Obfuscation functionality was added in the 4.3.100 version in March 2008 to statically analyze assemblies and automatically exclude items from renaming/removal that are known to cause runtime errors. We have consistently expanded and enhanced this functionality and today's Dotfuscator works around standard data binding scenarios with usually no to minimal extra configuration.
Even if Smart Obfuscation does not catch every one of your scenarios it is very easy to define custom rules to exclude properties of certain types or inheritance hierarchies by using custom exclusion rules (including matching types by RegEx patterns). You can also decorate items with the System.Reflection.ObfuscationAttribute attribute to ensure that they will be excluded from renaming or removal when run through Dotfuscator.
If you are binding from XAML markup to types in codebehind the last few releases have supported renaming the XAML/BAML to match the code behind. This improves overall hardening and also eliminates an entire range of issues when symbols in the markup do not match the code definitions.
I would recommend working up a few simple proof of concept applications using databinding similar to what you want to use in your applications and running those through Dotfuscator to see how well it handles them. If you find any scenarios where Smart Obfuscation is not automatically excluding targets of data binding send them on to [email protected] . We're always looking for well defined scenarios to improve the product.
混淆器的工作是分解源代码中可见的关系，以便它们在生成的可执行代码中不再明显。反射依赖于诸如“这段代码请求的属性是该段代码定义的属性”之类的关系。因此，混淆和反射不能很好地配合也就不足为奇了。
重命名属性只是零度混淆。一个不平凡的混淆器还会做一些事情，比如将一个属性分成两部分，这样在源代码只提到属性 P 的情况下，一些运行时代码将使用 P1，一些运行时代码将使用 P2，这样就有足够的它们之间的赋值，以便属性在需要时具有正确的值，但也有寄生赋值，以便它们在不需要时不会具有正确的值。不仅仅是 P 被重命名了：不再有属性 P。
我不知道为什么你认为反射加混淆是“广泛且基本的”：反射和混淆都是在宏大的编程方案中相当罕见，并且它们的使用之间没有相关性，所以我认为没有多少人试图同时拥有两者。
缺乏反思只是一长串让你付出代价的事情中的一项。如果决定使用混淆的人不是安全专家，请尝试向他们灌输混淆的成本非常高，而他们肯定低估了这种成本。
It's the job of an obfuscator to break down relationships that are visible in the source code so that they are no longer apparent in the resulting executable code. Reflection relies on relationships such as “the property requested by this piece of code is the one defined by that piece of code”. So it's not surprising that obfuscation and reflection don't play well with each other.
Renaming properties is just degree zero of obfuscation. A nontrivial obfuscator will also do things like split a property in two, so that where the source code only mentions a property P, some of the runtime code will use P1, and some of the runtime code will use P2, and there will be enough assignments between them so that the properties have the right value when needed, but also parasitic assignments so that they won't have the right value when they're not needed. It's not just that P has been renamed: there no longer is a property P.
I don't know why you think that reflection plus obfuscation is “wide-ranging and fundamental”: both reflection and obfuscation are fairly rare in the grand scheme of programming, and there's no correlation between their use, so I don't think many people are trying to have both.
The lack of reflection to be just one item in the long list of things that obfuscation costs you. If the person who decided to use obfuscation is not a security maven, try to hammer it into them that obfuscation has a very high cost which they are sure to have underevaluated.