Parasites Android Malware Discovered by WildFire

Zhi Xu

Category: Malware
 Tags: , ,

On July 16, 2013, Palo Alto Networks WildFire detected a new kind of Android malware that we have named Parasites. We will use this post to provide some technical details around this family of malware to benefit our customers, the security industry and other malware researchers. The malware was detected as part of a repackaged app named “SystemApp Remover” and a legitimate version of this app is available for sale on the Google Play Store for $1.02. The package name of the detected malware sample is, and its package signer is “Android”.

Based on analysis from WildFire, the malware sample seems to be distributed by a mobile advertising company in China, named WinAds. Since WinAds does not have its own app store, it is likely that this malware was promoted by WinAds and was pushed to the user.

Compared with the legitimate app, we observed that the repackaged APK file includes two independent payload APK files hidden in the /lib folder. The file names are “/lib/ s.pcb” and “/lib/c.pcb”. Unlike other Android malware families, the author did not intend to install these two APK files. Instead, the malware APK will dynamically load these two payload files when receiving certain system broadcast intents (e.g., when the user unlock the screen).

The s.pcb and c.pcb work independently. The file s.pcb specializes in SMS interception and sending SMS in the background, while c.pcb controls file download management, displaying ads, and tricking the user into installing downloaded APK files. That is the reason we named the malware Parasites, as the two payload APK files are attached to the “victim” APK file through the added launcher codes.

Repackaging technique

The Parasites sample shows a template to add or remove a payload APK. It also shows an interesting trend of Android malware. The attacker can easily attach a malicious APK file to a legitimate app APK. Further, the same launcher code can be reused to repackage other victim APK files without any changes. This capacity allows the attacker to generate a large number of malicious APK files very easily.

In Figure 1, we show a comparison of AndroidManifest.xml files of the legitimate APK file (on the left) and that of the repackaged APK file (on the right).  The attacker simply appends the following contents after the original content:

  • The broadcast receiver “com.slcc.tls.cofer” is used to start the service “com.slcc.tls.cfqws” which will load the APK file c.pcb dynamically;
  • The broadcast receiver “com.slcm.hqa.snbgr” is used to start the service “com.slcm.hqa.soiqs” which will load the APK file s.pcb dynamically
  • The added permissions are permissions claimed by c.pcb and s.pcb ;
  • Compared to the legitimate app, the malware author changes the app version code from “42” to “42108”


Figure 1. The AndroidManifest.xml of legitimate app (on the left) v.s. the AndroidManifest.xml of Parasites sample (on the right). The red circled parts are changed by the malware author.

In Figure 2, we show the (reversed) source code of the legitimate APK file downloaded from Google Play (on the left) and the repackaged APK file (on the right). As shown in the figure, the source code of malware sample is highly obfuscated. However, the organization of Parasites is still neat and straightforward.

  • The package com.slcc.tls is the interface to start package which acts as the interface to launch and control the APK file c.pcb.
  • The package com.slcm.hqa is the interface to start package which acts as the interface to launch and control the APK file s.pcb. The package is used to start an instance of SManager defined in package


Figure 2. The comparison of source codes: the original APK file (on the left) v.s. the repackaged APK file (on the right)

The attack functions are provided by s.pcb and c.pcb. As these two APK files work independently, we discuss the technical details of both APK files separately.

Payload APK s.pcb  (the SMSIntercept)

