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 Alzheimer.ca.
Click here to find out why.
Follow @discotekdotca
