Cracking the Face Recognition Lock on Android

Since Android 4.0 is available, the user has the possibility to unlock his smartphone by looking in the front-camera. This feature is called face unlock.

Just some hours after Google has presented the new Android version including this feature, it was broken by some blogger who just hold a picture of the person the smartphone belongs to in front of the locked smartphone. As a proof, there are plenty videos on youtube. With this demonstration in mind, you have to come to the conclusion that face recognition isn’t a real lock feature, its more a fancy way of the old screen lock were you just have to swipe over the display. Continue reading “Cracking the Face Recognition Lock on Android”

Detailed Analysis of Android.Bmaster

Intro: What is Android.Bmaster?

This new malware-family emerged some weeks ago in third-party Chinese Android-Markets. This malware is taking advantage of the GingerBreak exploit to gain root privileges. This exploit is not embedded into the application, instead it is dynamically downloaded from a remote server together with other malicious apps. This kind of behaviour is similar to an earlier proof-of-concept application called RootStrap, developed by Jon Oberheide back in May 2011.

Android.Bmaster is also known as RootSmart. This name was given to the malware by Xuxian Jiang who found and reported the first samples in the wild.

Analysis of the Application and Its Structure

The app requests the following permissions:

  • android.permission.ACCESS_WIFI_STATE
  • android.permission.CHANGE_WIFI_STATE
  • android.permission.BLUETOOTH
  • android.permission.BLUETOOTH_ADMIN
  • android.permission.WRITE_APN_SETTINGS
  • android.permission.READ_SYNC_SETTINGS
  • android.permission.WRITE_SYNC_SETTINGS
  • android.permission.GET_ACCOUNTS
  • android.permission.VIBRATE
  • android.permission.FLASHLIGHT
  • android.permission.HARDWARE_TEST
  • android.permission.WRITE_SECURE_SETTINGS
  • android.permission.READ_SECURE_SETTINGS
  • android.permission.CAMERA
  • android.permission.MODIFY_PHONE_STATE
  • android.permission.READ_PHONE_STATE
  • android.permission.INTERNET
  • android.permission.RECEIVE_BOOT_COMPLETED
  • android.permission.SYSTEM_ALERT_WINDOW
  • android.permission.GET_TASKS
  • android.permission.CHANGE_CONFIGURATION
  • android.permission.WAKE_LOCK
  • android.permission.DEVICE_POWER
  • android.permission.ACCESS_FINE_LOCATION
  • android.permission.WRITE_EXTERNAL_STORAGE
  • android.permission.ACCESS_NETWORK_STATE
  • android.permission.RESTART_PACKAGES
  • android.permission.DELETE_CACHE_FILES
  • android.permission.ACCESS_CACHE_FILESYSTEM
  • android.permission.READ_OWNER_DATA
  • android.permission.WRITE_OWNER_DATA
  • android.permission.WRITE_SECURE_SETTINGS
  • android.permission.WRITE_SETTINGS
  • android.permission.MOUNT_UNMOUNT_FILESYSTEMS
  • android.permission.READ_LOGS

After the application has been installed successfully, the icon of the app shows up in the dashboard and the application registers some receivers which will trigger when a specific system event occurs (for example: BOOT_COMPLETED, ACTION_SHUTDOWN, PACKAGE_ADDED or NEW_OUTGOING_CALL).

As far as we could detect, you can find all listeners and the corresponding intents afterwards:

  • WcbakeLockReceivecr: USER_PRESENT
  • BcbootReceivecr: BOOT_COMPLETED
  • ScbhutdownReceivecr: ACTION_SHUTDOWN
  • PcbackageAddedReceivecr: PACKAGE_ADDED

After decompiling the dex-file we can see that the application consist of three packages:

  • a – seems to be a SOAP library
  • – the malicious part
  • com.bwx.bequick – the benign part

The Malicious Actions:

  • The app checks if the smartphone is exploitable and if it has been exploited by the app before
  • The application downloads a zip-file (containing an exploit and two helper scripts).
  • Afterwards the malware roots the smartphone and downloads a remote administration tool (RAT) for Android devices.
  • It then connects regularly to the remote server to get new commands to execute (like downloading and installing new apps).

Check Exploit State:

After the application receives a BOOT_COMPLETED event the BcbootReceivecr is called. This receiver broadcasts a new action called action.boot. This action sets an alarm to 60 seconds. After this time periode a new action action.check_live will be broadcasted and the method b.a() will be called.

In this method the OS version is checked against “2.3.4″ and also the existence of a file called shells is checked. If The Android version is smaller than 2.3.4 and the shells-file is not existing, the application calls the method i.a() which we will examine in the next section.

Downloading the Exploit:

You can find the encrypted URL inside the file res/raw/data_3 (ED04FB6CD722B63EF117E92215337BC7358FB64F4166F4EC40C40D21E92F9036). When we decrypt this string using a fixed seed number(stored in the Android manifest file) and provide this number to the Java random number generator, we get the first part of our URL:

