Data binding and code obfuscation

Question

My employer uses Dotfuscator on all of our .Net software products. Because of this, we are absolutely forbidden to use ANY built-in data bindings or anything that reflects the names of properties / functions, because dotfuscator changes them and, therefore, something breaks instantly and urgently.

I keep retelling this logic in my mind and it starts to hurt. There must be a way to avoid this impasse, it is too broad and fundamental a problem to not have an obvious solution that has eluded us.

So how to do Reflection with Obfuscation? What trick? Presumably, there should be commercial obfuscators that are smart enough to get around the problem. What are the options for our version (which is pretty stupid)?

Answer 1

We made a number of improvements for Dotfuscator that should help alleviate data binding issues. Smart Obfuscation functionality was added in version 4.3.100 in March 2008 to statically analyze assemblies and automatically exclude items from renaming / deleting that are known to cause runtime errors. We are consistently expanding and improving this functionality, and today Dotfuscator works with standard data binding scripts, usually with minimal additional configuration.

Even if Smart Obfuscation doesn’t catch each of your scripts, it’s very easy to define custom rules to exclude properties of certain types or inheritance hierarchies using custom exclusion rules (including the corresponding types from RegEx templates). You can also decorate elements with the System.Reflection.ObfuscationAttribute attribute to ensure that they are excluded from renaming or deletion at startup through Dotfuscator.

If you are tied from XAML markup to code types, the last few releases support XAML / BAML renaming to match the code. This improves overall hardening and also eliminates a number of problems when the characters in the markup do not match the code definitions.

I would recommend developing some simple proofs of conceptual applications using data binding similar to what you want to use in your applications and running them through Dotfuscator to see how well they handle them. If you find any scenarios in which Smart Obfuscation will not automatically exclude data binding targets, send them to [e-mail]. We are always looking for clearly defined scenarios to improve the product.

Answer 2

It is the obfuscator's job to break down the relationships that are visible in the source code so that they no longer appear in the resulting executable code. Reflection depends on relationships such as "the property requested by this piece of code, which is determined by this piece of code." Therefore, it is not surprising that obfuscation and reflection are not well combined with each other.

Renaming properties is only a zero level of obfuscation. A non-trivial obfuscator will also do things like splitting a property into two, so when the source code only mentions the P property, part of the runtime code will use P1, and part of the runtime code will use P2, and there will be enough assignments between them to properties had the right value when necessary, but also spurious assignments so that they did not have the right value when they are not needed. It is not only that P has been renamed: there is no longer a property P.

I don’t know why you think that reflection plus obfuscation is “large-scale and fundamental”: both reflection and obfuscation are quite rare in the great programming scheme, and there is no correlation between their use, I think that many people try to have both.

Lack of reflection is just one element in a long list of things that obfuscation costs you. If the person who decided to use obfuscation is not a protective maven, try to hammer it in them, that obfuscation has a very high cost, which they probably underestimated.