| Appendix A. Obfuscation | ||
|---|---|---|
| Prev | Next | |
Table of Contents
This appendix covers obfuscation of yFiles WPF classes in particular, but also obfuscation of .NET code in general. Obfuscation as discussed here means name obfuscation.
Generally, .NET code shipped in assemblies is inherently susceptible to reverse-engineering by simple decompilation. There are several decompilers available that can reproduce source code from given .NET code quite accurately.
Performing name obfuscation makes decompiled .NET code harder to read, if not unreadable at all.
Name obfuscation works by replacing names in .NET code, e.g., namespace names, class, method, property, and field names by nonsensical new names. The replacement is done in a consistent way, so that the .NET code still works as before.
Example A.1, “Method name obfuscation” conceptually shows the effects of name obfuscation for method names and method signatures. Several methods with distinct signature are mapped to a single new name.
Example A.1. Method name obfuscation
// Original method names/signatures.
public void MyMethod(MyCustomType type, string name, bool enable){/* Code */}
public void AnotherMethod(MyCustomType type){/* Code */}
// Method names/signatures after name obfuscation.
public void a(f b, string c, bool d){/* Code */} // Formerly 'MyMethod'.
public void a(f b){/* Code */} // Formerly 'AnotherMethod'.
By replacing different method names with a single new name, decompiled .NET code is made rather incomprehensible to a human reader, making ad-hoc reverse-engineering attempts difficult. Note that, as a side effect of the obfuscation process, the size of any assemblies that bundle .NET code files is significantly reduced, too.
|
Copyright ©2004-2011, yWorks GmbH. All rights reserved. |
