8 Facts You Have to Know for the Safest Pokemon Hunt

It’s capturing the world by storm. People are leaving their homes in droves and abandoning their normal lives in an attempt to catch them all. It is a Pokémon renaissance happening in 2016.  In the early hours of the morning and the wee hours of the night, mass droves of people are heading to parks and lakes. Poke stops, the designated landmarks designed to help Poke Masters refill on poke balls and other essentials, are frequented by the young and the old. With seemingly entire countries obsessed with the game, many security experts are concerned with the permissions and information accessed by the game. In addition, there are real-world dangers in playing the game. Here are the top 8 things you need to know about Pokemon Go in order to stay safe.


1)      Accessing your Google Account:

When first signing up for the popular game, a user has the option to sign up using their Google account or through a special Pokémon Trainers club. Simply for convenience’s sake, many people opt out for the Google account registration. This just requires the user to enter their Google account login, such as an email, and a password for their Google accounts. The issue with this is that the app then has unrestricted access to all forms of a user’s Google account. The user is required to give access to the app so that the game may be played, but a user is not alerted to what the app can access, which is why it is aptly named “Full Account Access”. This proves to be problematic as the app could theoretically access photo libraries and billing information.

2)      Camera Usage:

The app’s prized feature is an AR option that brings the Pokémon to life. In order to activate the augmented reality feature, a player must allow the app to access the personal device’s camera. The AR feature on the app is a huge draw for the players in the game, as it feels similar to reality. Using the AR feature, however, requires camera permission, which is another portal for possible data leakage. People take photos with the Pokémon but in turn end up capturing street addresses, car licenses plates, possible credit card information, and many other details.

3)      GPS Tracking: Location Location Location.

Pokémon Go is an app that utilizes a user’s GPS location and camera to support its gameplay. These two permissions, however, prove to be problematic when it comes to mobile security.  The game uses GPS to track where a player is and spawn the rare Pokémon when many players are clustered together. This proves to be a high security threat because a hacker can pinpoint a player’s precise whereabouts.

4)      Not watching where you’re going:

It’s been reported previously that people are having accidents left and right from obsessive game play. From players abandoning their cars in search of the most rare Pokémon to players falling off cliffs looking for an elusive Charmander, people are putting their safety as a secondary priority to the Hitmonchan hunt.

5)      Armed robbery      

Hackers aren’t the only criminals after the players in Pokemon Go. Robberies are happening all over because of the level of game play. These low life criminals drop lures on poke stops around different cities, meant to draw more Pokemon to the poke stop. Since these lures are public and visible within the app, many players will stop by these locations hoping to use these communal lures for their own Jigglypuff hunts. This helps round up potential victims and their valuable possessions into one common area, making for an easy trap.

6)      Downloading a third party app:

Previously, the Pokemon Go app was only available in selected countries and areas. With the craze going so strong in the United States, countries like England and Canada were feeling major FOMO. Many users turned to third party apps to obtain the game to play and join in the worldwide obsession. This is a steep slope to walk down, however. Many third party apps contain malware or phishing software. Added alongside the massive amount of permissions required to play the Pokemon App, this makes it a huge security threat.

7)     Fake Apps:

A new group of dangerous applications targeting Pokémon Go users by promising cheats, tips, and other functionality. Despite their innocuous-sounding titles, the apps actually contained malicious code that either tricked users into paying for expensive bogus services or took over victims’ phones to click porn ads, among other things.

8)      Trustlook:

To ensure your safety and privacy, researchers cannot recommend enough using a security application. Using an antivirus app that deeply scans and alerts you of any data breaches is vital during this kind of social frenzy. Trustlook can protect every player from all the threats of Pokemon Go and any other threat in the market. With ID Check, Boost, SD Card Scan, Backup and Restore, and many other features, Trustlook can make sure you stay safe while in hot pursuit of Pikachu.  Download the Trustlook app here on the Google Play store today.

The Lie of "thunderous" speed – an Analysis of the Leidian OS and its Apps

– By Trustlook Research Team

You thought you installed an accelerating 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 SettingsAdministratorApplication DataCleanAndroid.


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 dl.so.keniub.com. 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

