7

'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.

Community
  • 1
  • 1
JerKimball
  • 16,584
  • 3
  • 43
  • 55
  • Nice to talk to you again. +1 useful question. – Federico Berasategui May 03 '13 at 16:46
  • 1
    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 :( – Earlz May 03 '13 at 17:24
  • Argh, I had a bad feeling about that...thanks for the info @Earlz - and heya HighCore :) – JerKimball May 06 '13 at 15:16

1 Answers1

-2

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.

ezolotko
  • 1,723
  • 1
  • 21
  • 21
  • 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 – Earlz May 06 '13 at 15:12
  • Client requirements are client requirements, unfortunately; that said, I can see the difficulty in obfuscating what is effectively runtime-only behavior. – JerKimball May 06 '13 at 15:18