Reverse engineering android native packer

Question

im trying to Reverse engineering an android app and the app have 4 folders in the /data/data/{package} folder

├───app_dexprotector
│       823517D25836B88F1C499C02370A047E.dat
│       823517D25836B88F1C499C02370A047E.dex
│
├───app_outdex
│       libdexprotector.bpqn57.12456.so
│
├───cache
└───lib
        libiconv.so
        libzbarjni.so

and all the files are the same except app_outdex file and when I start the app app_dexprotector folder will be modified after that a file will create on app_outdex then will delete immediately I create a copy of that file with Termux and inotify-wait and the interesting part is always the size of the file is different i searched the java code of the app and there is only an application class with a huge bytecode array and one native method like this :

public static native int tfAHDD(Object obj, int I, int i2, int i3, int i4, int i5, int i6, int i7, int i8);

the whole class is so long but it's only because of the byte array this is the link of the class my main questions are why the file has different sizes every time and why there are not other native methods? how the app will run this method and finally how can I analysis this .so file

Princekin · Answer

You can't analyze native functions with a standard decompiler because native functions are not implemented in the Java Bytecode (The Java Native Keyword and Methods).
You have to use common x86 disassemblers (Like IDA, JEB) to analyze the native functions.
At first, search for System.loadLibrary calls, to see which native library gets loaded (should be in a static block)
Once you found the native library you have to open it with a disassembler like IDA and go in Exports section:

Here you can see the implementation of your native functions.
Of couse you cannot expect java bytecode here, but only C pseudocode (if your disassebler supports it)

Reverse engineering android native packer

One Answer

Add your own answers!

Ask a Question