When appending the string from the method i.a() to our decrypted URL we get the real download link:

After the malware has downloaded this file, it checks if the md5 is equal to 6bb75a2ec3e547cc5d2848dad213f6d3. Inside this zip-file are three files (install, installapp and exploit) which we will look at in the next paragraphs.

The first file is called install. This script remounts the filesystem in read-write mode and creates a new directory afterwards (/system/xbin/smart). Inside this directory the script creates a root shell and then the filesystem is remounted read-only:

The second script is called installapp. This script is a helper script which is able to write a file anywhere in the filesystem and is able to grant the +s mode to this file:

The last file in this zip-file is called exploit. It’s a GingerBreak version which was compiled out-of-the-box.

Rooting the Smartphone:

In the method f.a() the app executes the helper scripts and exploits the device. Therefore it checks the ExternalStorageState, unpacks the zip-file with the help of the method s.a() and changes the access rights of the files exploit and install to 755. After executing this two files through McbainServicce.class Boolean a() the application deletes some files and tries to clean up:

Due to this process the app is able to install its own shell into the system. With the help of this shell, the app is able to install new packages silently. If the whole rooting process fails, the app will also try to download and install new packages. In this case the system will display a pop-up message to the user and waits for approval.

The Network Action:

The infected smartphone communicates with a remote server and sends a SOAP request to this server when connecting. This request contains a lot of privacy critical information like location, IMEI, IMSI and exact type of smartphone the app is running on (see the excerpt of method g.b() below). After the server responded to this request the smartphone connects regularly to the server to receive further commands.

Some Information About the Corresponding Botnet:

According to Symantec the size of the botnet is between 10.000 and 30.000 active devices which are able to generate a revenue between 1.600 and 9.000 USD per day. Another discovery from Symantec was, that the bonnet is running since September 2011 and is able to push about 27 different malicious apps to an infected device.

Sample Information:



Mobile-Sandbox Report

Detailed Analysis of Android.FakeRegSMS.B

Intro: What is Android.FakeRegSMS.B?

This new malware-family emerged some weeks ago in an unofficial Android-Market. It sends SMS messages to premium rated numbers and tries to hide this action from the malware investigators by using some kind of steganography.

After investigating the app, we would declare this app more as FRAUD than as real MALWARE, because the user gets a “Rules” button where he/she can see that the service will send a SMS message to a premium service.

Analysis of the Application and Its Structure

The app requests the following permission:

  • android.permission.SEND_SMS

After the application has been installed successfully, the icon of the app shows up in the dashboard. (The icon was pixelated due to its content)

The interesting part of the application: Steganography!

The first hint that this app is doing something “strange” appears when you look at the following lines:

Here it seems, that the app is searching for a special string inside a png-picture-file. After searching in the MainActivity we could extract the filename of this png-picture and the responsible lines of code:

The picture that the app tries to load into a byte array, is the application’s icon which can be found in different resolutions in the directories listed afterwards:

  • /res/drawable-hdpi/icon.png
  • /res/drawable-mdpi/icon.png
  • /res/drawable-ldpi/icon.png

When looking at these files with a hex editor we can locate the “tEXt” chunk very quickly. This chunk of data is identical within all of these three png-files. The binary data can be seen in the next picture:

Normally, this chunk is only allowed to contain printable Latin-1 characters and spaces. In our case there is binary data which looks very suspicious under this circumstances. When looking again in the code of the class-file we can find the following code snippet:

These code snippet shows that the app is reading every single byte of the tEXt chunk and is doing a XOR operation with a hardcoded key: f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43

To get the unobfuscated values of the tEXt chunk we are using the python script below.

After running this small python script we receive the following output:

420 100485111? requestNo1 maxRequestNoauto costLimit150 costLimitPeriod8640 smsDelay15 smsData!l5872600885697126387416947526760l4P?=

With this unobfuscated strings, the following few lines of code of the class-file make some more sense:

With the output of our python script we get some values for the variables used in the code snippet above:

  • costLimit = 150
  • costLimitPeriod = 8640
  • smsData = l5872600885697126387416947526760l
  • smsDelay = 15

Looking again in our class-file we can extract this code snippet indicating that the application is trying to send a SMS message:

After we found all these data, we were running the app in the Android emulator to proof our assumptions. When pushing the “Next” button in the main UI (see the picture in the middle of the first figure) the emulator logs an outgoing SMS message:

Decoding the PDU message in this figure we get the following information which is in conformity with our data we encoded from the tEXt chunk of the png-picture:

  • Receipient: 5111
  • Message: 420 10048 l5872600885697126387416947526760l0100

After some investigation, we think that the phone numer 5111 belongs to a service called smscoin, allowing users to donate money to another user via SMS messages. Looking at the “Rules” of the app, the amount of money the user donates to the app author ( is between 15 and 400 Russian ruble.

Sample Information:



Mobile-Sandbox Report