DexInspector

Rewording a quote from a famous film I would say “The Malwares are everywhere, even now in this very room”, and that’s could be true if you have an Android based mobile phone because the number of this kind of malwares are increasing nowadays. It’s not so hard to study an Android malware; there are some nice tools available on the net, and in the foreseeable future I could add my simple DexInspector too.

Why do I need another .dex analyzer? Well, I decided to write this tool because I had some problems dealing with disassembled output produced by some existing tools. Some of them shows an output which is hard to follow because of its syntax that is strictly related to .dex opcodes; on the other hand other tools try to understand what’s behind the code, but it’s really hard with a static analysis and the result may produce ambiguous results. I always use more than one single tool in my reversing sessions, and I think DexInspector could be a valid help for .dex analysis.

Since I don’t like to fill this blog post with a series of anonymous screenshots without a single word, to introduce the tool I’m going to use a malware named “FakeLookout.A” guiding you through a possible reversing session.
You can find a nice description of the malware at http://blog.trustgo.com/fakelookout/ and I’ll explain you how to get this information:

This malware can receive and execute commands from remote server.
Server address: hxxp://[hidden]press.com/controls.php
Commands:
clearFileList
getDir
clearAlarm
getFile
getSize
getTexts

DexInspector

.dex has been fully loaded

This is the main dialog of DexInspector, exactly when a .dex file has been fully loaded.
The box with a series of “[INFO]” entries is used to display information, depending on the current task. In this case it tells us everything has been loaded correctly.  The treeview on the left contains a list of all the .java files declared in the malware project.  Each disassembled class will be showed inside the empty box. The toolbar contains some buttons (used to view necessary information about structures inside a .dex file), a control used to store all the methods inside the current disassembled class and  3 search text controls.

Map list dialog

From the map_list dialog you can have an idea of what the file is. It has a lot of methods, classes and strings (item: method_id_item, class_def_item and string_id_item), so the question is: if I want to understand what’s going on inside the malware, where is a good starting point? The name of the classes and the original files used by the programmer are valid candidates, but like a common reversing session I prefer to start the static analysis directly from strings window, even if there are too many strings.

Selected string with location info

Due to the .dex nature it’s easy to discard useless entries; i.e. you can avoid specific type strings (something like “IILI”), strings starting with ‘L’ or ‘[‘, etcetc.  Among all the strings I see a suspicious address: “http://thelongislandpress.com/controls.php“, the server doesn’t exist anymore so I think I don’t need to obscure the address.
As you can see from the listview at the bottom of the dialog the string is located in a single file named “com.updateszxt.HttpFileUploader.zdi“.
What kind of file is this? It’s the disassembled file and the .zdi is the extension I use, you can find the file on your hard disk too.  Anyway, the name of the original file is HttpFileUploader.java:

Disassembled view: class, fields and constructor

The original file has inside the definition of the public class com.updateszxt.HttpFileUploader which extends java.lang.Object and contains some fields definitions (both static and instance). The http address is used inside the constructor of the class, here is constructor’s code:

Code of the constructor

The program analysis is done instruction-by-instruction involving debug information which are mostly useful when you have to understand the code. In this specific case the program uses debug information in different places, the first one is inside the declaration of the method: the parameters have specific names which are not randomly created.
It’s pretty simple to understand what’s going on. First thing: the method is used to check if a specific folder exists. If the folder, named “dataCache”, doesn’t exist it will be created inside Android external storage directory. Second thing: it initializes an url using the http address above. Nothing special indeed, but before going directly to the next part of the class I wanto to point your attention to an instruction:
  java.io.File folder = v1;
It’s not a line derived from one of the .dex opcodes but it comes from debug information and represents a local variable definition. Nothing special, but dealing with the original name could be handy.
Another addition is represented by the info inside the small box, it shows something depending on the selected instruction. i.e.:
selected instruction:   v2 = v2->append(v3);
info: java.lang.StringBuilder java.lang.StringBuilder->append(java.lang.String)
The meaning of the info is: the method append from java.lang.StringBuilder gets a java.lang.String parameter and returns a java.lang.StringBuilder type.

Ok, back to the code!

Interesting code starts here

Searching through the methods listed in the combo box I select the one named runIt, after a little glance you can understand what’s going on: the program estabilishes a connection with the remote server, it gets a command and execute it. The command is returned by getControls method and it’s one of the six I have mentioned at the beginning of this post (it’s also possible to have a path following the command).

Check for the right command to execute

Except few lines at the beginning of the method the codeflow of the program depends on the invoked command. As you can see from the snippet the command is compared with “clearFileList”, if it’s the one they want to invoke it will be executed otherwise the next command will be checked (“getDir”). This kind of check is done until the right command is not found.

Final words
Malware analysis ends here, there are a some nice methods to explore and I’ll let you discover the rest yourself because I think I have attached too many pictures for a simple program. It’s time to end up with this blog post, you should have an idea of what DexInspector does.
It’s not perfect, but I feel comfortable with it. It’s still under development because I have to test it again and again (bugs are like malwares, they are everywhere!) and I would like to add some more things.
If you think it might help your Android reversing sessions I’ll put it online available for everyone, on condition that you’ll report bugs, comments and criticisms to me, ok? Let me know and don’t expect too much, it’s only a disassembler!