Wednesday, December 28, 2011

Android Malware Analysis - Static Analysis of HolyF******Bible

You can get the Trojan on Contagion Malware Dump site
http://contagiodump.blogspot.com/2011/03/take-sample-leave-sample-mobile-malware.html
Direct Link
http://www.mediafire.com/?z4296jczsx4jc3d

Begin by renaming the .apk file to a zip file. This gives access to the contents of the .apk file.

We can see the classes.dex file. 


Let’s use Dex2Jar on the Classes.dex file to get access to the application code.



Don’t start exploring the code as yet. It is always better to have the AndroidManifest.xml file handy when exploring the code. So let’s get it using AXMLPrinter.

Its always better to have a look at the AndroidMannifest.xml file to start with. It gives an idea what kind of permissions the app is asking from the user. 

The manifest file for the current app indicates a few interesting things.
The app has requested permissions for the following 
Read and send Sms
Access Contact information
Understand when the device boots
Set wallpaper 

Its always good to have an eye open for components or modules mentined in the manifest file and check the workings of that module in the class files
For instance, receiver android:name="com.YahwehOrNoWay.PostingServiceReceiver" which we see in the manifest file can also be seen in the code obtained from the .dex file. 



If we inspect the code closely we can see that the app keeps a check on when the device boots itself. Perhaps it triggers something when the app boots?

Looking at the manifest file gives a feeling that the component ‘YahwehOrNoWay’ will have a lot of juicy stuff. Let’s explore it more in the code.
The app is creating a service named ‘theword’. This would keep running in the background and probably monitor the device for trigger events.


If we inspect the code below, it gives an indication that the app runs its operations at fixed time intervals.


Close inspection of another piece of code gives an indication  of another trigger point.


localStringBuilder1.toString().matches("05212011"))
This indicates that the date 21/05/2011 is a trigger event for this particular app. If you have been following the news this date has been prophesized to be **drum rolls** The day the world ends (again). It was stated by radio host Harold Camping that this day marks the Rapture and Judgement Day. This is another indication of how much the malware writers use Social Engineering.

Another trigger point is specific messages sent to the app. There are four such cases

Case I : String "formula401"

This commands instructs the trojan to send contact information to a file hosting site 'turbobit'.

Case II: String "pacem"

This command instructs the trojan to send a download recommendation to all contacts on the phone.

Case III: Date is 05/21/2011

The trojan creates a database mydb.db when it detects that the date is 21 May 2011.
It adds some values to the database and sends these values as a reply whenever an SMS is sent to the device
I wanted to show this behavior in real time on two simulators but sadly this behavior was not being replicated. I will surely try again and update.
Also, the wallpaper is changed as shown in the code below

Case IV: Date is 05/22/2011

The trojan replies a message 'Looks like Jebus is a no show, maybe Judaism was on to something' to any SMS received by the device.

Also, the wallpaper of the device is changed as shown in the following code.

As you can see the trojan is fairly capable of many things, most prominent includes sending vital information about the contacts present in the phone to the author thereby stealing sensitive information. Also the trojan spreads by enticing people present in the contact list to download the same app thereby spreading even more.

Thursday, December 15, 2011

Reverse Engineering Tutorial #1

Here we will try to remove a nag screen. The term nag screen essentially refers to a screen or banner which is displayed when a particular tool/ program runs. This usually comes at the start of the program with some message. In this tutorial I will show one such example.

The application we are looking at is a third party Calculator.

When we open the application we see a Nag screen for a brief period. Our aim would be to remove this nag screen for appearing when we run the program


The nag screen is sort of a dialog box, so it makes sense if we say that its part or a component of the program. So it makes sense if we think that somewhere in the code the author would be instruction the program to display this dialog box, or in other words, "Push" this dialog box on the screen. This is a important thing to remember regarding this program.

Now there are tools which show different parts or components of a program, to help us understand the program in a better way. One such tool which we will be using is ResourceHacker.

Open the executable in Resource Hacker and we can see different parts of the program.


The component of our interest here is the 'Dialog'. Expand it and we can see Dialog Boxes which make the program.

As you can see, clicking on each Dialog entry shows the corresponding code and the output which enables us to see how the dialog looks in the program. Now where is that pesky nag screen ....



Aha!!! here it is. Note that this Dialog has a number 105. This is the decimal representation for this dialog box. The Hex equivalent would be 69. So essentially we are looking for something like "PUSH 69" in the code for the program. So lets find it.

Open the program in our favorite Disassembler, Olly Debug



Right click and search for 'Command' and enter PUSH 69


Once you see where the nag screen is being pushed onto the screen, we can simply out NOP statements there. NOP essentially means No Operation so the processor is idle at these instructions. So no push, no nag screen.



Now save the changes made


Once saved, try running the executable. Much to our joy, we don't see any nag screen now.


So there you have it, a nag free Calculator program =).

So the key learnings from this tutorial would be:
  • Examining a program and identifying a particular part or component which we want to remove
  • Calculating and locating the probable code responsible for the nag
  • Finally removing it so that it is not a nag anymore

Crack Me, You learn

Reverse Engineering applications is a very daunting task. We have to go through a huge labyrinth of numbers and letters, just to make little sense of what is actually going on.

Even if we know most of the theory which supports the field, its never enough until we practice on actual running executables. To help us out of this jeopardy we have nifty executables called CrackMe's.

Crackme is a small executable which is generally made for the purpose of learning Reverse Engineering. The goal of the authors is to create an executable small enough and simple enough to teach a thing or two about Reversing executables and yet be simple and small enough that students/ practitioners don't get overwhelmed by data.
Think of it as a sort of assignment/ challenge for a student of this field.

There are a number of sources where these CrackMes can be found. I will list just few of them and keep adding as and when I find more.

Along the same lines you will find a number of 'Reverse Engineering Tutorials'. These are not so different than CrackMes. Main difference here is that the authors of these tutorials use small programs and executables which are very old so that there is little or no issue of the makers of those programs complaining. Again these are an excellent source to learn and improve your Reverse Engineering skills