# A native packer for Android/MoqHao

**[cryptax.medium.com/a-native-packer-for-android-moqhao-6362a8412fe1](https://cryptax.medium.com/a-native-packer-for-android-moqhao-6362a8412fe1)**

@cryptax May 20, 2021

[@cryptax](https://cryptax.medium.com/?source=post_page-----6362a8412fe1--------------------------------)

May 18, 2021


3 min read

_Update May 20, 2021. Added info on Pinterest URLs + Kudos to + actually was discovered_
_on May 12 not May 13._

On May 12, 2021 a new sample of Android/MoqHao (aka XLoader, Wroba) banking trojan
was [detected. There are several changes compared to 2019: new commands,](https://twitter.com/malwrhunterteam/status/1392415481261330444)
communicating CnC URL through malicious Pinterest accounts etc. See below.

sha256: `aad80d2ad20fe318f19b6197b76937bf7177dbb1746b7849dd7f05aab84e6724`

Comparing sample of 2021 (sha256:
aad80d2ad20fe318f19b6197b76937bf7177dbb1746b7849dd7f05aab84e6724 ) with sample
of 2019


-----

This is the part of the malicious payload that processes (malicious) Pinterest accounts to
retrieve information on the CnC. For each targeted bank, the malware searches for the
corresponding package on the smartphone, displays a given Pinterest URL and “hint”
message. See this of .
In this article, we will focus on the packer which is quite interesting because it uses a
**native library + the decryption algorithm has changed (see table above).**

## Decrypting the payload

The malware is packed. The unpacking process consists in processing correctly an
encrypted file in an asset directory named `./whrlrsu . The asset is encrypted with an XOR`
**key, and zipped. The XOR key is memorized in the encrypted file at the 12th byte.**


-----

Payload decryption process
[I implemented a payload decryptor, available on GitHub.](https://github.com/cryptax/misc-code/blob/master/MoqHaoUnpacker.java)

## Preparing dynamic class

Loading dynamic classes is typically done via the `DexClassLoader class, from the Android`
API. To conceal it loads a dynamic class, the malware does not directly call
```
DexClassLoader . Instead, it implements a native library ( libgdx.so ) that calls
DexClassLoader from the native layer.

```

-----

A DexClassLoader object is instantiated by function nd(). This consists in (1) calling
FindClass, (2) searching for a constructor, and (3) using the constructor to create a new
object.
The native library implements the following low level tasks:
```
   Object cr(Class class) : calls create() for the given class ( com.Loader ). This

```
actually instantiates a `Loader object.`
```
   Object lrd(int arg0, Object arg1, String classname, String arg3) : call
   loadClass() on the given class name and return the loaded class object.
   String g(int arg0) : returns a different string depending on the argument. Beware,

```
JEB currently decompiles it incorrectly: you must read the assembly.


-----

If the integer is 0, the routine returns “dalvik.system.DexClassLoader”, for 1 it returns
“com.Loader”, for 2 “()Ljava/lang/Object;” and for 3 “java.util.zip.InflaterInputStream”
In our case, the malware uses the routine with argument 1, so `g() returns “com.Loader”.`
This is provided to `lrd(), so the malware will load a class named` `com.Loader and`
contained in the dynamic DEX. Finally, it locates the method `create() within`
```
com.Loader .

```
There are some other native functions, but they are not used in the next stage. Note that up
to know, the malware does not execute its payload, it only “prepares” things. This is all
```
OmApplication.onCreate() does. Execution is within the next stage.

## Executing the payload

```
The next stage occurs when the main activity is launched. Actually, strangely, the manifest
references 2 main activities: `adlbect.kvActivity and` `adlbect.BnActivity, but`
actually `adlbect.kvActivity does nothing more than calling` `adlbect.BnActivity .`

Silly kvActivity does nothing more than starting BnActivity.

`BnActivity starts the` `WqService` — we’ll discuss it later — and calls native function
```
a.ed() . The method decompiles in JEB quite nicely, and we quickly recognize code to hide

```
an application icon.


-----

Hiding an application icon consists in calling setComponentEnabledSetting method (name is
truncated on the image above) on the PackageManager class, with special flags
PackageManager.COMPONENT_ENABLED_STATE_DISABLED and
PackageManager.DONT_KILL_APP. This is a well known trick to run an app while hiding its
application icon.
As for the WqService, it launches `start() of` `com.Loader — this is how the banking`
**trojan payload actually starts — and sets an alarm in 30 seconds.**

This is onStartCommand() of WqService. This method is automatically called by Android
when the WqService starts. a_set_alarm calls native function a.snc() to set an alarm. I don’t
actually know what it uses this alarm for.
The implementation hardens the reversing because it does not call methods directly but
delegates the work to 2 native functions: `a.start() calls` `com.Loader.start(), and`
```
a.snc() to set the alarm.

```
List of native functions, and their description, in libgdx.so
Kudos to [@MalwareHunterTeam and](https://twitter.com/malwrhunterteam) [@bl4ckh0l3z.](https://twitter.com/bl4ckh0l3z)

— Cryptax


-----