News
Rob Rachwald, Imperva: Mobile Malware Part II
August 2011 by Rob Rachwald, Director of Security Strategy at Imperva
In this 4-part series, Imperva’s Tomer Bitton presents an under the hood analysis of Android malware. This malicious mobile application is distributed via the Android’s application shop market. What does it do? The application captures incoming SMS messages before any other system application. It then posts their contents to a drop server.
Due to this interception behavior, security researchers have been calling it ZitMo – Zeus in the Mobile. But is this in fact the mobile equivalent of the notorious banking Trojan, ZeuS? As the analysis will show, we cannot guarantee the validity of the ZitMo claim due to the following reasons:
The code is not sophisticated
There is no configuration file
There are no encryption methods
That being said, also the first PC-based ZeuS versions were not too sophisticated,
behaving as generic keyloggers. Time will tell.
In the first part of this series, we presented some trends in mobile malware. In this entry, we decompile the application. Part 3 will analyze the application’s code. Finally, part 4 will provide the victim’s view once this malicious application is installed.
Trojan Introduction
The Trojan comes as an Android Application Package Package (.apk) file. The .apk file contains all of the application’s code, resources, assets, and manifest file (click to BIGGIFY):
Those familiar with the apk file format know that an .apk file can be opened and inspected using common archive tools (e.g. 7zip application).
Extracting the .apk file presents us with the list of the following files (click to BIGGIFY):
The interesting file for dissection is the classes.dex file. This is the file which contains the compiled code.
Decompiling the .dex file
In the last mobile malware analysis post, the Smali tool was used to disassemble the dex file. However, in this analysis we use a different method which requires the use of a different set of tools.
As dalvik is based on design of java, it is also susceptible to decompilation. As a first step, we will use the tool dex2jar which converts dex files to jar files. In the second step, a java decompiler, JD, will be used to allow us to view the abstracted code.
What do these classes do? In part III of this series we’ll take a deep-dive into those classes.