(http://leidianos.com/privacy.html) 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:

  • ChiMaster.zip 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.
  • com.leidianos.osspecial.zip 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.
  • leidianLauncher.zip displays the UI of the Leidian OS and starts some apps.
  • leidianProvider.zip uninstalls some system apps according to a blacklist and a whitelist.
  • donghua.zip displays animation after the mobile phone is booted.
  • netd.zip is for network management and the firewall function.
  • update.zip contains a dexdump tool to parse the dex files.
  • UpdateCentre.zip 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).

1. ChiMa.app

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 libchimahelper.so 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.

Analysis of Repackaged Applications from over One Thousand QQDownloaders in Global Android Marketplaces


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 “com.tencent.android.qqdownloader” 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 “com.tencent.android.qqdownloader” 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 com.fk.bh.MyActivity

As shown in Fig. 4, the main activity which is linked to the launcher icon in the home page of the phone is com.fk.bh.MainActivity, 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 support@trustlook.com

Hackers don’t need root exploits

Authors: Mengmeng Li, Tianfang Guo, Jinjian Zhai


“Root as a Service”

RaaS – Root as a Service is a phrase used to describe the methodology of malware launching a root exploit with server side support, in which the client side will dynamically request exploits specified for its hardware and OS version from the server. This implementation gives more confidentiality and upgrade flexibility to the exploits.

In recent months, an increasing number of RaaS malwares have been reviewed, such as “GhostPush” and “Kemoge”. These malwares are capable of downloading root exploits from their command & control server, and rooting the victim’s phone. They then take advantage of the root privilege to install 3rd party apps, and remove antivirus apps which prevents them from being uninstalled.

RaaS: the attack procedure

Using similar root exploits, the root tool (PC or Android based), on the other hand, becomes a necessity for some Android users who want to have total control of their phones. Driven by user demand, even the largest players in the industry have published their own root tools, which are designed to be used as easily as one-click ordering. Those vendors have certainly considered the safety of their root exploits, and have utilized protection mechanisms – such as anti-debugging and data-encryption, to protect their exploit binaries.

On the ACM-CCS conference, researchers from University of California, Riverside published a paper “Android Root and its Providers:A Double-Edged Sword” about the analysis of popular root tools. According to the paper, most of the exploits from rooting tools could be extracted and reverse engineered. And those tools are like double edged swords – once the exploits are leaked, no one can guarantee they will not be used for evil purposes.

After reading this paper, we decided to further explore a possibility: with the root vendors exposing their backend APIs, is it doable to forge the client side requests, abuse the vendors’ service, and root someone’s phone in the background (say, make a “root SDK” that can be integrated into malwares) without preparing a single root exploit?

Case study

We started with a popular root tool A. Because this tool has utilized strong code obfuscation, we did our analysis by dynamic execution in our sandbox, and analyzed the events after the large “Root” button was clicked.

Its RaaS implementation is quite clear:

  • Upload user’s device info to the server, such as phone type, OS build info, and kernel version.
  • The server will respond a JSON, containing the download link of a “root solution”, usually a native library
  • The app will then download the library file, load it, and let the root exploit do its job
  • Remove all the downloaded config files and exploits

Initial Request to the root server with phone info:


The returned JSON file is encrypted by the AES algorithm. However, the decryption algorithm and key are all implemented locally. It cannot hide from our dynamic analysis:


The decrypted JSON looks like this:


Using the download link from the JSON file, the real exploit will be downloaded and renamed with an unpredictable number, and stored in the app’s private folder.


The last step is to load the library and trigger the exploit:


The exploit library file has been modified with some anti-debugging mechanisms, such as corrupting its Section Header Table and adding overlapping instructions. However, those efforts only added difficulties on static and dynamic analysis, not loading and execution. We can launch the exploit by loading this library, execute its entrance function and root the target phone.

Corrupted ELF header prevents static analysis. But can be easily repaired

Another rooting tool, B, used a similar architecture as A, and also proved vulnerable against forging requests. Its configure file downloaded from the server has not been encrypted:


The jar file in the figure (…1111.jar) is a compressed file containing some tools for rooting as shown in the figure below:


The root tool B will drop the corresponding root exploit and the related tools in a directory named by a three digit number. It is possible for an attacker to exhaust all the possible device info combinations to steal all the exploits from that vendor.

The dropped exploit is not protected and can be decompiled easily. We learned the way it works, how it exploits the Android system, and the corresponding CVE or non-CVE vulnerabilities involved. More detailed analysis will be included in a later blog post.


