Qihoo 360 Technology Co. Ltd. (NYSE: QIHU)
Qing Dong, Runze Zhao and Nianzhong Sun
About one month ago, we found the first Bootkit Trojan on the Android platform in the worldwide — Oldboot.A. By flashing a malicious boot.img into an Android phone, the Oldboot.A Trojan starts to run and extracts malicious application during the early stage of system’s booting. We have released the first special detection and removing toolagainst Oldboot in the world to detect it and protect our users’ mobile phone from damage.
Recently, we have seized a new variant of the Oldboot family — Oldboot.B, which uses the same technology as the Oldboot.A. Besides the ability of installing Apps silently in the background, Oldboot.B also can inject malicious modules into critical system process, prevent Apps from uninstalling, modify the browser’s homepage and uninstall or disable mobile Anti-Virus software. Specially, some ELF binaries of the new variant have their executable code and strings encrypted, and the configuration file downloaded from C&C server is hidden using steganography. Meanwhile the stealth ability of the new variants has been greatly strengthened. Individual components delete their files on the disk after be executed, which means these files just exist in the memory of the process or some system processes (through injection); It’s more difficult for the users or antivirus products to find them. The Oldboot is a well-organized huge Trojan family, with every member having a clear division of labor, written by professional programmers, promoted by commercial companies and evolved constantly. We have developed a new special tool that can effectively detect, defend this Bootkit.
From the current point of view, the most significant acts of Oldboot Trojan family is to receive commands sent from the server, silently download and install others normal Apps in the background without user’s permission, and benefits from the App promotion expenses. Once an Android device is infected by Oldboot Trojan, its users will find lots of newly installed Apps or games in the system, which are not manually installed by this user.
Oldboot.B, the new variant of the Oldboot family, is closely related to the Oldboot.A Trojan we found before, both in code and functionality. The approximate relationship as shown below:
Figure 1: The relationship among the main components of the Oldboot family that have been found
The components of the Oldboot.A Trojan are shown on the left side of Figure 1. Just as the analysis report we released previously said, the _imei_chk_ file automatically executes during the system startup by registering a service in the init.rc script, and drops the other two malicious files — GoogleKernel.apk and libgooglekernel.so instantly. These three components communicate with each other to achieve the malicious goals. If you want to learn more about their information, please refer to our analysis report.
The Oldboot.B we found recently is shown on the right side of Figure 1. Most components of the new variants add one startup point in the init.rc script, similar to Oldboot.A — to place itself in the initrd and add an entry point in the init.rc script, and then be flashed into the boot.img of an Android device. They also have similarities in their intended functionalities. For example, they will listen to the socket continuously and receive and execute command sent remotely. Specially, one component named ‘_boot_tst_’ of the new variant, will drop a file named ‘leecore.so’, most of whose code are similar to the code of the component named ‘libgooglekernel.so’ of the Oldboot.A Trojan.
According to the figures shown above, the Oldboot.B, according to the functionality, can be sorted into four parts:
I Part 1, the _boot_tst_ file set. The main functionality is to remotely inject codes into the ‘_system_server_’ processes of the Android system, continuously listen to the socket, and execute commands sent. As followed are the relevant files:
- /init.rc, the configuration script for Android system’s booting which has been modified by Oldboot
- _/sbin/boot_tst_, an ELF executable file for ARM architecture
- /data/system/usagestats/leecore.so, an ELF shared library file
- /data/system/usagestats/leejrc.so, an ELF shared library file
- /data/system/usagestats/leejar.jar, a Java Jar module file
/data/system/usagestats/leejar.dex , the dex file of the Jar file above
II Part 2, the _/sbin/adb_server_ file. The pm script of Android system is replaced by this file, to implement the Anti-Uninstallation functionality.
III Part 3, the _meta_chk_ file set. The main functionality is to update the configuration file, download and install Android Apps promoted in the background. As followed are the relevant files:
- /init.rc, the configuration script for Android system’s booting which has been modified by Oldboot
- _/sbin/meta_chk_, (v1) an ELF executable file for ARM architecture
- _/sbin/meta_chk_, (v2) an ELF executable file for ARM architecture
- _/sbin/adb_meta,_ an ELF executable file for ARM architecture
- /system/etc/.gprs.xml, encrypted configuration file
Ⅳ Part 4, the agentsysline file set. It is written in C++ language with complex architecture, running as a daemon in the background to receive commands sent. It can uninstall anti-virus software, delete the specific files and enable or disable network connection etc. The following are the relevant files:
- /init.rc, the configuration script for Android system’s booting which has been modified by Oldboot
- /sbin/agentsysline, an ELF executable file for ARM architecture
Part 1, the _boot_tst_ file set
Similar to the other members of the Oldboot family, the _boot_tst_ file automatically executes by adding a startup point in the configuration script for Android system’s booting. The following lines will be appended to init.rc file:
Here is the execution flow of boot_tst：
Figure 2: the execution flow of _boot_tst_
As shown above, it can be divided to two parts, one part of the code is executed in the _boot_tst_ process; the other part – the code injected — is executed in the _system_server_ process. Once the remote injection operation is completed, the two parts of the code communicate via the socket.
The execution flow of the code in the _boot_tst_ process is as follows:
- Drop embedded ELF file to the file /data/system/usagestats/leecore.so and load it into memory. Specially, this shared library file will be deleted after loaded into memory, and user will not able to find it in the file system.
- Call the main function exported by leecore.so.
- Drop embedded ELF file to the file /data/system/usagestats/leejrc.so
- Inject the /data/system/usagestats/leejrc.so file to the _system_server_ process of Android system.
Figure 3: inject after got the PID of _system_server_ process
Figure 4: remote injection
- Get the port number associated to the reserved socket – adb6 — registered in the init.rc script, listen to the socket continuously，perform the appropriate action in accordance with the instructions sent, and return to the operating result. The code is shown below：
Figure 5: listening socket and executing commands sent
The commands received from the adb6 socket can be divided into two groups; the relevant data structure is shown below:
Figure 6: the data structure for command distribution
The two groups of commands are：
- cmds receive an array to command, and then execute them with root privileges
- netcmd receive control commands from the leejar.jar module in the _system_server_ process，to open/close network, or acquire/release wakelock etc.
The code of leecore.so file is complied base on the code of the libgooglekernel.so file, which was described in our previous analysis report. The obvious change is that the usage of the curl and cJSON library to implement the update and parse of configuration files.
The code injected into the _system_server_ process start to execute from the function _hook_thai_jrc_init_ exported by leejrc.so. The main process is as follows:
- Drop embedded jar file to the file /data/system/usagestats/leejar.jar
- Load the leejar.jar into _system_server_ process by using DexClassLoader
- Call the static method leeJrcInit of the lee.main.main class in the eejar.jar
Figure 7: the method to load leejar.jar using DexClassLoader, and call the jar
- leeJrcInit will create a local socket server listening to the port 9096, receive commands sent from _boot_tst_ and execute them, and then return the results via the socket – adb6.
Figure 8: leejar creates a socket server listening command in the _system_server_ process
Figure 9: leejar connects to the socket listened by boot_tst, and sends commands
The following are the commands which the _boot_tst_ process can send to the socket server socket created by leejar in the _system_server_:
Part 2, the _meta_chk_ file set
The _meta_chk_ file also alters one startup entry point in the init.rc script file. The major difference between the two versions of the meta_chk is that, one version registers one socket named adb2 in the init.rc script, and listens to this socket in the code; the other version will create a socket server, and listen to local port 23332.
The execution flow of the meta_chk is shown below:
Figure 10: The execution flow of meta_chk
The execution flow of the meta_chk is as followed:
- Start the UpdateNoService using the am command.
Figure 11: start the UpdateNoService
- Check whether the execution path is /sbin/meta_chk; If not, it will not do anything malicious.
- Delete the /sbin/meta_chk file so that users and antivirus software cannot read and write this file, which can effectively avoid being detected and cleaned, because there is ‘no file’. As the meta_chk file is located in the ramdisk, once this file is deleted, it will not stop this Trojan from running and the Trojan still can automatically run during next booting. This is also a very practical trick for Trojan to hide itself.
Figure 12: Check the path and delete their own files at runtime
- Drop an embedded ZIP file to /system/lib/libkey.so, then use the open source library – MinZip – to unzip and extract the axel file inside, finally copy the axel file to the _/sbin/adb_meta_ file and add Executable property for it. The _/sbin/adb_meta_(i.e. axel) file is an open source lightweight HTTP/FTP download tool supporting multiple connections (Project homepage: http://axel.alioth.debian.org/ ), which is similar to the wget/curl utility, used by the meta_chk to download files from the server.
- Load the configuration file /system/etc/.gprs.xml for subsequent code to use. The /system/etc/.gprs.xml file is an encrypted configuration file, whose size is 12,508 bytes, which has a customized format and contains a very large number of fields, having the ‘AZD \ 0’ as a beginning symbol. This configuration file as least has the fields as followed:
- Domain name of the Trojan’s C&C server.
- The package names of some antivirus software to disable
- The package names of some Apps to promote and the local path of downloaded Apps
- A flag to indicate whether to clear the browser cache
- A flag to indicate whether to modify the home page of web browser and the URL to change to
- A commands list to execute
- The last time that the malicious behavior was triggered.
- Read the contents of the /system/etc/hosts file and check if some domain names could possibly be used for downloading hijacking Apps, such as zkl90.com, 177.net, 188.net, etc. Once hijacked, the meta_chk will overwrite the entire contents of the hosts file with the default content of hosts file (127.0.0.1 localhost) to ensure that the downloads afterwards can be performed properly
- Download a virus file to /system/lib/libdowntemp.so using the adb_meta (axel) tool, then rename it to /system/bin/chk, and make it executable, finally run the /system/bin/chk file.
Figure 13: Download the Trojan file and execute it
- Download the configuration file and overwrite the /system/etc/.gprs.xml file with it.
- Download APK file and install it in the background. In order to ensure the App can be downloaded and installed successfully, before performing a silent installation, the meta_chk file will use the command ‘pm disable’ to temporally to disable three mobile phone antivirus software — the 360 Mobile Safe, Tencent Mobile Manager, and Kingsoft Mobile Duba , and after installing the App, it will use the command ‘pm enable’ to enable them. Meanwhile the meta_chk will use the sqlite tool to directly modify the database file of Android’s ‘Settings’ App — settings.db, to make sure that Apps from the ‘unknown sources’ are allowed to install.
Figure 14: Download and install the APK
- Create a thread, which will listen to the socket and execute commands sent by other programs. The commands received by the _meta_chk_ can be divided into five groups. The ‘opengprs’ and ‘closegprs’ can open and close the phone’s network connection; The ‘setdb’ can directly modify the database file to change various settings of the Android phone’s ‘Settings’ application; The ‘check?c=‘ and ‘zxly2?=c’ can execute arbitrary commands with root privileges through the pipeline and return the results.
Figure 15: listening socket and executing the corresponding command
It is interesting that the _meta_chk_ will verify the client App’s RSA signature with the connecting to the socket server. Only if the client App’s signature contains the same contents as the data hard-coded in the _meta_chk_ in binary, the _meta_chk_will execute the command. Some Anti-virus software or killing tool use some functionality that the Trojan provided to remove the Trojan, and this authentication mechanism makes it no longer possible.
Figure 16: meta_chk validates the client’s signature
- Part 3, the _/sbin/adb_server_ file
The system file — /system/bin/pm — will be replaced by the _adb_server_ file, to hook the pm uninstall command. If it finds out the app to uninstall is one of the Apps that the Oldboot wants to promote, the _adb_server_ will not uninstall the app, but print the fake message ‘Success’ to the user or some tool. So is the Anti-Uninstallation functionality.
The _adb_server_ file exists in the ramdisk of bootimg just as the other members of the Oldboot family. Specially, it does not have a startup point in the init.rc script. The _meta_chk_ file (descripted below) will copy it and replace the /system/bin/pm file with it. The replacement process is shown below:
Figure 17: replace the _pm_ file using _adb_server_
When a user or program executes the pm command, the _adb_server_ file is actually executed. After started, the a_db_server_ file will take some necessary initialization, such as setting the uid and gid to root, checking the environment variable LD_LIBRARY_PATH and checking whether the parent process is the shell.
Figure 18: _adb_server_ ’s initialization checks
Then, the _adb_server_ will check whether the sub-command is ‘uninstall’. If it is, it will obtain an next parameter, e.g. the package name to uninstall, and then compare it with the item of the built-in package name list one by one; If it finds the package name to uninstall is contained in the built-in package name list, it will return directly and print a fake message ‘Success’.
Figure 19: The _adb_server_ checks whether the sub-command of pm is uninstall, and prints the message ‘Success’
Figure 20: Checking whether the App to uninstall is one of the Apps to promote
Part 4, the agentsysline file set
Depending on the input parameters, the agentsysline can do different things. It can act as an _SU_ program by calling the shell to execute various commands with ROOT permission (The Trojan authors did not fully implement that part of the function, so it cannot be used properly); Also the agentsysline can be running as a daemon service, receiving the commands sent from the remote server or local programs and executing them in the background.
The agentsysline is a multi-threaded program written in C++ language, with the main function encapsulated using C++ classes, and having good architecture design. Although 15 threads at least will be created by the agentsysline itself, the thread synchronization is very good. From the code, we can tell that the Trojan’s author is a senior Linux developer.
The agentsysline’s main function is packaging into 6 C++ classes, as followed:
The Frame single instance class, on behalf of the runtime of the program
The NetManager and TcpSession in charge of network connection
SocketCmdManager creates a socket and send/receive data, and sends commands received to CmdHandler to execute
CmdHandler gets commands from SocketCmdManager, parses and creates new threads to execute these commands
Logger single instance class, implement logging functionality
The relationship among these C++ classes is shown in the figure below:
Figure 21: agentsysline behavior diagrams
The execution flow of agentsysline is as followed:
Initialization; such as sets resource limit and the signal handler, and writes its own PID into the file /data/system/sys.server.id.
Call SocketCmdManager to create a socket server, and continuously listen to it
Call NetManager to connect to the network, and update the configuration file
Do an infinite loop — call SocketCmdManager to receive commands and execute them (the instructions supported are shown above) — unless a special signal is received, and the flag bTerminate set to 1.
Call each class destructor and exit.
The disassemble code is as follows:
Figure 22: the code of agentsysline daemon
Compared to the Oldboot sample _(imei_chk)_ we found before, the new variants of the Oldboot family have changed in many ways, especially, the defense against with antivirus software, and the defense against malware analyzer, and the defense against the automatic analysis tools, which are particularly significant and as follows:
The stealth ability of the Oldboot Trojan is greatly enhanced. On the one hand, after started, the _meta_chk_ will delete itself in the file system, with only the process itself is left. As we know, the popular Anti-virus software does not support the process memory scan in the Android platform, so they cannot detect or delete the Oldboot Trojan which resides in the memory. On the other hand, the _boot_tst_ uses remote injection technique to inject an SO file and a JAR file to the _system_server_ process. Since the injection technique on the Android platform is mature now, we can expect that the Oldboot Trojan authors to definitely use these two technologies together, to implement a ‘no process, no file’ Trojan. Perhaps this Trojan technology exists now, but we have yet to identify it.
The code of the Oldboot Trojan’s ELF file is no longer clear, but encrypted, and the decryption stub code at the beginning of the main routine will decode all the encrypted parts and execute them. Meanwhile, almost all the strings used by the program are encrypted. The configuration file is also encrypted. The extensive use of all these Anti-disassembly techniques, hinders the analysis process, and greatly increases the time required to analyze.
The Oldboot Trojan adopts some tricks against dynamic analysis, such as adding some meaningless code, and some behavior is randomly triggered.
The Oldboot Trojan will check some of the environmental attributes at runtime. For example, the _meta_chk_ will check its runtime path, and exit if the path is the expected. It will also check the SIM card, and it will not perform certain behavior if there is no SIM card. Due to these runtime checks, some sandbox or emulator cannot get useful results but false positive.
The Oldboot Trojan will check for the existence of antivirus software, and may uninstall the anti-virus software before doing anything malicious, or stop the Anti-virus software using the ‘pm disable’ command before installing any App to promote and then re-start them using ‘pm enable’ command. Of course the latter one is a more subtle way without user knowledge. A special case is that, the author of the agentsysline may take into account the fact that the 360 Mobile Safe is the most popular mobile security software in China, with the largest mobile phone market share, so he/she just added some code to only uninstall the 360 Mobile Safe without any other mobile Anti-Virus software. This makes the work of the engineers from Qihoo 360 extremely difficult.
Figure23: the agentsysline uninstalls 360 Mobile Safe and stops the RPC server
- The Oldboot Trojan uses the Steganography techniques to hide its configuration file downloaded from the C&C server. Steganography is a powerful technique that hide information within some format in a way that makes it difficult to be detected by one who doesn’t know it’s there, which acts as liaisons in the 911 terrorist attacks in U.S. We found that the _meta_chk_ will download some file from its C&C server. From its appearance, the file is a picture. But after some analysis, we found that the configuration of _meta_chk_ is hidden in this picture, which contains the command will be executed by _meta_chk_ and other information.
Figure 24: Trojan configuration file hidden in the picture file
- The Oldboot Trojan’s architecture design is more complex, with a high degree of flexibility, and a lot of behavior can all be configured and controlled from the Trojan’s C&C server. This control is fine-grained, and many things could be configurable. The configuration file of the _meta_chk_ clearly proves this point. The size of this configuration file is 12,508 bytes, and almost every byte has a different meaning. Complete analysis of a remotely controlled Trojan itself is a difficult task. Due to the fact that command issued from the C&C server is different, the behavior Trojan will be triggered may be different.
A domain name that _meta_chk_ will connect to is az.o65.org (the server is down right now). Through some search about this domain name, we found that its IP is 188.8.131.52, and many similar domain names exist on the same server. Through the cache of search engine, we found that they all have a string ‘ZKL90’ as the content of its homepage, so we are sure that all these domains are the server of the _meta_chk_. The _meta_chk_, as a single component of the Oldboot Trojan family, owns so many domain names. The domain names require considerable human and financial resources, so we guess the size of the team behind the Trojan Oldboot is large.
Figure 25: domain name list of the meta_chk
Now, we’ve released the first special detection and removing tool for Oldboot in the world. You can download it from:
This tool will deeply and precisely scan Android devices to find the existence of Oldboot and its variants. We’ve developed a new checking and deleting method in it which can effectively clean Oldboot on popular Android device models.
If your device isn’t supported currently, our suggestions include:
Checking this tool’s updating regularly. We’ll add the cleaning ability to more models;
If it finds Oldboot on your phone, please report your phone’s information and the samples to us. This will help us to develop cleaning code for your model more quickly.
You can also join our QQ group to report more information and to get our response engineers’ technical assistance.
Or you can try to re-flash your device with its origin stock ROM. After flashing, the Oldboot should be removed.
Since only modified devices will infect Oldboot, if you’ve found it by using our tool, you can also directly contact with your reseller to take customer service.
We also suggest you to install the 360 Mobile Safe and use the cloud detection ability to prevent the related threats brought by Oldboot.
As the first Bootkit on the Android platform, the Oldboot has a symbolic significance. In the war between the Anti-Virus software and the Trojans, it develops a new battle field, and opens up a new era.
The popularity of high-speed networks plays an important role in the rise of smart phones. Android-based smart phones, having the largest market share, keep the connection with the Internet most time. The authors of the Trojans on the Android platform notice this trend, so they prefer to put more and more information on the network, and the App or ELF files installed to the phones of users, just provide the basic functionality, such as updating the configuration over network, executing any command with ROOT privileges, etc. What the Trojan really does, is controlled from Trojan’s C&C server. The Oldboot Trojan family is the most significant demonstration of this trend.
Based on the discovered Trojan, the Oldboot Trojan family is mainly used to promote the Apps, and it is highly flexible and configurable, which can be proved from the following aspects: first of all, the number of the domain names and servers where configuration file stored are large, and the domain names change frequently to ensure that the Oldboot Trojans can always get the latest updates to meet the needs of promotion or against the defense of the anti-virus software; secondly, the configuration file is extremely complex, and most things are configurable, including the link of the App to download, the path to store after downloading and package name, etc. ; thirdly, the authors of the Oldboot Trojans take into account a variety of circumstances, for example, if the server address was hijacked in the hosts file, or if the active defense of anti-virus software is enabled, or if the user want to uninstall the Apps to promote using the ‘pm uninstall’, etc.; And of course, the Oldboot Trojan uses the Bootkit technology, having the basic functional modules flash into the bootimg of Android phone’s ROM, and automatically starts with the Android operating system as a native service, which makes the Oldboot Trojan the most notable pre-installed Android malware. Based on the points above, we can say that the Oldboot Trojan family has done the ‘best’ on the malicious App promotion.
The Oldboot Trojan essentially is a Bootkit Trojan which can remote control users’ Android phone. Depending on the commands sent from the C&C server, it can do many different things, such as sending fake SMS messages or phishing attacks, and so on. Driven by profit, the Oldboot Trojan family changes very fast to react to any situation. We will closely follow the latest development of this kind of attack and provide security solutions.
- Oldboot: the first Bootkit on Android