s.pcb is an complete and independent APK file but it is not signed. By reversing the APK file, the package name is “”. The s.pcb will be loaded when the user unlock the touchscreen (i.e. android.intent.action.USER_PRESENT), or when smartphone connects to a WiFi network (i.e.,, or when a new app is installed on the smartphone (i.e., android.intent.action.PACKAGE_ADDED). The app name is “SMSIntercept”.


Figure 3. AndroidManifest.xml of s.pcb.

The s.pcb APK has the following key functions:

  • Send SMS with the infected device ID to a designated phone number controlled by remote attack website.
  • Block incoming SMS messages and log the intercepted SMS contents in a database file.
  • Maintain a command and control channel with the attacker through the Internet

Send SMS To Designated Phone Number

After being loaded, s.pcb first communicates with the url to request the receiver phone number. The returned results are in the format of JSON object. Figure 4 shows an example of these results:

[{ “ErrorType”:”E1″,”PhoneNum”:”13708333433;”,”RequestTimes”:”40;”,”NextRequestTime”:”123″}]

With the received information, the APK will first save the received information in the file “/data/data/”, as shown in Figure 4.


Figure 4. The sm.xml that contains the specifications for sending SMS messages and the Icon of s.pcb.

Then, the malware APK composes a SMS message that includes the infected device’s ID as content, and sends the SMS in the background to the number provided by the malicious URL.  Every time the s.pcb APK  is loaded, it will attempt to send a SMS message.

Block incoming SMS and log the intercepted SMS contents in database files

s.pcb monitors the intents broadcasted on the infected device. The SMS interceptor is implemented in class “”. When the intent “android.provider.Telephony.SMS_RECEIVED” is received, the s.pcb will first check the content of received SMS message with criteria stored in sm.db file. If there is a match, the s.pcb will log the received SMS in the database file sm.db, and then block the broadcast by calling the BroadcastReceiver.abortBroadcast() function, so that the user will never see the incoming SMS. The structure of sm.db file is shown in Figure 5.


Figure 5. Structure of sm.db

Command & Control

s.pcb implements its communication functions in the class. One interesting feature is that, the s.pcb not only uploads the phone’s information to the attacker, it also uploads the host APK file information to the attacker (i.e. in this sample). We believe the attacker is attempting to build a botnet with different types of repackaged APK files. The host APK file information is used for management of different APK files.

Specifically, the communication functions include:

  • Download initial data, such as the phone number to send SMS
    • URL connecting to :
  • Download instruction data
    • URL connecting to :
  • Upload phone information to remote server
    • URL connecting to :
    • Uploaded information include:
      • Device id (i.e. imei in this sample)
      • appkey: the “SM_KEY” embedded in the AndroidManifest.xml of Parasites APK file. Used to identify the host APK file this s.pcb lives in
      • host app name: i.e. in this sample.

Payload APK c.pcb (the DownloadManager)

c.pcb is also an unsigned APK file. By reversing the APK file, its package name is “”. The intents are exactly the same as those seen in s.pcb. As such c.pcb is loaded when the user unlocks the touchscreen (i.e. android.intent.action.USER_PRESENT), or when the device connects to a WiFi network (i.e.,, or when a new app is installed on the device (i.e., android.intent.action.PACKAGE_ADDED). The app name is “Test App” when we managed to install it separately.


Figure 6. AndroidManifest.xml of c.pcb.

The c.pcb APK acts like aggressive adware, providing the following functions:

  • File download management
  • Pushing ads to phone
  • Trick the user to install the downloaded APK files by sending notification messages.
  • Keep a command and control channel with the attacker through Internet

Download Management

c.pcb downloads files with a given address and saves the APK file on the SD card. Further, all the downloading records are saved in a database file located in “/data/data/” file. The structure of this file is as shown in Figure 7.


Figure 7. The LDownload.db file kept by c.pcb.

Push Ads to Phone

c.pcb allows the attacker to send promotions to the device and display the them via the notification service. In c.pcb, the promotion information is called “ad” and each ad is uniquely identified by a gid.  The titles and images displayed in notification messages are also sent from the attacker. To keep track of these types of “ads”, c.pcb maintains a database file in the “/data/data/” file. In this file, detailed information is logged as shown in Figure 8.


Figure 8. The lock.db file that keeps all the promotion information (the gid is the unique id of each entity)

Push APK files to user by notifications

c.pcb does not claim the permission to install the downloaded APK files directly. Instead, we observed that the malware attempts to trick the user by sending notifications. c.pcb provides two types of notifications, one is through the standard notifications bar on the top of screen, and the other is by popping up an AlertDialog. For example, class builds an AlertDialog object with the message in the Dialog as “You have downloaded apps that have not been installed yet”.  By default, when the user attempts to open a downloaded APK file, the Android OS will consider this action as “attempting to install this file”. The system app will handle the installation.  This saves the APK installation task and the corresponding security permission for the c.pcb.

Command & Control

c.pcb communicates with, and we observed the following actions:

  • Check if the local gids are still valid
    • URL connecting to: . The list of local gids will be uploaded for validation.
  • Upload phone information to remote server
    • URL connecting to :
    • Uploaded information include:
      • Device ID (i.e. imei in this sample)
      • appkey: the “SM_KEY” embedded in the AndroidManifest.xml of Parasites APK file. Used to identify the host APK file this s.pcb lives in
      • Host app name: i.e. in this sample.
      • Current Android OS model
  • Regain information of a gid from remote website:
    • URL connecting to :
    • The gid will be uploaded
  • Debug purpose:
    • URL connecting to :
  • Upload the local ads promotion statistic information:
    • URL connection to:
    • The uploaded information include:
      • Device ID
      • Appkey
      • pname: the intent used to launch the p.pcb.
      • svion : c.pcb version (value is 1 in the current sample)
      • Host app name
      • Android OS model,
      • Network name (e.g. ChinaMobile)
      • gids and their counts.


The Parasites sample shows a good example about how to attach independent APK files to a host APK file. It allows the attacker to convert an existing benign app (e.g. a task management app) into an attack app, and then attach its APK file to any host APK file. The attached APK files will be loaded dynamically and run independently from the host APK file. This allows the attacker to make sophisticated repackaged APK files more easily and efficiently.

To this end, we show the organization of folder /data/data/ , which keeps all the information related to the attack.  The sc.dex and sc.jar correspond to c.pcb. The s.jar and s.dex correspond to s.pcb.


Figure 9 The organization of local storage maintained by Parasites.

Malware sample availability

The sha256 value of detected malware APK file is


As on Aug 21, 2013, the APK file URL is still valid at

2 Reader Comments

  1. Disappointing that this article was disseminated with the headline : “The popularity of the Android OS, at a 79.3 percent global market share, makes Android devices particularly susceptible to mobile malware.”

    Nonsense. Its popularity make Android particularly “attractive” to mobile malware. However, until I see trojans and viruses rampant in the Play Store, I don’t care, at all, about corrupted APKs in the wild.

    The opening paragraph of this article can also be misread to construe that this malware is in the Play Store, but upon re-reading, I think you’re saying that the Play Store version is okay, and this malware simply attempts to pretend to be that legitimate version. That could be made clearer, I think.

    Lots of scaremongering that only affects those countries who buy Android Phones but have no access to the Play Store. Not sure how many that is, but that could included in the article info too, I think. Starting point : lists the 97 countries that do have full access to Play Store.

  2. Zhi Xu

    I agree that the number of malware discovered in Google App Store is much smaller than the number of malware discovered in third party app stores. However, we can not force the user downloading the apps only from Google App store. We shall protect those users who downloads apps from third party app stores too. In fact, even Google states that “As an open platform, Android offers choice. You distribute your Android apps to users in any way you want, using any distribution approach or combination of approaches that meets your needs.” Thus, APK files distributed by third party app stores are also important.

    Besides, repackaging legitimate apps and distributing repackaged apps (for free) is still the major way to attract smartphone users downloading malware apps.

Got something to say?

Get updates: Unit 42

Sign up to receive the latest news, cyber threat intelligence and research from Unit42

By submitting this form, you agree to our Terms of Use and acknowledge our Privacy Statement.