The root tool is a double edged sword. Although the vendors tried their best to prevent the exploits being abused, the nature of RaaS makes it difficult to detect whether the client request is forged, nor can the vendors protect their exploits from being abused by someone else. As long as their “root service” is enabled, the possibility of their backend being abused by hackers exists.

We have more research on rooting tools coming up. Stay tuned!

"Reflections on Trusting Trust" – Some Thoughts on the XcodeGhost Incident


Authors: Tianfang Guo, Jinjian Zhai

(Further reading about the XcodeGhost: the original story and detailed analysis)

Reflections on Trusting Trust

In 1984, Ken Thompson, “Father of Unix”, mentioned in his speech about the first compiler backdoor he once made, which allows him to login with “su” privilege into any Unix systems in the Bell lab in the 1970s. To find this backdoor, his colleges reviewed the source code of Unix and found nothing.  They have never suspected it’s the compiler that planted the backdoor. The author, who wrote Apple’s App Store Infected with XcodeGhost malware in China” believes that Ken is telling us, before searching for security holes, one should first be clear about which party he could and couldn’t trust,  thus Ken named that speech “Reflections on Trusting Trust”.

And 30 years later, we witnessed the consequences of “Trusting UnTrust” – everyone gave enough alertness to the apps, but gave unconditional trust to the compiler which builds apps. As a result, the XCodeGhost infected more than 4000 apps on the iOS App Store, according to FireEye.

The injected malicious code could upload the victim’s privacy to a remote server, it could also pop up message boxes upon server request, which can be potentially used for phishing or attracting users to download more malicious apps. Luckily the last functionality seemed not been used till the C&C server was shutdown. Yet it would have been still possible for an attacker from world-wide-web to hijack the HTTP traffic and reactivate this backdoor.

Screen Shot 2015-09-22 at 7.47.47 PM
Screen Shot 2015-09-22 at 7.48.29 PM

Apple has also reacted to this incidence by pulling off 400+ infected apps:

The XcodeGhost is the first successful example of distributing large number of malwares into the iOS App Store. The impact rose many questions.

Who’s at fault?
Most victims are from China , thus it took days to download the Xcode in China from the official source. Some places were suffering from frequent disconnections (not sure if it was caused by Great Fire Wall), making a complete download the mission impossible. On the other hand the local download links could be easily found in developer communities and were conveniently hosted by Chinese cloud storage vendors such as Baidu. The hacker apparently took advantage of the situation to launch such attack. Like Ken’s story in 1970s, people fully trusted the infected build environment which is distributed via the peer-to-peer downloading channels.

What surprised us is, despite the individual developers, even the largest players in the industry were not survived, e.g. Tencent. The large companies certainly have the condition to download their IDEs from official sites, e.g. using a Virtual Privacy Network. Lazy or ignorance? Apple could also have deployed their CDN servers in China, but they choose to ignore the developers from their 2nd largest market.

Also, repackaging a signed dmg file should not be an easy job on OS X . After 10.7.5, the Gatekeeper mechanism is introduced, which will verify an app’s file digests upon the first launch. In this case, Adding or modifying the files in a dmg will cause verification failure and rejection.

The Gatekeeper is turned on by default. According to our survey, most iOS developers has turned it off, some said it’s for the convenience of adding 3rd party extensions to Xcode.


Is it over?

There are follow-ups about this incident: the Unity framework distributed in China has also been found infected. The samples have the same malicious logic. The only difference is the domain names of the C&C servers.

Technically, the Android IDE is as fragile as Xcode under an attack of compilers. As is shown below, on all the fundamental Java packages are under the /lib folder of the project. It’s entirely possible to inject the malicious code into one of them, and to repackage the installation dmg of Android Studio. As a result all the APKs built by the Studio ( including the IDE ) will be infected.

Trustlook is closely watching the similar attacks on Android. We will update the blog if we found any infected frameworks.

Screen Shot 2015-09-23 at 1.15.46 AM

Why GPS Location Leakage is not simply a malware problem: Flaws in legitimate apps continue to expose users to real time risks.

Authors: Jinjian Zhai, Tianfang Guo

Nasir al-Wuhayshi had a bounty of 10 million USD issued by the US State Department in October 2014, and was killed in a US drone strike in the Hadhramaut Governorate of Yemen on 12 June 2015.

