Detailed Analysis of Android.Bmaster

Your ads will be inserted here by

Easy AdSense Pro.

Please go to the plugin admin page to paste your ad code.

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

%d bloggers like this: