Posted by & filed under malware, potentially unwanted app, vulnerability.

– By Trustlook Research Team

You thought you installed an accelarating tool, when in fact a backdoor has sneaked into your mobile phone.

Leidian OS was recently promoted by the Qihoo 360 security tool. It claimed that if you flash Leidian OS into your mobile phone, the phone will run 30% faster and will save more battery life.

We analyzed Leidian OS and its installation process, and found that the Leidian OS actually contains a backdoor function which flashes a customized recovery image into the mobile phone using the fastboot tool. It also uninstalls system updates from other security apps (most of which are pre-installed apps by mobile phone vendors) according to a predefined blacklist and whitelist. The uninstallation of these apps will expose the mobile phone to security vulnerabilities.

Leidian OS also installs the Leidian App market, Leidian browser, Leidian assistance, Leidian acceleration and the 360 security tool without the user’s consent. Moreover, it modifies the system’s certificate to install apps in the /system directory and to get the SYSTEM privilege. As a consequence, it can execute critical operations and hook important functions to monitor system activities. It also leverages Qihoo360’s root tool to get the root access. Last but not least, the Qihoo360 security tool doesn’t give a clear notification to users when the Leidian OS is being flashed. Instead, it just tells the user to “experience a much faster mobile phone” by making a simple click in Fig. 1. It doesn’t specify the risk to the user after the process. All these actions make the user more exposed to an unsecure environment.

After our analysis, we found that Leidian OS is developed by two companies called “KuRuiMeng” and “CHIMA”, which are subsidiaries of Qihoo360. Leidian OS has embedded several modules of the Qihoo360 mobile security tool as well.

Below is the detailed analysis, along with the steps to install the Leidian OS.

As shown in Fig. 1 and 2, by installing the latest Qihoo360 security tool in the Windows version and clicking “more” in the lower right corner to get more tools, you will find “Leidian OS” to open the installation window.



Fig.1 – The entrance to the Leidian OS in Qihoo360 security tool – Step 1. 

Fig.2 – The entrance to the Leidian OS in Qihoo360 security tool – Step 2. 


Fig.3 – The installation window of the Leidian OS in Qihoo360 security tool


When clicking the green “experience instantly” button in Fig. 3 above, the Qihoo360 security tool begins to download the related files and applications, which are saved in

 C:\Documents and Settings\Administrator\Application Data\CleanAndroid.



Fig.4 – Begin to install the Leidian OS to the mobile phone

By monitoring the downloading process, we found that these files were downloaded by the360CleanHelper.exe process.

We also found the related JSON file containing the downloading information as shown in Fig. 5 and the json file in Table 1.


Fig.5 –  360CleanHelper.exe drops the Leidian OS installation files



Table.1 – The JSON file containing the downloading information.


Fig.6 – Downloading information of the Flash tool


Fig.7 – The flash tool package


Fig.8 – The flash tool package in the Cleandroid directory


Fig.9 – Files in “tools” directory of the “Cleandroid” directory

From the tools package info we see that the Leidian OS is installed by flashing the recovery.img into the

phone with the fastboot tool. Then it uses an “adb” tool to install apks into the phone. According to the

