Simplify uses a virtual machine to execute an app and understand what it does. Then, it applies optimizations to create code that behaves identically but is easier for a human to understand. It is a generic deobfuscator because it doesn't need any special configuration or code for different types of obfuscation.

There are three parts to the project:

1. smalivm: Creates a context sensitive control flow graph of a method by executing each instruction. The value of all classes and registers is recorded at every execution of every instruction. It doesn't need to know the arguments for a method to execute it as it handles unknown values. Also, it executes every possible path. For example, if an if could be true or false because it references an unknown value, it assumes both could happen and executes both paths.
2. simplify: Takes the graphs from smalivm and applies optimizations such as constant propagation, dead code removal, unreflection, and specific peephole optimizations.
3. demoapp: Contains simple, heavily commented examples of how to use smalivm.

Because this project contains submodules, either clone with --recursive:

git clone --recursive https://github.com/CalebFenton/simplify.git

Or update submodules at any time with:

git submodule update --init --recursive

Then, to build a single jar:

./gradlew fatjar

The Simplify jar will be in simplify/build/libs/simplify.jar

You can test it's working with: java -jar simplify/build/libs/simplify.jar simplify/obfuscated-example

Simplify is in early stages of development. If you encounter a failure, try these recommendations, in order:

1. Include only a few methods or classes with -it.
2. If failure is because of maximum visits exceeded, try using higher --max-address-visits, --max-call-depth, and --max-method-visits.
3. Try with -v or -v 2 and report the issue with the logs.
4. Try again, but do not break eye contact. Simpify can sense fear.

1. If you can, link the APK or DEX. Otherwise post the SHA1.
2. The full command used.
3. Optional: Include verbose logs.

Just submit a pull request. We can talk through it there. I can clean up the style

.method public static test1()I
    .locals 2

    new-instance v0, Ljava/lang/Integer;
    const/4 v1, 0x1
    invoke-direct {v0, v1}, Ljava/lang/Integer;-><init>(I)V

    invoke-virtual {v0}, Ljava/lang/Integer;->intValue()I
    move-result v0

    return v0
.end method

All this does is v0 = 1.

.method public static test1()I
    .locals 2

    new-instance v0, Ljava/lang/Integer;
    const/4 v1, 0x1
    invoke-direct {v0, v1}, Ljava/lang/Integer;-><init>(I)V

    invoke-virtual {v0}, Ljava/lang/Integer;->intValue()I
    const/4 v0, 0x1

    return v0
.end method

The move-result v0 is replaced with const/4 v0, 0x1. This is because there is only one possible return value for intValue()I and the return type can be made a constant. The arguments v0 and v1 are unambiguous and do not change. That is to say, there's a consensus of values for every possible execution path at intValue()I. Other types of values that can be turned into constants:

• numbers - const/4, const/16, etc.
• strings - const-string
• classes - const-class

###After Dead Code Removal

.method public static test1()I
    .locals 2

    const/4 v0, 0x1

    return v0
.end method

Because the code above const/4 v0, 0x1 does not affect state outside of the method (no side-effects) it can be removed without changing behavior. If there was a method call that wrote something to the file system or network, it couldn't be removed because it affects state outside the method. Or if test()I took a mutable argument, such as a LinkedList, any instructions that accessed it couldn't be considered dead.

Some other examples of dead code:

• unreferenced assignments - assigning registers and not using them
• unreached / unreachable instructions - if (false) { dead_code(); }

• Guillot, Yoann, and Alexandre Gazet. "Automatic Binary Deobfuscation." Journal in Computer Virology 6.3 (2010): 261-76