jd-gui | A standalone Java Decompiler GUI

I have been trying to obfuscate a jar file to protect it from retrieving the original source code.

Obfuscation in Intellij requires IntelliGuard 2 plugin and yuguard 3.0.0 (preferably yguard-bundle-3.0.0.zip).

The obfuscation process :

1. Generate Module out of the project: File --> project settings --> Modules ( + new module and set proper out path)

2. Generate jar file using Artifacts: File --> project settings --> Artifacts ( + JAR and naming configuration)

3. Generate Ant build

4. Obfuscate the jar file: File --> project settings --> Facets( + Obfuscation ), then choose the path to ygurad-bundle/lib/yuguard.jar, and choose the main class. See illustrating image below:

Afterward, build Artifacts (build--> build Artifacts), then Obfuscate the jar file ( build--> obfuscate jar, then choose the input jar and the output obfuscated jar).

I couldn't find another way or resource to follow and do it the easy way, so I decided to share my experience.

While reserved words may not occur in Java source code, they are permitted in compiled Java code. Some code obfuscation tools can make use of this to make decompiling harder. For instance, ProGuard provides the following option:

-obfuscationdictionary filename

Specifies a text file from which all valid words are used as obfuscated field and method names. By default, short names like 'a', 'b', etc. are used as obfuscated names. With an obfuscation dictionary, you can specify a list of reserved key words, or identifiers with foreign characters, for instance. White space, punctuation characters, duplicate words, and comments after a# sign are ignored. Note that an obfuscation dictionary hardly improves the obfuscation. Decent compilers can automatically replace them, and the effect can fairly simply be undone by obfuscating again with simpler names. The most useful application is specifying strings that are typically already present in class files (such as 'Code'), thus reducing the class file sizes just a little bit more. Only applicable when obfuscating.

So if you feed this a list with Java identifiers (such as this one) you end up with a class file that causes syntax errors if decompiled. Of course, you can simply rename the variables to fix these compilation errors (for instance by using ProGuard yourself before decompiling), so this is only a minor inconvenience.

There is no difference in what ProGuard does between these two methods.

The difference is in the tool you're using to read ProGuard's output: what bytecode it can and can't decompile to make it look like normal Java source.

Answer to question 1:

I found that multiple .apk were installed for the game. My error was to trust the app Apk Extractor that gave me only the base .apk

I connect through SSH to my phone and list all the .apk installed. Several .apk were installed in the /data/app/ folder of my game !

• One was dedicated to the base source code (the one i got from Apk Extractor)
• One .apk that store only the native libraries (libMain.so)

Answer to question 2:

I used the command readelf -s libMain.so | grep ' to retrieve the function address. The output was something like that 00000000003c69b4

readelf -h libMain.so : gave me the architecture in which the library has been built aka AArch64.

I downloaded the same toolchain that has been used to compile the binary:
$> sudo apt-get install binutils-aarch64-linux-gnu

And then used it with this command:
$> aarch64-linux-gnu-objdump -d libMain.so --start-address=0x3c69b4
The start-adress value is set with the return value of the first command

And now i have assembly code that i need to reverse engineer !

Why is this happening?

It is happening because the decompiler is not able to figure out Java source code that will compile to equivalent bytecodes.

The task for a decompiler is difficult. When the compiler compiles Java source code to bytecodes, a lot of information is thrown away. It is not just the obvious stuff like comments, indentation and local variable names. It is also the particular choices that were made about control structures. In addition, there are various situations where the compiler has to insert synthetic methods or fields.

A decompiler has to do two sometimes contradictory things:

• It has to produce readable code.
• It has to produce code that is (hopefully) compilable and that (hopefully) means the same thing as the bytecodes.

Unfortunately, decompilers don't always get it right. Practical decompilation is heuristic, and the heuristics are not perfect.

Obfuscators make it even harder. Deliberately.

The corollary is that you should not be using decompilation and recompilation in your software development processes.

The best approach is to get hold of the original source code for the JAR you are trying to understand and modify.

Only use decompilation to help you understand other peoples' code if you have no alternative. (For a start, it could well be a license violation. Check to see if the software license forbids reverse engineering, etcetera.)

If you really need to modify bytecodes, use a bytecode disassembler ... and learn to read and edit the Java assembly language.

This call in Java:
.\u0971("www.google.com", new String[] {"sha256/asdIa1tHg96AnzarJ6GJLu6JiogJla3UDsPWMDICs=" })
is found in smali at:
invoke-virtual {v1, v2, v3}, Lo/bdq$if;->ॱ(Ljava/lang/String;[Ljava/lang/String;)Lo/bdq$if;

The Java class is o.bdq$if (class if is nested inside o.bdq). The method name is ॱ

So, after a bit of struggle, I found a solution to my issue. Firstly, I added a of "provided" (link to docs) to the dependencies I wanted out of the lib folder :