PoisonCake In the ROM(English Version)

By | 2014年12月26日

Post by baronpan


AVL Team & LBE discovered a new backdoor in an infected mobile phone. It is an executable ELF file, and we believed it is part of new variant of “FakeDebuggerd.C”[1]. Because this ELF can execute directly without others, and also performs comprehensive mal-behaviors, so we name it along. The malware author calls it a cake, so we named this backdoor “PoisonCake”.

PoisonCake can setup itself, decrypt and drop other payloads, create background services, and is able to perform these malicious behaviors:

1.Inject com.android.phone, send and intercept SMS.

2.Send premium SMS or visit WAP site.

3.Collect phone info, upload to remote server.

4.Able to download files.

5.Able to update itself.

PoisonCake is complex. It has an explicit and extensible structure. It also uses sort of ways to make itself harder to discovered, detected and cleaned.

Malware workflow and behavior

PoisonCake separates to three parts: initialization, core framework and plugins.

dm is the initialization executable file, which is an ELF, performing setup and environment initialization. It drops reactore.dex.jar and runs it in main thread, and also creates a monitor thread for watching main thread.

reactore.dex.jar is the core framework, which declares basic interfaces, implements core services, decrypts and releases plugins, and finally stays in a loop, waiting for new events and commands.

The final part of PoisonCake is plugins. PoisonCake contains 8 plugins to support its extensibility. Each plugin performs a different job. For example, one of the plugins named bean, it supports code injection. It will inject libblackbean.so and redbean.dex.jar to com.android.phone. The injected part will listen on port 10023 and accept commands.

Base on the eight plugins, PoisonCake is able to do these malicious behaviors:

1.Send and intercept SMS.

2.Network management, especially for APN.

3.Phone info collections, including IMEI, IMSI, phone number etc.

4.Support heartbeat connection to keep online.

5.Send premium SMS or visit WAP site.

6.Upload and Download, post records to remote server.

7.Support self-update.

PoisonCake workflow graph below: 1

Analysis of PoisonCake Malware

Malware related files and relations

During the execution, PoisonCake will create some directories and temporary files. It also releases payloads and plugins, but will delete them immediately for prevent detection.

File created by PoisonCake:


Directories created:




Temporary files created:





Log and record files created: /mnt/sdcard/sysv/lv

/mnt/sdcard/sysv/lg1 /data/usr/honey

Initialization malicious executable

dm performs setup and initialization of PoisonCake. It accepts parameter “–setup”. It encrypts all strings to defeat static analysis. dm will execute these in a particular order:

1) Decrypt sensitive information to string array in memory.

2) Check /data/.dmtjjexit exist or not, if exist, process exit.

3) Process environment setting, change process name to jworker/0I:2H:1J.

4) Copy itself to /data/.3q/dm, create directory /data/usr, delete itself.

5) Fork itself, child process execute /data/.3q/dm, it will finish things remain.

Self-Protection mechanism

The main thread of dm will create a thread, which will fork continually. 2


To prevent generating too many child processes, dm will create two file locks to block new created process. The file lock is named .l6, .l9 and saved in /data.

We can see the processes and file locks list here during the execution.


By creating child process frequently, it makes harder to terminate it. If we kill each of the process, the other one will create a new.

Core malicious executable file

reactore.dex.jar is the core framework of PoisonCake, which is an zip file containing a classes.dex and 8 encrypted plugins.


The core framework provides basic interfaces declaring. The basic interfaces separated into 4 parts:

1) Infrastructor Responsible for most basic functions provider, like DB operation.

2) Repository Responsible for feature management.

3) Services Background executed services.

4) Component Independent part for feature providing.

The core framework also provides some core services and basic command implement.

After reactore.dex.jar being dropped and loaded, it first decrypts and releases plugins to /data/plugins. Then it scans and loads all classes implement by plugins.

It initializes Infrastructor, Repository, Service and Component in a particular order. After initialization done, it will process all the events which added during the initialization.

Finally, this core framework starts a loop, waiting for handler processing. The whole workflow graph is below:


Analysis of the malicious plug-in

PoisonCake implements 8 plugins, each one implements a different major function.


Analysis of some major plugins here.


bean implements injection to com.android.phone. It will first release an ELF named whitebean, and executes the following command:

a. whitebean –check libblackbean.so

Runtime checking, check if can retrieve android::AndroidRuntime::mJavaVM and android::AndroidRuntime::getRuntime or not.

b. whitebean com.android.phone libblackbean.so readbean.dex.jar cache Release /data/usr/server.log

Inject libblackbean.so and redbean.dex.jar into com.android.phone, and execute com.android.phone.os.Program.main to start running the injection code.

The injection part will inherit permissions from com.android.phone, so it will support these features:

1 Send and intercept SMS

2 Query phone information, IMEI, IMSI, phone number, connection status etc.

3 Network management, APN and Cellular. Finally, it will listen on port 10023 to accept command request from bean.


honeybee record log information, save and encrypt to /data/usr/honey, and will upload it to the remote server. The post url is http://slasty.hada1billi.info/honeycomb/ums/postEvent. The honey file is encrypted by AES, We decrypt it here.



sun provides networking connection support, and heartbeat connect service to the remote host for keeping online. The heartbeat host here is http://ubaj.tndmnsha.com/throne.

Interesting technology details

In the analyzing of PoisonCake, we found some interesting technology. PoisonCake using the JNI_CreateJavaVM API to load and run the JAR payload, which exported by libdvm.so. It will pass the following parameters:

–Djava.class.path=/data/usr/reactore.dex.jar -Djava.compiler=NONE -verbose:jni

In this way, the PoisonCake doesn’t need to install any APK files to the system. Most of the security software just scan APK files under system and app directory, so PoisonCake is more harder to detected.

We also find some fingerprint of the malware author and the malware creation time.

We guess the malware author named ruanxiaozhen. The core framework reactor.dex.jar created at 26 Aug 2014.


The initialization executable dm is created at 19 Nov 2014. 10

Detection and Clean policy

Professional Users can execute “ps” command to list mobile phone processes, check whether “dm” or “jworker” exist to determine whether the phone infected PoisonCake or not. Users can also check /data/.3q/dm, /data/usr. Users can also download PoisonCake Killer Tool[2] for detecting and cleaning.


[1] Report of FakeDebuggerd.C by 360 http://blogs.360.cn/360mobile/2014/11/24/analysis_of_fakedebuggerd_c_and_related_trojans

[2] PoisonCake Killer Tool by AVL Team https://update.avlyun.com/AvlPro/PoisonCakeKiller.apk

Appendix A: Malware and Payloads Hash


Appendix B: Significant Malicious Behaviors

Release and run reactor.dex.jar:


Post sensitive information to remote server: 13

Start local listening: 14

Read preferences to collect phone information: 15


邮箱地址不会被公开。 必填项已用*标注