Databinding and code obfuscation

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 solutio开发者_开发技巧n 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?

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 support@preemptive.com . We're always looking for well defined scenarios to improve the product.

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.