Last week, we have blogged about an Android malware that was impersonating as a popular browser (http://totaldefense.com/securityblog/2011/09/23/The-SMSer-Trojan-Returns-as-Fake-Browser-Again.aspx).
This time we present the analysis of another interesting Android malware to highlight its noteworthy features that users need to be aware of.
This sample shows how easily such kind of impersonating malware is being created to impersonate many popular messengers and chat clients.
It all started, when an interesting view was observed during the proximity view analysis of this malware as illustrated in the fig.1.

Fig.1: Proximity view of the onCreate() function defined in the malicious activity class.
Interested by this view, explored the contents of the resource files present in the android package file.
Not surprisingly, it was observed that the package contains a bunch of icons of popular messenger and chat clients as shown in the fig.2

Fig.2: a look at the multiple icons present in the resource dir of the apk package.
So, what does it do?
As discussed in our earlier blog, this sample also impersonates (in this case, as ISQ client) and while an innocent user is installing this, it silently sends SMS in the background to a message centre and at the end asks the user to download the original software from the legitimate site. The final message (the prompt with the link to the legitimate site) is constructed as a template message. This template gets filled with the appropriate URL from where the current impersonated software can be downloaded.
The code that constructs this template is shown in Fig.3

Fig.3: Template message builder
You can observe that "this.site" (the placeholder of the legitimate website of each software that the malware currently impersonates) gets appended with the template message.
The portion of the code that checks the application name and sets the content view appropriately to suit the impersonation is illustrated in fig.4.

Fig.4: code that checks the appname to set the content view.
Let us quickly verify our analysis by observing the sample in action inside the simulated environment with flow analyzer frameworks.

Fig.5: Permissions requested from the user to authorize the application.
When started, the application sets up a progress bar that claims to be "downloading" the software as illustrated in the fig.6

fig.6: The "download" progress bar
We can see in the code that the sample sends SMS messages when the progress bar reaches 30, 56, 77, 86 as shown in the fig.7

Fig.7: Code that sends SMS
Since, we have setup hooks at various points in the sample so that we gain control when the sample sends out the SMS.

Fig.8: breakpoint hit in the debugging framework.
Fig.9 illustrates the value of the different states of the sample while the breakpoint is hit.

Fig.9: states of the malware captured at a point.
Once the sample completes sending the SMS messages in the background, it prompts the user with a dialog that has the link to download the original software the sample was impersonating.

Fig.10: The template message with the URL to download the software
Also, in this blog, I would like to demonstrate another experiment that was done with this sample. We have instrumented the sample to change the destination SMS number to one of the emulators running in the simulated environment. This way, when the malware sends the SMS messages, the messages will be sent to the emulator running in the simulated environment.Fig.11 shows the result of the instrumentation.

Fig.11: The SMS messages sent from the infected device.
The cases like these clearly reiterate the fact that malware authors take social engineering tricks very seriously and almost all the Android malware cases registered so far involves social engineering tricks. As usual we recommend the users to be aware about these social engineering tricks and pay attention while authorizing applications and always download software from the legitimate market sites and keep your security software up to date.