Obfuscator which supports WPF properly

What options exist for a good obfuscator tool for .NET which 开发者_如何转开发propertly support WPF in .NET 4.0?

In particular, which obfuscation tools handle rewriting of BAML within WPF assemblies, and handle cross-assembly references within BAML?

While most obfuscators list "WPF" and ".NET 3.5" or ".NET 4" support, in practice, they fail to rewrite the embedded BAML references, causing cross-assembly calls using WPF to be handled improperly. This prevents their usage in large-scale WPF applications.

---

Eazfuscator.NET does a proper WPF renaming since version 3.5. We put extensive R&D efforts to create a solution that just works. XAML renaming is powered by a dedicated analyzer that takes bindings, commands and every other aspect of XAML into account to deliver the precise results. You can give it a try.

---

Disclaimer: I work for PreEmptive Solutions (the makers of Dotfuscator).

If you tried Dotfuscator a while back you should probably give it another try. We are constantly improving our XAML/BAML parsing & rewriting capabilities. You should be able to get a new free evaluation version easily from the PreEmptive website (or by contacting sales).

Most of our customers are able to obfuscate the majority of their WPF/Silverlight/WP7 applications without significant exclusions. Even if the BAML obfuscation breaks something in your application you should be able to selectively exclude only those items than should not be renamed.

If you do have a specific scenario of something that we break during obfuscation please go ahead and send it in, we're always looking to make our product better.

At this time the only other .NET obfuscator (that I know of) that claims to be able to modify XAML or BAML is CodeFort. I am obviously biased so I'll let you investigate the products and make your own judgment :)

---

Well WPF depends heavily on Reflection and changing your property names may not work correctly as binding will not function correctly. Obfuscator tools will not detect string references in code that may be there inside your ViewModel and so on. And whatever you do. Tools like Blend can anyway create copy of templates and styles from BAML and that is the reason BAML was introduced instead of creating executable code from xaml.

And as it is BAML is just a graphical representation, at runtime people can also use Snoop tools to identify your runtime view of controls.

However, there is a free tool which generates WPF code behind file as a pure CLR object graph representation instead of BAML, http://xamlgenerator.codeplex.com/ (Disclaimer: this xamlgenerator is free tool created by my company)

---

ConfuserEx is as an Open Source obfuscator which does pretty good job making code very difficult to follow.

If WPF exe doesn't work properly after using one of the presets, try adding protections manually (I found that in my case 'Name Protection' (rename) was breaking event handling):

---

I tried CodeFort in a multi-assembly Silverlight 4 application with partial success. Reference scrambling and string encryption work great and bring some degree of protection.

Renaming feature in CodeFort is a big mess though. Enabling renaming (with XAML support) in all my assemblies broke the application. I tried then to exclude all types (including all members) from renaming, which was very time consuming due to bad UX. That didn't bring the app to life.

Debugging and troubleshooting doesn't work well either. CodeFort doesn't respect PDB files. The only way to debug the problem was to enable debugger to break upon all thrown exceptions. Now I see the XAML parser complaining about app.xaml, which looks OK.

As for now I just stick to reference scrambling and string encryption.

---

In our company we use Agile.NET Obfuscator - it supports WPF application and can protect/encrypt managed resources including BAML files.

Decompiling using ILSpy:

Before (with only code encryption)

After (with Resource encryption)