Dotfuscating BAML in WPF application

Question

'Lo again,

My Dotfuscation efforts continue! So I'm currently working on obfuscating a reasonable complicated WPF application consisting of ~38 assemblies. Now that I've overcome my performance issues (Speeding up obfuscation process), I've now moved on to testing out the BAML obfuscation capabilities of Dotfuscator v4.10.

Trouble is, it ain't working - the errors (well, warnings) that are generated are all of the same form, for which I can find nothing on the 'net that discusses:

BamlAnalysis flagged something in Data Binding Path: SOMEFIELDNAME in 
SOMERESOURCEPATHTOBAML.baml for the following reasons: 
Could not resolve, may have to manually exclude.

Anyone come across this and have any insight what the heck it wants me to change?

[EDIT:] Even setting up manual excludes on the properties its complaining about does not remove the warning...and it doesn't appear as if the underlying BAML is altered at all (at least not by visual check via reflector).

[EDIT2:] Also, should state that Dotfuscator is a requirement here, so alternative tools probably won't help me.

Kutz

Nice to talk to you again. +1 useful question. – Precarious

unfortunately, these warnings don't go away after excluding. The problem is basically things like "we see a property named Foo... but we have no idea what class it belongs to". So, we issue a warning about it, but it's very difficult to know that you also excluded it properly... so there is no way to get rid of warnings :( – Alexandro

Argh, I had a bad feeling about that...thanks for the info @Alexandro - and heya HighCore :) – Kutz

Answer 1

You can try using the latest version of Eazfuscator.NET to obfuscate complex WPF applications. XAML renaming is powered by a perfect analyzer which takes bindings, commands and every other aspect of XAML into account to deliver the precise results.

Dawson

There are cases where "perfect" is impossible, even with dynamic analysis. Data binding is particularly hard because the DataContext can change to be any object at anytime. I won't argue if Eazfuscator is better or worse, because I'll obviously be biased, but the word "perfect" is probably not appropriate here – Alexandro

Client requirements are client requirements, unfortunately; that said, I can see the difficulty in obfuscating what is effectively runtime-only behavior. – Kutz