Just came across with some android malware that packed with libarm_protect packer.
Here is the manifest of the packed android application.
You can see from the <application> tag, the app will starts with class called arm.StubApp
The StubApp seems like works as a payload unpacker that loads the library arm_protect which is in the folder /lib/armeabi/libarm_protect.so.
Then, we can somehow guess that the packer is in the .so file since you can’t find other classes mentioned in the AndroidManifest.xml (e.g. com.e4a.runtime.android.StartActivity)
Go to the library folder that contains libarm_protect.so , and decompile the library in your favorite decompiler, Ghidra is used in this case.
Check for attachBaseContext function, seems like it will read file ends with .dex from folder /assets . In folder /assets there are 2 encoded binary with .dex extension.
Why attachBaseContext? By referring to this paper.
AttachBaseContext() is the function that packers
usually override to perform these tasks since it is called
by the framework even before
By reading the load bytes function, we can see NOT operation on the loaded bytes. We can try to NOT those bytes and see what happens. After the NOT those bytes, we can see the dex magic header from those decoded .dex files.
After that, we can continue with the payload analysis :)
I think the decoding logic might be vary for different sample as it looks like a custom packer.
Sha256:
c951e7c322530cbd470cc1ba0c103d93fcf3fd3120af53de3dae128d70adfb38
