| Appendix A. Obfuscation | ||
|---|---|---|
| Prev | Next | |
Table of Contents
This appendix discusses the benefits of obfuscation of yFiles server-side classes in particular, but also obfuscation of byte code in general. Obfuscation as discussed here means name obfuscation.
This appendix only gives a brief overview of obfuscation in general. A comprehensive guide of server-side code obfuscation can be found in Appendix A of the server-side Developer's Guide or the Developer's Guide of the separate yFiles for Java or yFiles.NET distribution.
Generally, byte code (as shipped in Java .class files, .NET assemblies or Flex .swf files) is inherently susceptible to reverse-engineering by simple decompilation. There are several byte code decompilers available that can reproduce source code from given byte code quite accurately.
Performing name obfuscation makes decompiled byte code harder to read, if not unreadable at all.
Apart from the need of protection for Java code in general, a yFiles licensee in particular is bound to the code protection requirements as stated in the license terms: the yFiles license terms explicitly require that all essential class, method, and field names of classes belonging to the yFiles library are obfuscated. The obfuscation's intended purpose, namely prevention of any unauthorized use of the library's functionality via the publicly available yFiles API, is also expressed.
Name obfuscation completely defeats any attempts to access yFiles functionality that is part of an application via publicly available class or method names.
All private and package private yFiles classes, methods, and fields are already name-obfuscated as a factory default, since they cannot be used for software development anyway. The remaining public and protected parts of the yFiles API must be obfuscated before a yFiles-based product can be released.
Obfuscation of the client side code is not required by the license terms. Developers who are interested in protecting their intellectual property, however, should consider obfuscation of their client side code, too.
Name obfuscation works by replacing names in byte code, e.g., package names, class, method, and field names by nonsensical new names. The replacement is done in a consistent way, so that the byte 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, boolean enable){/* Code */}
public void anotherMethod(MyCustomType type){/* Code */}
// Method names/signatures after name obfuscation.
public void a(f b, String c, boolean d){/* Code */} // Formerly 'myMethod'.
public void a(f b){/* Code */} // Formerly 'anotherMethod'.
By replacing different method names with a single new name, decompiled byte 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 Jars, assemblies or .swf files that bundle obfuscated byte code is significantly reduced, too.
|
Copyright ©2007-2015, yWorks GmbH. All rights reserved. |
