Sideloading-Malware Found in GooglePlay – An Overview

In July/August 2017, we found two interesting malware samples distributed in the official Google PlayStore, which had a total download rate of 5.5 Mio (based on GooglePlay). We reached out to the Android Security team and they immediately removed both apps from GooglePlay. In this article, we want to describe the details of the malware samples we found. Interestingly, both of them act very similarly. They offer an app with very limited functionality and try to force the user to install a malicious spyware application afterwards. This violates the developer policy due to the following provision: „Apps and app listings on Google Play must not provide any means to activate or access functionality that violate these terms, such as linking to a non-compliant APK hosted outside Google Play.

The following figure shows the general overview of malware’s architecture. First, we describe each component from a high-level perspective and will explain app-specific details afterwards.

Figure 1: Important components of the sideloading-malware.

The most important components are:

  • String Obfuscation

    Both apps made use of string-obfuscation techniques (anti-static analysis) in order to obfuscate all strings that occur in the app. Those include URLs, text that occurs in dialog boxes, etc. This was the first „challenge“ when we looked into the samples. But with the help of CodeInspect’s debugger and the „Mass Analysis“ view, this was not really challenging.

  • Anti-Dynamic Analysis Checks

    Both apps also contained anti-dynamic analysis tricks. Obviously, those checks occurred before the app communicates with the „Remote-Server 1“ (see Figure 1) or in other words the C2-server. Interestingly, for both cases only a single anti-dynamic check was implemented.

  • External Malware Install Check

    Next, the malware extracts device information such as the device-ID and sends it to a remote server („Remote-Server 1“). Based on the information and probably also some network-information (IP address, etc.), the server decides whether the real malware should be installed or not. This kind of information is part of the server response.

  • Server Response

    The server response can contain different types of information. One response type contains information whether the malware-install shall be triggered on the smartphone. Another one can contain an arbitrary text with the purpose of displaying it in form of a dialog on the phone. This is used for social engineering purpose like „As a next step, please enable Third-Party Installations…“.

  • Download Malware

    Finally, the malware gets downloaded. The „Remote Server 2“ URL and also the implementation for the malware-download is already part of the app and does not get dynamically loaded.

App1: SMS-Tracker Spyware Downloader
  • Package-Name: com.mobmonapp.appd
  • MD5: 158cc5a66e1c265220f8fc4f03861a76
  • Advisory
  • Installs: 100,000 – 500,000

The app advertises itself as a monitoring application, which does not violate the Android Developer Policy if it complies a few requirements listed here. However, the app distributed on GooglePlay had very limited functionality, which can be reduced to a downloader app. There were no real monitoring features implemented in that app. However, the app that gets downloaded afterwards contained all the monitoring features, which are described in detail on the website of the spyware developers

