Joe Security's Blog

You might have already heard about Loapi - the Android malware which will kill your phone due to exhaustive bitcoin mining. Loapi was found by Kaspersky, an excellent write-up can be found here: Jack of all trades.

While Kaspersky's blog post gives a good overview, it does not provide a fine-grained analysis to deeply understand Loapi's behavior. Interesting forensic information, like Loapi's unpacking and obfuscation techniques being left out.

In our opinion, Loapi is one of the first Android trojans which uses multi-stage unpacking and dynamic code loading. Therefore, this blog post is dedicated to explaining how unpacking works and also shortly outlining why Loapi is challenging to be dynamically analyzed - especially through instrumentation approaches.

Layer 1

If we launch Loapi in Joe Sandbox Mobile we get two executed methods:


The more interesting method is attachBaseContext:


The method constructs the DexClassLoader class and contains some very large string. If we browse the code we can indeed see that the long string is decrypted (first base64 decoded) and then stored to a zip file:


The zip file is mapped by the DexClassLoader:


Next method etxtfvw.cqwwrwk.attachBaseContext is called via Java Reflection. Jave Reflection is super cool because it lets you dynamically call method during runtime. During static analysis, it is not clear what method is actually called.



Unfortunately, we do not have any method with that name in the Joe Sandbox report. Why that? Because we first have to understand how static instrumentation works.

Static instrumentation is a method to extract additional runtime information from a program. To achieve that, a program is statically analyzed and new code is added (instrumentation). The purpose of that code is often to log method calls, arguments, class invokes etc. For APK the process looks like this:


To problem with Loapi is that the modified APK is loading new code from itself - to be precise from a string in the APK code. Further, the string is encrypted, then decrypted at runtime and finally loaded. Due to that, no instrumentation takes place and the behavior of that code is fully hidden.

Dynamic Instrumentation

So what can we do? The answer is Dynamic Instrumentation. The instrumentation of the original APK can be done in a way that the newly added code not only logs method calls but also fully controls it. In our case, we can instrument the DexClassLoader constructor call. If it is called we can instrument the DEX code that will be loaded:

So we added a dynamic instrumentation of DEX code. Pretty cool? Yes and, for Loapi this is really a necessity.

Thanks to dynamic instrumentation we can now inspect function etxtfvw.cqwwrwk.attachBaseContext:




We can see an interesting String called /system/framework/XposedBridge.jar and some code to kill the current process. Anti Analysis? You are right. The Xposed Framework is used in CuckooDroid / Cuckoo Sandbox and likely also in some Checkpoint products. Loapi checks the stack trace for method names used by this hooking Framework.

Layer 2

So what is next? After the Anti Analysis check method, YRkfJMV is called:
Let us have a brief look at it:




Another DEX file? Right. This time it is an encrypted file inside the APK resources:



Please note that any API call in method YRkfJMV is done via Reflection. It's important because this is already unpacked / dynamic code. Finally, the newly created DEX file is loaded via reflective constructor call:


From a high-level perspective, the unpacking can be understood as follows:



Any string in the original APK, as well as the stub, are XOR encrypted:

Final Words

Interested in trying Joe Sandbox Mobile? Register for free at Joe Sandbox Cloud Basic or contact us for an in-depth technical demo!

Full Joe Sandbox Analysis Repor of Loapi.