DADA Week 9 Writeup

This week’s speakers were Alex Hinchliffe and Fernando Ruiz from McAfee Security. This week’s topic was on Mobile Security, specifically Android.

Fernando went through a lot of slides introducing us to the structure of the Android OS.

Lab 1

Our first lab was a look at a Trojan SMS for Android using Static Analysis. Just to recap, static analysis is doing code/application analysis without executing the program we are looking at. We were provided two APK files, RU.apk and TapSnake.apk. APK stands for Android package kit, which is exactly what it sounds like, an app that’s bundled up for use on Android systems. Inside the apks were other files, such as a META-INF directory, the certification information, an AndroidManifest.xml, which is unreadable because it’s encoded. It is readable with APKTool.

We loaded the tools in the terminal with the command: “java -jar ~tools/apktool_2.0.0rc3.jar d RU.apk -o FirstCase”.

Using APKTool we could see the activities that RU.apk had, which was just to send an SMS message. Apparently it was supposed to be a basic Hello World message. There were also references to a MoviePlayer, but we didn’t really go into that. Hello World is a basic exercise/activity which most programmers do when learning or demonstrating basic syntax of a language or application.


Basic “Hello World!” program written in Java.

Another tool was dex2jar, which converts .dex files to .jar files. Jar files are for Java programs, and dex are compiled Java files written for the Android system.

Using a long command: “sh ~/tools/dex2jar/ classes.dex” we could create a .jar file for the classes.dex file found inside the RU.apk. We could now look at each of the individual .class files used to create the .jar. Class files are objects used by the Java object oriented language to create objects out of code. Then we used jadx.gui to open the jar file, which contained 4 classes, DataHelper, HelloWorld, MoviePlayer, and R. These files were in plain Java, which we could understand better than “smali”, which .dex is compiled as.

Inside the Hello World class, we could see that it was sending 3 SMS messages, which is definitely not what Hello World programs should be doing.

Lab 2

Our second exercise was dynamic analysis using the Eclipse IDE and emulator. Dynamic analysis is looking at code while actually running it. We were also shown the Android Security Wiki, which listed tools used regarding Android security, such as tools for dynamic analysis, reverse engineering, etc. Some of the tools we used today were on it as well.


Starting the Virtual device.

We were able to spoof some SMS messages to and from our infected device. We could see that anything we entered in one device was popping up in the
“hacker’s” device. Inside the AndroidManifest.xml, we could see there were a lot more permissions being used. Apparently there was even more than we were seeing, because we were allowed to see the one we were looking at.


We learned about a family of Android malware named FakeInstaller, which is a fake Android installer for specific apps like Skype or Opera, seen around 2012. What it really did was send SMS messages to premium-rate numbers. It is distributed through various websites and fake app markets. What made it interesting was that it was the first Android polymorphic server side android malware. That means that the server would change the files being provided to the client, instead of being polymorphic on client side.

A lot of Facebook profiles and Twitter accounts would tweet or contact people trying to get people to click on it. There were also fake Instagram webpages set up to get people to download it. Of course because it was based in Russia, all of these webpages and profiles were in Russian. The malware basically had a button that sent the premium rate message whether or not the button was pressed.


The various faces of FakeInstaller.

The APK/DEX file had a different IP address, but functionally remained the same, the only things that changed were various texts or strings. They would try to change various things about each individual APK such as having similar photos but changing the size of it. Another method they did was “obfuscation”, which is obscuring something. They would have the dex files have different numbers of class files, but the code functionality would perform the same way.


A Chinese distributed app, usually functional, but had malicious payloads. This was seen around September 2011. It did some advanced things like removing security software, invoking methods using java reflection, and fetching commands from encrypted public logs. Two notable functions this malware did was use DexClassLoader and Java Reflection. DexClassLoader uses an API to load classes from .jar and .apk files containing a classes.dex entry, which executed code which was not originally a part of the application. Malicious code could be downloaded by clean apps and executed. Java reflection allows instantiation of new objects and methods, which was usually used to access hidden features. Instantiation is the creation of new classes or objects in a system.

Day2 lab 1

This lab was focused on Android obfuscation, once again, we had to use Eclipse and a malicious APK. The XML files were encoded once again. Opening the dex file with dex2jar revealed that the classes were bjorked and were could not read any of it, due to obfuscation. There were tons of classes, but inside of them, they were say “INTERNAL ERROR” or the classes would have messed up Java code. To fix this, we would have to go to the decompiler code in the smali compiler but remove the obfuscation code, then recompile. The tool we would have used for this is JEB, but due to licensing issues, Fernando had to show us a Youtube video on it instead of demoing it in person. JEB is a reverse engineering decompile for Android applications.

We created another Android device(Nexus S) and installed Obad.apk onto it using the terminal. There was an issue with loading the apk on the device, so we had to go to the smali file and remove “goto_0” instructions. Starting the device again, we can see “Movie Player” in the apps list. Once the 5556 instance of the emulator has started, we could now start Movie Player, which sent a SMS message to the “hacker’s” device. The point of this malware was to make money for the hacker, which seemed to pay off because of how easy it is to spread this fake app.


Gettin’ money.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s