WPF and obfuscation

Today, confusion remains. NET program, and what is the obfuscation support for WPF applications? Let's go through the examples today.

Start by creating a simple user interface as shown in the following illustration:

Set some binding properties in the interface code:

Define a racial enumeration first in the background code to make it available in the list:

The following properties are defined in the form Window1 class:

The code function at the red circle is to load all the values of the racial enumeration into the race list attribute, so that the enumeration can be used in a consistent, elegant way in the front of the background, which is a good tip.

Next, you hard-code the values of some properties directly in the constructor, and then use yourself as your own DataContext:

Uh ... Play Warcraft friends do not noisy ...

Now that the program is compiled and run, you can see that the data is well reflected in the interface:

OK, then the protagonist, we will take dotfuscator Professional Edition 4.3 evaluation As an example to introduce.

Open Dotfuscator directly after the new project, loading our compiled program, and then directly to confuse and output, run the output after the program:

Well, none of the data shows up.

As far as I understand it, the obfuscation has not yet been able to parse and modify the XAML file, resulting in the confusing background code and the foreground XAML interface description does not match, such as "{Binding race}" statements such as can not be associated with the confused code, so all can not be displayed.

Some confusing mapping results are shown below:

The gray color of the item represents has been removed from the program, all others have a corresponding confusing name.

Now, to make the confusing program work, we have to compromise to the XAML.

The first thing you might think of is to restore some of the interface-related attributes that were removed above, but I tried, that doesn't work.

And as long as the ban on the Window1 class of confusion, the problem is basically resolved:

Looking at the confusing result, it is possible to guess that Dotfuscator is automatically adding the public properties of the class that forbid confusion to the exclusion of confusion, and that these attributes have not been removed this time:

But I still can't explain why the program still does not work when you are only banning confusing attributes and not prohibiting confusing classes.

The problem now is that the list shows the confusing enumeration name, which is fine, as long as you're not confusing all the fields of the enumeration:

Now that the program is completely back to normal, but this is not so much different from the confusing program, look at the confusing program through reflector parsing:

Summary: Confusing technology is already relatively perfect, and now, WPF has brought new challenges, we can only hope that vendors can follow up quickly, so that the WPF program can also be fully protected, for its future wide application to lay the cornerstone.

PDF version of this article download: http://www.box.net/shared/abeeolbk72

Source code Download: Http://www.box.net/shared/uqadhnhsua