dex2jar | Tools to work with android .dex and java .class files | Plugin library

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 !

This is the result of Obfuscate progress when app is build. The idea of Obfuscate is Making the code become hard to read, understanding after decompiling. For more information, you should search the keywords Obfuscate

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 ॱ