Analysing Backdoor.AndroidOS.Obad.a

Today i am going to write about my own analysis of “The Most Sophisticated Android Trojan which Kaspersky Labs blogged about here.

I’ve managed to grab a copy of the sample from Mila Parkour
I’ve placed a copy of the sample here and the pw to the archive is “infected“.
MD5: F7BE25E4F19A3A82D2E206DE8AC979C8

For this particular Android malware, if you simply use dex2jar+JD-GUI, you will realised that most of the methods can’t be decompiled.

Furthermore, i’ve realised that the method which it managed to decompiled looked slightly wrong too.
This is the method which i will discuss for now

Initial Analysis:
I will go through with my manual approach as well

Basically for a start, i would recommend you to use apktool first.

You should see something like this after running the above command.

Now let’s take a look at the AndroidManifest.xml file, you should see the the permissions requested by the APK file like here.

From the AndroidManifest.xml, we also know the following
1.) This malware have several “service” entries.
Furthermore, if we look up we can see that it indicates to have a high priority.
2.) There is an Activity entry and under the “intent” tag of this Activity entry. It indicates to start as the main entry point according to

According to the official diagram from Android, we should be looking at “OnCreate” function first.

3.) Earlier on, i’ve written that there are several “Service” being started by this app. According to We should be looking at “OnCreate” or “StartService” in those class file(s).

This “Service” is running in the background even when the user is not directly interacting with the application.

Analysis of Dalvik Code:
Normally i would suggest looking at the “onCreate” function first. Iin order to have a better understanding of Dalvik byte code, it’s probably better to have either of the following 2 links:

Now before we go to “OnCreate“, earlier on i’ve mentioned that Dex2Jar screwed it up right.
According to the AndroidManifest.xml, the file with “android.intent.action.MAIN” intention is OclIIOlC. But let’s look at “cOIcOOo” method in this smali file, “OclIIOlC” first.

In order to understand better, it would be preferred to take a look at the original smali code and then this one which i have added with comments.

Now compare it with this snippet which i’ve attached here. This should be the way to reverse the Dalvik Opcode back to Java source code…i think.

Ok, i’ve also mentioned before on why AVs and some of the tools don’t work.
Most of the better Android malware nowadays uses Reflection API.
Reflection can allow a program to create a “function pointer” and invoke the target function by using it. You can see it’s common usage in ExploitKits or those Java exploits.

You will see it when you start reversing “OnCreate” function now.
This is the pseudo Java source code for “onCreate” which i have decompiled manually.

We can see from the pseudo Java code that all external methods are called via Reflection.
Now if you go through each class, you will discover that each class had it’s own way of decrypting the strings but the general logic is quite similar.
Now that we have gone through the decrypting method and the onCreate method. The rest of the class files are not a problem. :D

I’ll update this blog post as i reverse it as it’s tiring to reverse it while changing diapers in between. xDDD

[ Gunther ]