Details about the main parts of the sideloading process:

  • String Obfuscation

    They made use of a very „complex“ string obfuscation technique, which expects a string that is represented in binary format (e.g., „10001101“). It gets converted into alphabetic format with the following pseudocode snippet:

    public static String bytesToAlphabeticString(String binaryFormatOfString) {
      int length = binaryFormatOfString.length();
      String deobfuscatedString = "";
      for(int i = 0; i < length-8; i+=8) {
        String subStringOfBytesAsString = binaryFormatOfString.substring(i, i+8);
        char c = (char)Integer.parseInt(subStringOfBytesAsString, 2);
        deobfuscatedString += c;
      return deobfuscatedString;

    Since this is just a byte-to-string converter, we can use CodeInspect's decoder for that:

    Figure 2: Codeinspect's mass-decoder view.
  • Anti-Dynamic Analysis Checks

    In order to prevent automated dynamic analysis approaches from triggering the malware-app download (sideloading), they made use of a captcha that needs to be entered:

    Figure 3: Captcha inside the malware sample.
  • External Malware Install Check

    The malware fist communicates with it's C2 server - "" - via POST request without any parameters. So for this case, it does not send any device specific data to the C2 server, which was described in the overview figure above. The server triggers a malware download by sending the following JSON response: {"net":"ok","test":"uu"}

    This is also what you see in the code

    boolean $String22 = $param02.getString("net").equals("ok");
    if (!$String22) break block8;
      $String22 = $param02.getString("test").equals("uu");
      if ($String22) {
        this.step1 = true;

  • Download Malware

    Finally, the malware gets downloaded from

App 2: Cell Tracker
  • Package-Name:
  • MD5: be8d1c46b46af4176faf5d09fc7ae914
  • Advisory
  • Installs: 1,000,000 - 5,000,000

This application is designed in a very similar fashion as the previous one. It is a "kids tracking" application where the app that got distributed in GooglePlay acts as a downloader and the real spyware application gets sideloaded from a server outside of GooglePlay. It slightly differs from the main functionality, which will be explained in the following:

  • String Obfuscation

    The string obfuscation was realized by AES encryption (AES/CBC/NoPadding) with hardcoded IV (A1$qh#eQVb7uA7Yr) and hardcoded key (m315ZY?af2MxM58Y). It took a string as input and decrypted it with symmetric encryption. A little bit more advanced compared to App 1, but still not a big deal to automatically de-obfuscate. From an academic perspective, Harvester would be one approach that could have been used to automatically de-obfuscate those strings.

  • Anti-Dynamic Analysis Checks

    In this case, there was no real anti-dynamic analysis check. The only dynamic task that needs to be done is to click on a specific button.

  • External Malware Install Check

    The malware extracts different kind of device information including:

    • IMEI
    • Phone language
    • Timestamp
    [[action, firstcheck], [website,], [typeapp, 2], [imei, 395960584275410], [appid, 85], [langphone, en], [time, 1503606833687], [minname, 5], [maxname, 15], [minpass, 5], [maxpass, 20], null, null, null, null]

    encrypts them again with AES (see String Obfuscation)

    [a2ea1e93bdd8d380765f43489123c97a=d94574f1b957733ceb711eaff166dbe2, d4b60576694169abbed4baf5104dcf09=429aafb401154c1179cf72bc4fc022c8, 1a2dc2b354e50df1b1a3177c5d120862=bea050311d9927ae89b26a76333d50aa, 350157108d53e404e278e9fc3730a518=0c53dd2bb38d58ba57e6ed857a38b880, ba75a0c4130667e23533b8192a940d36=7951e20b569badb78485fdbb3ecdedfe, a7ef27db6153f9d6e97a9d04b2aa935a=c1d61bb16a199d03de52779b23e5c9ef, 6fc9dc8926973b0137305e320d6708d7=1b2463fa59de0ff801a65c2c3983b3b0, fb2c0648b89ac71e19a26df6fc68e402=d756ee9ab3d61f9384192c65a5865edf, c0a0f2d639394a4cf5677274b7f42e8c=6abbde6ecb273bb5e9b718f23e55f786, 2c361554155fac5c288e26dd2e88aa68=d756ee9ab3d61f9384192c65a5865edf, d5a03f3ffd23029f231dbc04ec129db8=58cc99c69a1f6454c9b51766c2f9dfb7, 3dd7583889475bfad844f87f2af2567f=f33f09e47f4bd1fef726c944e3a9c957]

    and sends it to the C2 server located at With the help of a MITM attack, one would be able to intercept the traffic, but since the key/value pairs are encrypted with AES, it is not obvious what kind of information is transferred.

    It is also important to mention that the C2 server seems to implement an external emulator check, because if the app runs on an emulator, it sends the following information to the C2 server:

    [[action, firstcheck], [website,], [typeapp, 2], [imei, null], [appid, 85], [langphone, en], [time, 1503606833687], [minname, 5], [maxname, 15], [minpass, 5], [maxpass, 20], null, null, null, null]

    The difference between this two data is the IMEI information:

    • Smartphone: [imei, 395960584275410]
    • Emulator: [imei, null]
  • Server Response

    The response of the C2 server differs when the request from the client is sent from a real device ([imei, 395960584275410]) vs. an emulator ([imei, null]). It either replies with information that triggers the external malware installation process or it replies with something like "There is a technical problem", which gets displayed to the user. In the former case, it replies with a social engineering text, which gets displayed to the user saying something similar to "You need to enable Third-Party Installation on your Android device. Everything is ok...".

    It is very interesting to see that the malware outsources the emulator check - even though it is a very simple check - to the server, which makes a simple emulator detection routine on client-side harder.

  • Download Malware

    Afterwards, the malware gets automatically downloaded from The URL targets a file with a file ending of txt, which is actually an apk file.


As a summary, in this article we described two sideloading malware applications that we discovered in July/August 2017 in the official GooglePlay store. In total, they had 5,5 Mio installs regarding to the GooglePlay Store website. The original samples that were uploaded to GooglePlay acted as a downloader that downloads the actual malware after app-installation. Both samples made use of anti-static and anti-dynamic analysis techniques and used a C2-server for the decision whether the malware shall be installed on the victim's smartphone or not.

General advice to a smartphone user:

  • Think twice if you really need to install third-party applications after installing an app from the official App-Store.