JSON file in Table 1 the download address is By monitoring the ip (

and querying its DNS info we find that the download server is hosted by Qihoo360. From the

Leidian OS’s customer service webpage

( we find that the company’s address is same with that of Qihoo360,

which further reveals the development and operational relationship of Leidian OS and Qihoo360.


Fig.10 – The download address of the Leidian OS


Fig.11 – The DNS query info of the download address

As shown in Fig. 9, the details of the files in the CleanAndroid directory are explained as follows:

  • contains an apk file, which is used for auto-starting after the boot process and to start some important services.
  • com.chima.customizationassist contains a file called Hurricane.apk.
    • It’s used for uninstalling or disabling some apps according to a blacklist and a whitelist.
  • contains an App which realizes a custom App loader.
    • It uses this tool to automatically capture the WeChat bonus in WeChat chat groups.
    • This feature is popular and is used to attract more users to install Leidian OS.
    • But it will make the WeChat App unsecure, resulting in the possible disclosure of the WeChat username and password.
  • displays the UI of the Leidian OS and starts some apps.
  • uninstalls some system apps according to a blacklist and a whitelist.
  • displays animation after the mobile phone is booted.
  • is for network management and the firewall function.
  • contains a dexdump tool to parse the dex files.
  • is for rooting the mobile phone and hooking some important functions.

Here we explain the certificate of the attached files:

leidianLauncher.apk file’s certificate is shown in Fig. 12:


Fig.12 Certificate of the leidianLauncher.apk file

chima.apk file’s certificate is shown in Fig. 13:


Fig.13 Certificate of the chima.apk file

As shown in Fig. 12 and Fig. 13, they are developed by KuRuiMeng and CHIMA, which are subsidiaries of Qihoo360.

Below is the analysis to three important Apps (ChiMa.apk,updateCenter.apk,Hurricane.apk).



The package name is com.chima.vulcan. It is installed in the /system directory in the user’s phone and has the same

certificate with the OS so it can get the system privilege as shown in Fig. 14. Therefore, it will start after the mobile

phone starts. It collects user’s information, including IMEI/Serial Number/operator/gender/location/CPU info/running

processes list, etc.


Fig.14 – The SYSTEM uid owned by the Chima.apk

This App drops a file called in its assets directory, and it hooks three important functions:

bindService, startService, getContentProvider in dalvik layer (as shown in Fig. 15). This allows it to monitor

and control some communications between the components in the system.


Fig.15 – The hooking to bindService function in chima.apk

The App also implements many sensitive remote execution commands, such as installing Apps remotely,

disabling Components remotely, etc. The command list is shown in Fig. 16.


Fig.16 – Some remote execution commands in the Chima.apk

As shown in Fig. 17, we found that multiple function calls in this app are implemented by reflection.

The method is often used by malware for evasion purposes in anti-virus detection.


Fig. 17 – Reflection calling to some functions used in Chima.apk

2. updateCerter.apk 


The app is for rooting and hooking the system (as shown in Fig. 18). It allows for full control of the mobile phone.


Fig. 18 – The hooking to many functions in the updateCerter.apk file

The app also hooks the native functions, as shown in Fig. 19.


Fig.19 – The hooking to the native functions

Root module RootMan is located in com.qihoo.permmgr.RootMan package. After our verification we found that

this module is the same as that in Qihoo360’s root tool (in the name of “360 Root By One Click”).

By concatenating the strings of different mobile phone models and related info, we send them to Qihoo360’s

server as shown in Fig. 20. Then we got different root exploits to execute as shown in Fig. 21.


Fig.20 – Concatenation of a special URL for downloading respective root exploits using specific phone models


Fig.21 – Execution of the root exploit in updateCentre

3. Hurricane.apk 


The app is for uninstalling the apps in a user’s mobile phone according to a list, including most of the mobile

phone vendors’ updates and security applications. After this uninstallation process, a user’s mobile phone

will be less secure. The uninstallation App list is as follows:




Suggestions: Go to your mobile phone vendor’s official website to find the correct recovery image file and reflash your mobile phone if Leidian OS has been installed.

Posted by & filed under vulnerability, zero-day.


“这不是bug,是功能。” -程序员常说

“这不是漏洞,是后门。” -黑客们常说

The door at the beach




Screen Shot 2015-11-24 at 1.21.44 AM


受影响的安卓版360浏览器版本为6.9.9.70 beta及以下。在11月23日,有白帽子将漏洞发到了乌云(,24小时内Trustlook发布了漏洞的demo(。360在同一天更新了修复漏洞的6.9.9.71 beta。鉴于此漏洞的巨大危害,我们没有马上公布漏洞利用细节,给了用户更多时间修补。

360浏览器在卸载的时候会弹出一个“用户调查”,询问用户卸载原因。这个功能是在一个叫um.3(UninstallManager的缩写)的so文件里实现的。这个库文件会开启一个独立进程,在收到卸载的消息后,会使用”am start”命令开启浏览器,显示“卸载调查”网页。



um.3的进程间通信机制是用一个自定义的HTTP server实现的。如同所有的虫洞漏洞一样,成了万恶之源。这个server会监听手机的6587端口,允许所有地址连接。但它支持的功能很简单:1. 查看版本 2. 开启浏览器



/data/data/com.qihoo.browser/files/so_libs/um.3 com.qihoo.browser –execute am start -n -a android.intent.action.VIEW -d\\&Wid=81e188a23869a898d1343eaa20c11495
–user 0


1. 命令使用system函数执行,对命令本身没有任何过滤。

2. 弹出网页的url是作为命令的一部分传进去的,而这个url是远程可控的,直接来自远程请求的GET参数。


为了搞清楚这个HTTP server的一些逻辑,我们用IDA Pro/HexRay把um.3逆向成了C代码,并加了注释。关键的函数有两个:sub_9018和sub_9078,分别用来解析URL参数,和实现HTTP server逻辑。有兴趣的读者可以点开大图看。

Untitled drawing (9)


am start -n com.qihoo.browser/.BrowserActivity -a android.intent.action.VIEW -d %s -e from %s



curl -X http://[target IP]:6587/t=1&;echo 1>/sdcard/lol.txt;


Screen Shot 2015-12-10 at 6.23.14 PM





Posted by & filed under vulnerability, zero-day.


“It’s not a bug. It’s a feature.” – A developer’s quote

“It’s not a vulnerability. It’s a backdoor.” – A hacker’s quote

The door at the beach


We first introduced “Anywhere Door” (in Chinese: “任意门”) in this previous article. “Anywhere Door” is a new Wormhole vulnerability that affects versions of the 360 Browser prior to beta. By sending a certain crafted HTTP request, a remote attacker can execute an arbitrary shell command on the target phone, with the privilege of the 360 Browser app. If the phone is rooted, the attacker can do anything on the root user’s device, such as install and remove apps.

In this article, we will disclose more details of this vulnerability.

Like all the Wormhole vulnerabilities that have come before it, “Anywhere Door” is triggered on a customized HTTP server, on the port 6587. The server is used for cross-process communications, and contains a few APIs, such as popping-up a browser window. The purpose of this API is to display an “uninstall survey” when the main app is being removed. And the server logic is implemented by a native library (.so file) called um.3 (UninstallManager we guess?)


Port 6587 will be opened upon the first launch of the 360 browser


The HTTP server in um.3 is running in an independent process


The um.3 will be copied from the assets folder to so_libs folder

When handling the “launch browser” request, we found the um.3 directly executes a shell command to launch the browser process. For example, when popping up the “uninstall survey”, the command is goes like this:

/data/data/com.qihoo.browser/files/so_libs/um.3 com.qihoo.browser –execute am start -n -a android.intent.action.VIEW -d\\&Wid=81e188a23869a898d1343eaa20c11495
–user 0

There is a critical vulnerability in this design: the url, which is part of the shell command, is controllable by a HTTP GET parameter. And the entire command is executed via system() without any filtering, causing a remote command injection vulnerability. A remote attacker could use “;” to close the original “am start” command, add any malicious commands after the “;”, and have those commands executed by the 360 browser on the target phone.

We reverse engineered the um.3 using IDA Pro/HexRay. The critical code is mainly in 2 functions: sub_9018 and sub_9078, which are used for handling HTTP server logic and GET parameter parsing. The code logic is explained in the comments in the following figure (click for enlarged image):

Untitled drawing (9)

From the reversed C code, we can see that the raw command to be executed is:

am start -n com.qihoo.browser/.BrowserActivity -a android.intent.action.VIEW -d %s -e from %s

And the value of GET parameter “u” will be filled in the first “%s” (while the “t” value must be set to “1”). To exploit it, all an attacker needs to do is simply send the following request:

curl -X http://[target IP]:6587/t=1&;echo 1>/sdcard/lol.txt;

After that, the attacker will find a lol.txt generated in the sdcard folder.

By default, the attacker could share the privileges of the 360 browser, such as sending and accessing SMS messages, reading the call logs, accessing browser history, and monitoring the camera and microphone.

If you are targeting a rooted phone, you can do almost anything. For instance, silently replacing the user’s banking app with a phishing app (as shown in the following video). Even if the user has installed a root management tool like SuperSU, the confirmation dialog will appear in the name of the 360 browser, which is likely to be trusted by the user.


Posted by & filed under News, zero-day.

Screen Shot 2015-11-24 at 1.21.44 AM


The 360 browser is a popular browser on both the PC and mobile platforms in the Chinese market. It is known for its security, and has a total download number of more than 460 million on the 360 market, Tencent market and combined.

24 hours ago, a new vulnerability of the 360 browser was posted on [1] (a popular vulnerability disclosure platform in China). After careful analysis of the 360 safe browser (com.qihoo.expressbrowser), another critical vulnerability “Anywhere Door” was found.

Like the “Wormhole” and “DimensionDoor”, the Anywhere Door is triggered on a customized HTTP service. We noticed that HTTP service will not be shutdown even after the app is patched. To stop this service, users need to manually disable it in the system settings, or reboot the phone.

Qihoo pushed the update beta on Nov 23 to address this bug. According to our tests, the previous versions before Nov 23, such as beta, are vulnerable. If you are using the 360 browser, and haven’t updated it after Nov 23, please make sure to update it to beta or newer, then restart your phone.

What can this vulnerability do?

This vulnerability could lead to remote code execution on any Android phone with a 360 browser installed. Keywords: Remote, Silence, Flexible.

For rooted phones: the attacker can do pretty much everything, such as install APKs from the Internet in the background, access emails & SMS, monitor the camera and microphone. It is more flexible than the “DimensionDoor”. If the user has installed a root management tool such as SuperSU, the confirmation dialog will be popped up in the name of the 360 browser, which is likely to be trusted by users.


For unrooted phones: the attacker could share the permissions of the 360 browser, such as sending and accessing SMS, reading the call logs, accessing browser history, and monitoring the camera and microphone.


As of today, Nov 23, most of the users have not upgraded their 360 browser to the latest version. The detailed analysis and exploitation code will be released in a later blog, after users have had a chance to protect themselves.

We made a PoC video for this vulnerability. In this demo, we triggered it remotely on a rooted phone, and replaced the genuine banking app with an arbitrary app.

This blog will be updated soon with more details and exploitation simulations. Stay tuned!


Posted by & filed under News.

几天前,360手机助手被Google Play下架了:

Screen Shot 2015-11-18 at 12.01.45 AM

这就是说,Google Play认为,360手机助手存在违反规定的行为,比如安全问题,或者不按套路出牌的更新/加载代码等行为。这也意味着,除中国大陆外,安卓机基本不能从官方渠道下载360手机助手。

我们分析了Google Play下架前的版本以及相应的国内版本,进而发现了“DimensionDoor(异次元之门)”,一个和Wormhole危害相当的漏洞。

该漏洞在360手机助手3.4.70(10月15日发布)及以下版本均受影响。在漏洞被发现当天(美国西部时间11月18日晚)只有官网上能下载暂未发现受漏洞影响的3.5.0 beta版本。而直到现在(美西时间11月20日晚8点)360手机助手在部分手机上仍只能自动更新到3.4.70版。(见文后视频)


    1. 为了实现跨应用通信,360手机助手开启了一个自定制的http服务,该服务会监听手机的38517端口,并且允许远程IP连接
    2. 这个http服务会接受一些通过HTTP GET发送的指令并解析执行,但缺少对发送者的身份验证,因此本质如同一个后门。其中最可能构成安全隐患的指令有两项:
      a. 下载远程apk并自动安装,无需任何用户交互(会弹出应用界面)
      b. 通过包名查看某个应用是否已安装
Screen Shot 2015-11-20 at 4.54.59 PM


  1. a功能有对下载域名的白名单判断,但我们发现可以通过360的CDN域名shouji.360tpcdn.com作为下载url并绕过该限制。由于360应用市场(包括雷电手机搜索)使用了此CDN作为分发服务器,因此攻击者可以先将app传到360应用市场,获取下载url,再远程安装到受害者手机。
  2. 可能的安全威胁:

    a. 黑客可以把任意app伪装成流行应用或应用更新等有欺骗性的内容,大量扫描同3G/4G网段的IP并且远程自动安装
    b. 黑客可以远程扫描用户手机上的应用安装信息,造成隐私泄露。




  1. 文中分析的3.1.55是360手机助手2014年的老版本,目前官方正式版和beta版均不存在远程端口安全风险。
  2. 360手机助手的APK下载会弹出助手下载页面,是具有界面交互的正常功能,整个过程用户有明确感知,与百度系产品被利用静默无提示安装任意应用的虫洞漏洞有本质区别。本文演示视频也证明了这一点,“dimensiondoor”的定义不妥。
  3. 文中提到打开任意网页的问题实际是不存在的。360手机助手对打开的url有着严格限制,只能打开360域名的网页。文中根据逆向分析猜测,与真实的产品功能逻辑相差甚远。



    1. 3.1.55是我们经手的第一个样本,并被提及在第一版分析报告中。但绝非只有所谓“2014年版本”有漏洞。3.4.70及以前的版本,都受此漏洞影响。具体受影响的用户数未知,考虑到360应用商店上2.5亿、应用宝上1.1亿、豌豆荚1.6亿的下载量,很可能国内受影响用户达到亿级,总量超过Wormhole漏洞。
    2. “360手机助手的APK下载会弹出助手下载页面,是具有界面交互的正常功能,整个过程用户有明确感知”。一个安全大厂,面对几亿用户和产品漏洞的事实,说出这种话是不负责任的。我相信360一定知道这个http server(simpleHttpServer)是以后台service运行的,就算用户的手机处于待机状态,执行远程安装命令后手机都会远程安装并执行(见视频),待机状态用户根本不会关注到这个过程。另外攻击者也可以把恶意apk伪装成软件更新等有欺骗性的内容,并弹出自动安装。更有趣的是,app在下载栏的名称是可以由攻击者随意修改的。


  1. 浏览器能开启的URL,以及下载安装的URL存在过滤,这些我们都分析到了并非猜测。而我们的分析中也已提及:360自己的CDN域名shouji.360tpcdn.com是在白名单里的。而360应用市场里的应用,都会通过这个域名来分发。所以任何应用只要上传到360应用市场,都可以利用这个漏洞远程安装到手机。
  2. 360手机助手被Google Play下架前的版本是2.2.012(国内外使用了两套版本计数),也是一个有漏洞的版本,并非360和Freebuf声称的“躺枪”。





Posted by & filed under vulnerability.


Authors: Jinjian ZHAI, Yang SONG

The developers of paid apps in Google Play depend on a protection algorithm to prevent unauthorized installation and monetary losses of pirating and repackaging activities globally. During our research, we found that there is a loophole in the paid app protection algorithm on the Google Play store, in which crawlers can easily harvest many paid apps automatically, and distribute those apps at a lower price, or freely install them into other cell phones with a brand new Google account (without any credit card information registered).

According to Android Security Internals: An In-Depth Guide to Android’s Security Architecture

By Nikolay Elenkov, Page 82,  “Free apps are decrypted and the APKs end up in /data/app/, while an encrypted container in /data/app-asec/ is created and mounted under /mnt/asec/<package-name> for paid apps.” Yet the paid apps in the research do not behavior like that.

The sample being researched is the paid version of the popular app “Weather Live”. This paid version has more than 100,000 downloads, and the free version has more than 5,000,000 downloads. The price for the paid version is $0.99 per installation as shown in Fig. 1 .


Fig. 1 The paid version of the Weather Live app costs $0.99.

As shown in Fig. 2-4, we set-up a valid credit card in the Google account to purchase the app. The app installed successfully. After the installation, the customer can choose to uninstall and refund the charge within a certain amount of time. The customer can also “OPEN” the app to play for a while before going back to the Google Play page to “REFUND”.


Fig. 2. The first phone is equipped with a Google account which has a credit card registered.


Fig. 3. The purchasing and downloading process on the first phone is fast.


Fig. 4. After installation, a “REFUND” button is shown in the first phone with valid credit card information for the Google account.


Fig. 5. The functions of the paid app on the first phone with valid credit card information.

As shown in Fig. 5, the paid app that we purchased works well on the first phone that has valid credit card information in the Google account.


Fig. 6. The APK of the paid version of the Weather Live app can be pulled from the first phone that has the credit card information in Panel A.  Then it is installed on the second  phone with a brand new Google account that does not have credit card information in Panel B.

In order to test the validity of the paid app’s protection, we first tried to pull the APK from the first phone. As shown in Fig. 6, the pulling process is successful. The APK size matches the size on the Google Play page, and we can unzip it without any encrypting protection. Then the app is tested if it can be installed in another phone, which is also successful.


Fig. 7 The paid version of the Weather Live app is installed on the phone of the Google account without valid credit card information by adb install.

As shown in Fig. 7, the APK of the paid app has been shown on the home screen of the second phone after adb installation. The second phone has a brand new Google account for which we have not input any credit card information yet, as shown in Fig. 8.


Fig. 8. The Google account on the second phone is a brand new one without any credit card information.

As shown in Fig. 8, the Google account in the second phone is totally different with that of the first phone. And it should be noted we do not possess any purchasing capability on the second phone.

It’s interesting that when browsing the Google Play page of the paid version of the “Weather Live”, we found the app has been labeled as installed as shown in Fig. 9-10 . The only different button from the first phone ( as shown in Fig. 4 ) is the “UNINSTALL” button, as in Fig. 9  you are not capable of refunding the charge of the app. It’s our hypothesis that the Google service put it into another track of the logic without checking the validity of the payment. When they found the app can not be refunded due to null payment, they just show the uninstall button as any other free apps, instead of alerting the abnormal behaviour. In this sense, many users are capable of taking advantage of the paid APKs, which are possibly collected by any automatic crawler. This might cause potentially large monetary losses for Android developers.


Fig. 9. In the second phone without credit card information, the “REFUND” button is just replaced with the “UNINSTALL” button. The download counts (100,000) are still revealing that the app is the paid version.


Fig. 10 . In the app manager of the second phone without credit card information, the paid version, and only the paid version, is installed.

In order to fully understand if there is any difference between the app installed in the paid environment and the unpaid environment, we play with the “Weather Live” app and found the functions of the app on the two phones are exactly the same, as shown in Fig. 5 and 11.


Fig. 11. Playing with the app in the second phone (without credit card information), we found the functions are the same as on the first phone.

Last but not the least, the paid APK which was pulled from the first phone does not have any encryption protection, and can be easily reversed engineered by apktools and JD-GUI, as shown in Fig. 12.


Fig. 12 . The pulled APK can be reversed engineered.

In general, the Google Play store should have provided a feasible protection algorithm for the paid apps of Android developers, otherwise their hard work can be easily fooled by a crawler and third party Android markets around the world, where the authentic apps might be sold at a lower price, or even distributed freely. Further, the paid apps risk the same level of repackaging activities from hackers as any free apps distributed inside and outside Google Play.  

The bug has been reported to Google Android Open Source Project and was accepted with bug tracking number 194525.

Screen Shot 2015-11-20 at 10.26.35 PM

The bug was considered “working as intended” in the reply of the developer, yet they failed to address the issue why the paid app of one Google account is not only considered free app of that specific Google account but also of any Google accounts. Such intended mechanism can be easily abused by pirating and repackaging activities.

Screen Shot 2015-11-20 at 8.50.16 PM


If you would like to know the list of affected MD5s or access to the detailed report, please contact

Posted by & filed under vulnerability, zero-day.



Authors: Tianfang Guo, Mengmeng Li

Two weeks ago, the Wormhole vulnerability was in the wild, and affected more than 100M Android users. As you may already know, the Wormhole is triggered on a customized HTTP service used for cross-app communication, allowing a remote attacker to bypass the security check and issue a variety of remote commands such as installing arbitrary APKs.

Less than 2 weeks after the Wormhole vulnerability was fixed by Baidu, another incident happened with the 360 Mobile Assistant application, which is a popular app on the Android platform. The Trustlook research team found a similar issue inside this app, which causes a nearly identical remote code execution bug, called the “DimensionDoor”.


Screen Shot 2015-11-17 at 10.34.45 PM


The affected package is named “com.qihoo.appstore” in the Chinese market and “com.qihoo.secstore” on Google Play. The apps have a different version control, but use the same implementation. We used the Chinese version 3.1.55 as the example. When the app is launched, a service called “SimpleWebServer” will start listening to the TCP through a remote connection.


Screen Shot 2015-11-17 at 11.30.00 PM


Even though the app’s code is protected by ProGuard, it is still readable. Three of the functionalities from the code that we highlight are open URL, download/install APK and start activity.


Screen Shot 2015-11-17 at 11.37.52 PM



The commands could be issued remotely by sending an HTTP request to http://[client_ip]:38517/[API name]?[param], which will trigger any corresponding logic. However, there is a security check to prevent the service from being abused. For example, the remote URL will be filtered against a domain white list (only the domains owned by the vendor are allowed to access):




Screen Shot 2015-11-17 at 11.49.23 PM


We dug into the verification logic and found a few detours. For example, the 360 app’s cloud storage service uses the domain “”. Anyone can upload APK files to it, and get a downloadable URL with the “” domain. Another approach is using the vendor’s CDN domain “”.

Below is a PoC video:


As of Nov 17, the 360 Mobile Assistant app has already been taken down from the Google Play store.

Screen Shot 2015-11-18 at 12.01.45 AM

Posted by & filed under malware, potentially unwanted app, Virus.


Authors: Jinjian ZHAI, Yang SONG, Mengmeng LI

100 miles north of San Francisco in the City of Ten Thousands Buddhas, a statue of Mercy Goddess with 1,000 hands has been worshipped since 1974. The 1,000 hands are used to save people separately. However, those hands are rooted from the same body.

A series of repackaged apps can be looked at in the same way as that statue with 1,000 hands. That is, thousands of individual apps with distinctive MD5 hash were indeed similar derivatives, classified by the unique package name with the same or a handful of developing groups.

Research of the individual APK samples can lead to the specific app version and developer information, and in turn reveal the developer’s reputation and network of repackaged apps within the global Android markets.


Fig. 1 The popular QQDownloader app has over 1,600 derived APKs available on the internet.

As shown in Fig.1, we take the APKs which share the same package name “” as research samples in this blog. They are chosen because firstly, the app reflects a variety of APK downloading sources; secondly, the app itself is an Android marketplace, and thus is prone to the attack of hackers as a base app to deliver more  repackaged apps.

The market itself is an Android app, which needs to be downloaded from the internet directly. It recommends apps as well as provides downloading sources upon search / query.  

We have kept monitoring the malicious behaviors of this family, and have collected over 1,605 versions of this family. The 1,605 versions of QQDownloader consists of many authentic apps, as well as a few repackaged apps. Some of the repackaged apps are even malware.

The reason that such a large number of versions exist lies in the fact that firstly QQDownloader is the counterpart of Google Play in China, and has been updated frequently; secondly, QQDownloader is so popular that it has been the target of hackers for possibly monetary gains.

I. The Authentic Apps

The authentic apps of “” are marked with exactly the same developer signature.


Fig. 2 The authentic developer certificate signature of QQDownloader.

As shown in Fig. 2, the authentic QQDownloader  is developed and maintained by the Android QZone Team in Beijing.

This authentic sub-series represents the majority of the 1,605 samples being researched. They consist of 1,583 samples signed by the developer’s certificate signature as shown in Fig. 2.

II. The Repackaged Apps

The remaining 22 apps are repackaged apps. Based on the authentic and repackaged apps’ discrepancy of the main-launcher activity name, which is concurrently registered as “android.intent.action.MAIN” and categorized as “android.intent.category.LAUNCHER” under the same android:name action in the AndroidManifest.xml, we found a few repackaged apps of interest.

We analyzed one APK for its dynamic behaviors, network traffic, and static code logic. The Metadata of the sample being researched is shown in Fig. 3.


Fig. 3 The Metadata of the Illegitimate and Repackaged Sample of the QQDownloader app.


Fig. 4. AndroidManifest.xml of the repackaged QQDownloader app. The main activity from the launcher is

As shown in Fig. 4, the main activity which is linked to the launcher icon in the home page of the phone is, while the main activity of the authentic QQDownloader app  – “com.tencent.assistant.activity.SplashActivity” is bypassed.

The sample passed most AV vendor scannings as benign, with Virustotal score of 1/55 when initially submitted, as shown in Fig. 5:


Fig. 5 VirusTotal scan of the repackaged sample when queried on 11/09/2015.

Yet further investigation of the main activity reveals some suspicious function calls.

Fig. 6. The main activity of the repackaged app redirects the onCreate() function to a stored string in AndroidManifest.xml.

Firstly, a service called YangService is started by the initializer YangInit.getM()  from the initSad() function of Fig. 6.

Secondly, as shown in jumpToOther() function of Fig. 6, a class name is read from the MyUtil.getRac() function, which in turn reads the activity name “com.tencent.assistant.activity.SplashActivity” from AndroidManifest.xml (as shown in Fig. 4)

A question of who and why they insert the extra service into the SplashActivity of the QQDownloader would be proposed naturally against the repackaged app. Bearing such questions, we examed the developer’s certificate signature of the app:

Fig. 7. The developer’s certificate signature of the repackaged app.

As shown in Fig. 7. the Issuer’s Information is too brief to reveal the real developer’s information, which suggests his/her suspicious behavior.

A detailed scrutiny of the YangServer and YangReceiver class reveals that the injected service is used to load class methods dynamically :


Fig. 8. The dynamic class loading source code called by the functions of the injected YangService class.

When monitoring the dynamic behaviors and sniffing the network traffic while the app is running in the Trustlook Mobile Sandbox environment, we found that the app slagged the initial activity of the main QQDownloader layout and covered the phone screen with a large ad window.


Fig. 9 The ad window started by the repackaged QQDownloader app.

When following the network traffic packets, we found that customer’s privacy was collected and sent to the ad server in Aliyun, the public cloud service platform.


Fig. 10. The network packet with customer’s privacy was sent to the ad server based on the Aliyun cloud service platform.


Fig. 11. The ad packet contains URL of APKs and ad pictures. The pictures are rotating and clickable in Fig. 9.

As shown in Fig. 10 and Fig. 11, the ad server collects the following private information and uses it to push ads in the injected ad window:

  1. customer’s gender and age
  2. phone number
  3. IP address
  4. MAC address
  5. location, longitude, and latitude
  6. IMEI and IMSI
  7. OS version
  8. ISP service

We see that the repackaged QQDownloader sample as being dangerous adware. When we continued to research other repackaged QQDownloader samples, we found a list of suspicious developer certificate signatures. As shown in Fig. 12, they either contain little information or purposely alter the initial QZone developing team’s information.


Fig. 12. Some suspicious developer certificate signatures of the repackaged apps of QQDownloader.

In general, the authentic apps are repackaged due to one or more of the following reasons:

  1. The developer would like to change the ad network
  2. The developer would like to inject malicious code
  3. The developer would like to republish the app in an Android market other than the one where the authentic app is published.

If you would like to know the list of malware MD5s or the detailed report, please contact

Posted by & filed under Uncategorized, vulnerability.

This article is an update to our previous report “The WormHole Vulnerability: The Number of Affected Apps is Increasing”. We will introduce more technical details about this vulnerability going forward.

Apk version used: Baidu map 7.7.0 for Android

The cause of the vulnerability:

The Moplus SDK creates a local server for in- and cross- app communications. It links on special ports (6259 or 40310), but doesn’t need to match the request source correctly. It only checks the Host/remote-addr/Referer field of the arrived packet. If their specifications align, it will allow their connection and accept/execute many powerful commands in the url’s parameters, such as downloading files from the internet, installing Apps, running apps, uploading user’s phone information, etc. These packet headers can be easily forged, allowing an attacker to send specially made urls to the user’s phone remotely, and executing dangerous commands on the user’s phone. Moplus SDK is so useful that many third party apps contain Moplus SDK for search engine or map services. Therefore, this vulnerability can have a large impact on Android users. You only need to know the user’s ip to launch an attack. Yes, that’s all.

The conditions that the incoming packet header must adhere to if they want to connect the user’s phone:

  • The “Host” and “remote-addr” field’s value is “”
  • The “referer” file contains one of the following:

Then it will consider that this request is from inside the app, accept it, and execute the command contained in the request.

To any a hacker, setting the request’s header field to some value is as easy as drinking a cup of coffee. All you need to do is this (if using Python):



All commands that the Moplus SDK supports can be seen in the function

All commands the server supports

The correspondence between the command and the function are as follows:

The corresponding functions and the commands

All commands’ functionalities are as follows:

  • geolocation: get the user’s exact location, such as the longitude and latitude
  • getsearchboxinfo: check if the user has installed the Baidu Search App (package
  • getapn: get the user’s APN, such as the Wifi/2G/3G
  • getserviceinfo: get the Moplus/Baidu push service version info
  • getpackageinfo: check if the user has installed apps whose package names are specified in the parameters of the url
  • sendintent: launch a specified Intent Uri (such as open some App/send sms/open URL in browser and so on)
  • getcuid: get the user’s phone IMEI /cid number
  • getlocstring: get the phone’s cid/area code/IMEI and then join them together for sending
  • scandownloadfile: scan the apks in the download directory
  • addcontactinfo: add contact to the user’s phone
  • getapplist: get all installed apps’ package name and version on the user’s phone
  • downloadfile: download a file from a specified url to the user’s phone
  • uploadfile: install or uninstall some apps silently
downloadfile command

For example,take the command “downloadfile”. Its code is as follows: The function gets the download url, the saved path, and the file size (in bytes) from the url. Then it will download the file to the user’s phone, and the file will be saved in the “savepath” directory under the sdcard directory, etc. in /sdcard/$savepath$.

The code pieces of the downloadfile function

The url format containing the parameter for downloading is as follows:


sendintent command

Another important command is “sendintent”. Anyone could specify the intent Uri, which will start the Uri intent directly, such as dialing the specified number, sending an sms, or running an application.

Get the intent Uri from the URL

Get an Intent Uri then start it:

Start other apps by sending Intent to the phone
Start the Intent by the Uri in the URL

If you want to dial a number you could make a url like this:


We developed the exploit application in Python and Java several days ago and tested it successfully, but recently Baidu updated its SDK. The vulnerable port (6259/40310) has been closed (I have tried several Apps, with the same outcome). When the app containing Moplus SDK is newly installed, the 6259/40310 port will open for several seconds, but will close soon thereafter. So now the exploit cannot be used. When executed, it will return an error. However, we found another vulnerability: the 7777 port is always open, so by exploiting the same vulnerability, the attacker could get useful information of the phone remotely, such as the phone’s IMEI and the user’s location, but cannot execute dangerous actions such as installing apps or downloading files to the user’s phone. Regardless, this could still result in the leakage of the user’s private information.

The vulnerable port 6259 has been closed, but 7777 port is still open, light vulnerable

These commands are so powerful, like Doraemon’s key, and this SDK so widely used, especially in China. If used by attackers, this could have a widespread negative impact for Android users. Imagine if you use a 2G or 3G network. All users are on the same LAN, so the attacker can  just scan the net range then see if you opened the 6259/40310 port. If yes, then the attacker could launch the attack. It’s that easy. So big companies should pay more attention their SDK and app security, and protect the Android world for users. Remember: With great power, comes great responsibility.



Posted by & filed under vulnerability, zero-day.

The “WormHole” is a critical vulnerability on Moplus SDK on Android, which is used by major Baidu products, as well as some other apps.

In summary, this vulnerability is caused by “ImmortalService” – a customized HTTP service used for cross-app communication. Because “ImmortalService” uses an incorrect approach to filter requests from outside the phone, a remote attacker could use certain crafted HTTP requests to execute some pre-set functionalities of this SDK, such as to install an app from the Internet (needs root support), launch arbitrary intents, or manipulate phone contacts.

The details of this vulnerability can be found here.

It is entirely possible for an attacker to develop a worm , which can spreads itself using the WormHole vulnerability. To make matter worse if the worm spreads popular apps according to, more than 100M users can become affected.


The Trustlook research team has searched our app database, and found the total number might be more than that. Here is the updated list of affected apps:

cn.jingling.motu.photowonder 50,000,000+ 10,000,000+ 5,000,000+
mobisocial.omlet 5,000,000+
xcxin.filexpert 5,000,000+ 1,000,000+
org.cocos2dx.FishGame 1,000,000+ 1,000,000+ 1,000,000+ 1,000,000+ 1,000,000+ 1,000,000+ 1,000,000+ 1,000,000+
com.ubercab.driver 1,000,000+

Please note that the above list is a conservative estimation of the number of affected apps. The data only includes the Apps on Google Play, which has the lower bound of install numbers. Apps that were distributed via other channels are not calculated.

This blog will be updated by Nov 4 with more info about the WormHole vulnerability.