Explaining the mystery of how al-Wuhayshi got pinned in a vast area of desert land mass, CNN reported : “This was more than just luck. … He got sloppy and moved in a way that he could be tracked. … Classified high tech gear makes the strike possible. Eavesdropping of cell phone and monitoring of social media by the intelligence community is at all time high.

According to CNN, eavesdropping on Nasir al-Wuhayshi’s cellphone disclosed his location, like something out of a 007 film. Mobile apps, especially social media applications, emerge as new sources of location intelligence.

Although this was an fatal example of the leakage of physical GPS metadata, the information was under the control of international law enforcement. You can imagine situations where the circumstances can evolve to be much worse had similar data been under the control of outlaws.

It seems similar privacy leakages aren’t as far off as Yemen. On June 17, Reuters reported large amounts of private data were stolen due to common flaws in application development: “Security researchers have uncovered a flaw in the way thousands of popular mobile applications store data online, leaving users’ personal information, including passwords, addresses, door codes and location data, vulnerable to hackers.

Below is an example of a leaked GPS location from a compromised android app.

com.songguo.hotel is a popular Android hotel booking app from Ctrip.com, one of the biggest online travel services in China. The version we analysed sent GPS locations to Baidu Map service without any user input. The data, accurate to a few meters, was captured en route in plain text.

The plain text of GPS location.


The high accuracy location of the user is fetchable by GPS coordinates:



GPS stealing behavior can be detected by the Trustlook Mobile Security platform and application with the name “StealBy.Socket“.




The malicious “StealBy.Socket” behavior in Trustlook Mobile Security app:




Apps leaking GPS data were discovered as malicious by Trustlook Mobile Security:



There are ways to avoid leaking GPS location, including disabling location sharing entirely. Sometimes such notification windows are absent, just like the app we studied in this blog. Consumers should rely on Antivirus applications to be sure of privacy protection from not only malware but the also risky behavior of legitimate apps.

Other data leaks- including password, photos, and medical data, will be further investigated and published in the future. Stay tuned…

To read the full report of the sample from the Trustlook Antivirus platform, please contact : support@trustlook.com

“The Clickers” – Zombie Malware that feed on the mobile ecosystem

Authors: Tianfang Guo, Jinjian Zhai; Special Thanks: Steven Chen

Last week, Trustlook exposed the Facebook credential phishing malware “Cowboy Adventure”. In the article we pointed out that phishing is one kind of behavior that is difficult to detect via an automated technical approach. This may be one reason it sneaked by the Google Play Store’s  “Bouncer” automated security check.

In this article, we will highlight several examples of Zombie malware on Google Play we very recently uncovered. These are Called  – “The “Clickers”.They commit another stealthy kind of malicious behavior, that  will likely be overlooked by automated analysis solutions.

“Clicker” is a malware that affects a large part of the mobile ecosystem creating fraud for the vendors, spamming the networks and exploiting the resources of user the community. This form of malware launches requests through Advertizing links. “Clickers” generate costly, false user traffic for advertisers, while draining the user’s battery life and consuming their monthly data plan bandwidth allowances. Everyone loses when a “Clicker” is unleashed.


Screen Shot 2015-07-13 at 3.46.01 PM

Screen Shot 2015-07-13 at 3.46.10 PM


The latest malware we detected is called “Best: Dubsmash”. It has no actual functionality other than a confusing UI. Most users are likely to spend some time to figure out what it does. In the mean time, let’s see what is doing in the background:

Screen Shot 2015-07-13 at 3.47.28 PM


Communicate a C&C server. This server will serve the target URL that needs users to click.

According to our test, this URL will give different URLs each time you refresh it. Most of the URLs are porn sites.

Screen Shot 2015-07-13 at 3.48.05 PM

Our behavioral analysis shows the Zombie requests are generated by using invisible webview calls, in a continuous 20s time interval. There goes the user’s battery life and bandwidth. data plan. Also it will (or rather should) create events on a properly monitored corporate network. Just what your SecOps team needs, right? More Spam remediation.

Screen Shot 2015-07-13 at 3.48.45 PM


As of Jul 13 PST 2:40PM, this app, as well as 3 similar “clickers” are still alive on Google Play. We already reported this issue to our colleagues at Google Play and will look forward to timely remediation.

Screen Shot 2015-07-13 at 6.50.16 PM