Modifly Allatori Dasho Zelix KlassMaster Proguard YGuard
Name Obfuscation
Flow Obfuscation
Debug Info Obfuscation
String Encryption/Obfuscation
Incremental Obfuscation
Stack Trace Utility
J2ME Obfuscation
Android Obfuscation
GUI Interface
Java Build Tool Interface
Tamper Detection
Shelf Life
Error Report & Usage Statistics
Runtime Transformations
Reflection Protection
Reorder Members
Post-processing of Server Jars
Suggest Exclusions
Price $200.0 / $2000.0 USD / Year $290 USD ~$1000-2000 USD Standard: $479 USD
Small Developer: $239 USD
Free Free
License Commercial Commercial Commercial GPL (Open Source) GPL (Open Source) Proprietary (Open Source)
Charitable Contribution

The removal of symantics from class, field, and method identifiers. For instance, class SecretFormula might be transformed to class a. Modifly takes advantage of discrepancies between the Java Language Specification and the Java Virtural Machine Specification by optionally converting identifiers to control characters. Control characters are not legal in the Java Language Specification, which presents a substantial challenge for decompilers. Furthermore, control characters are not valid file system characters, which complicates extracting such classes from a jar for decompilation.
The manipulation of bytecode instructions such that they have the same functional meaning, but cannot be easily be represented by source code constrained by the Java Language Specification. Modifly does not provide this type of protection explicitly. However, Modifly's "Reflection Protection" feature will mangle code such that it cannot be easily represented in Java source code.
The obfuscation of debug information, which includes variable names, line numbers, and Java source code file names. Debug information provides an enormous amount of information to an attacker. Modifly provides the option of removing it, which makes supporting your application harder (consider stack traces with no line numbers) or obfuscating it. An obfuscated stack trace can only be reversed by Modifly as long as a conversion log file is generated.
String literals are a common part of Java code and can be a strong indicator of a class's purpose. A decompiler can easily convert a String literal in bytecode to its original form in Java source code. String Encryption/Obfuscation is the process converting bytecode such that its String literals are only in their original form at run time. Some obfuscators claim their techniques are stronger than others, but ultimately, no String encryption/obfuscation will stop a knowledgeable and determined attacker. This type of obfuscation is more suited to deterring a less skilled attacker.
Generally, optimize obfuscation can be considering a marketing gimic. If optimize is important to you, first read the optimize documentation of each of your obfuscator candidates. Almost invariably, "optimize" boils down to decreasing the code size by shrinking class, field, and method names, but true optimization should speak to actual performance metrics. This understanding seems to be pervasive in the industry, so all the obfuscators in this grid have been granted a check mark. It appears that DashO does some real bytecode optimization, however, you should be aware that modern JVMs will perform optimziation at runtime, which may prove to be just as effective performance-wise. Once again, if this is important to you, you should research optimizaton empirically before spending money, potentially for little gain.
Adding artifacts to bytecode to ascribe ownership or origin. Modifly uses a unique method of adding watermarks to bytecode, which is specifically designed to sustain against transformation (changing class, field, and method names) and optimization (removing superfluous instructions) attacks. Also noteworthy, Allatori and DashO did not receive favourable reviews in a recent (2011) watermark resilience evaluation publish in the the International Journal of Computer Science, "An Evaluation of the Resilience of Static Java Bytecode Watermarks Against Distortive Attacks".
The ability to transform bytecode constructs consistently despite changes to the bytecode. Incremental Obfuscation allows you to maintain backward compatibility from one release of your product to the next and is generally accomplished by using the recorded conversions of one run as input to the next.
A tool to ease the conversion of an obfuscated stack trace to the form it would have if the bytecode had been generated from the original (non-obfuscated) bytecode.
The ability to protect your bytecode from transformation that might inadvertantly corrupt a J2ME application. Modifly does not provide this functionality explicitly, but can be configured to do so manually.
The ability to protect your bytecode from transformation that might inadvertantly corrupt a Android application. Modifly does not provide this functionality explicitly, but can be configured to do so manually.
The conversion of bytecode such that its reflection code will not be corrupted by name transformations. For example, the code Class.forName("com.example.MyExample") would get corrupted if the class com.example.MyExample were to converted name-wise to a.b. Using this example, Auto-Reflection would convert the bytecode for Class.forName("com.example.MyExample") to Class.forName("a.b"). You should note that Modifly will only correct class references in reflective code. It will not correct references to fields or methods. It is unknown if other obfuscators do this, but it is unlikely.
The ability to identify and/or eliminate unreachable code. Most obfuscators will identify unreachable code given an entry point. Modifly uses a different approach. It does not require a starting point. It will analyze all classes and separate it into mutually exclusive groups. If all of your code is reachable, there will be only one group.
Provision of a Graphical User Interface to ease the configuration and support of your obfuscated products.
Provision of an interface which integrates with common build tools like ANT, Maven, or Gradle.
The ability to identify if your application has been modified from its distributed form at run time.
The ability to insert expiry dates into an application to prevent use after a given date. Technically, this is not obfuscation, but is the sort of functionality that obfuscator authors can integrate fairly easily. Modifly may have this feature in the future.
The ability to report unexpected problems and generate feedback about an applications usage. This is far outside the domain of obfuscation, but is the sort of functionalit that obfuscator authors can integrate. Depending on the reporting mechanism, it can add a significant amount of complexity to an application. The usefulness of this feature has not been evaluated for Modifly at this time.
The ability to obfuscation transformations to application bytecode at runtime. This is the main feature that set Modifly apart from all other obfuscators. Runtime transformations potentially eliminate the possibility of modifying application behaviour (especially when combined with tamper detection).
The ability to convert bytecode to its reflection equivalent. This is particularly useful when combined with String encryption. This sort of obfuscation is particularly useful for hiding calls to integration points such as Java's core runtime library. For instance, an attacker could easily track down integration points such as System.exit(int) or Runtime.getInstance().exec(...). When these methods are converted to their reflection equivalent and their String parameters are masked by String obfuscation, they are simply unrecognizable.
This feature re-orders the fields and methods of a class. Some applications have clients that can be downloaded each time they are run. Applets and WebStart clients are examples. Such deployments can be re-obfuscated periodically to complicate an attacker's attempts at integration. Such a technique can be overcome by a "template" attack, where reflection is used to recognize the basic structure of various classes, despite changing class, field, and method names. Re-ordering members of a class reduces the likelihood that an attacker can create a template.
For projects that have a client and server who communicate via value objects, if a value object class is obfuscated, it will no longer be able to communicate with the server. A simple solution would be to exclude value objects from obfuscation. However, leaving value objects un-obfuscated would provide much insight to an attacker. A safer solution would be to obfuscate both the client and server side value object classes. It should be noted that should a stack trace be generated on the server end which includes obfuscated value objects, the stack trace utility can provide the original stack trace (assuming a conversion file was generated).
Manually configuring an obfuscator to exclude various classes or class constructs can be a daunting task and depending on the complexity of the project, it can be error prone. An obfuscator can provide suggestions to common exclusions that are recognized in the bytecode.
A "de-obfuscator" is a tool that attempts to convert an application's bytecode into a state that is more easily analyzed and decompiled. For instance, an application whose class names are converted to control characters cannot even be extracted from a jar. A de-obfuscator can give you an idea of how vulnerable your application is to an attack.
Discotek contributes 20% of all Modifly orders to Click here to find out why.