This Android malware was referenced in a recent blog post (http://www.xchg.info/?p=46) and I thought analysts would be interested in checking out the decompiled bytecode.
Java files for live.photo.savanna and com.androways.advsystem: BadNewsA_Src.zip
Sample MD5: 98cfa989d78eb85b86c497ae5ce8ca19
The implementation of this Android malware is strong and clean. Nothing really innovative though.
Here’s a short summary:
The APK was run through a name obfuscator. I’m attaching the sources decompiled using JEB 1.1, and with most of the refactoring/renaming/commenting work done. For JEB users, here is the JDB file. Enjoy.
Sample MD5: 1cf41bdc0fdd409774eb755031a6f49d
Continuing part 1, let’s have a look at another feature, assets encryption.
Let’s have a look at an app containing a protected asset, 1.png. The hexdump below shows the encrypted 1.png. The PNG header is gone, as this is the encrypted version of the file.
The decryption routine is easy to spot: it appears the AssetManager.open() call was replaced by inline code that uses encrypted strings and reflection to instantiate a Cipher class and decrypt the asset file. We will use the script from the previous post to decode the strings and determine exactly what is happening. The screenshot below shows the decompiled routine in question, after it was marked up and commented using JEB (try-catch have been disabled for improved clarity, as they do not help understand how the routine works):
The references to the AssetManager class, open method, asset filename 1.png as well as cipher type AES-CFB have been encrypted using the string encryption feature. The decryption is achieved using standard Android classes, and the scheme used is AES with a random key and IV (outlined in red in.)
The final call to InputStream.available() is actually what the original method was doing. Therefore, the protection mechanism replaced AssetManager.open() by the following section of code:
We conclude that manually restoring protected assets is not difficult, although it cannot be easily automated. One way to improve that protection scheme would be to use custom decryption routines instead of SDK-provided classes, and/or generalize the use of reflection to reference the decryption code.
Let’s have a quick look at one feature of this well-known Android application protector, the string encryption mechanism. The app in question is a version of Cyanide.
First, access to strings inside a protected class are replaced by calls to a static private decryption routine. That routine accesses a static private array containing all protected strings within the class. That array is created by the class initializer upon loading:
The decryption routine usually takes 3 arguments, although in some simpler cases, it may only take two arguments. The arguments may also be shuffled. (Note: from a Dalvik standpoint, that routine is oddly structured. Although JEB’s decompiled output is structurally fine, a for-loop construct cannot be created, mainly because of the irregular jump inside the first if-cond branch.)
The screenshot below represents that decryption routine. The name was obfuscated by the app protector. Notice the constant numerals that have been circled in that code snippet: they are the decryption routine characteristics.
The following screenshot shows the same piece of code after marking it up. As you can see, the encryption algorithm is fairly simple: the current output character is derived from the previous character as well as the current byte of the encryptedStrings array. A constant (-8 in this case) is added to yield the final character. The initial length (length) as well as initial character (curChar) are also offset by hard-coded constants. These three constants (0x3E, 0x199, -8) characterize the decryption routine, and are unique for each routine. The curChar parameter acts as the decryption key.
You may customize this Python script to decrypt the strings:
#!/usr/bin/python
# decryptor
# customize
strings = [0x4C, 0xE, 2, 9, -7, 0x10, -54, 0x3E, 0x17, -9, -44, 0x4C, 0xA, ...]
c0, c1, c2 = (0x199, 0x3E, -8)
def decrypt(length, curChar, pos):
length += c0
curChar += c1
r = ''
for i in range(length):
r += chr(curChar & 0xFF)
curEncodedChar = strings[pos]
pos += 1
curChar = curChar + curEncodedChar + c2
return r
Combined with reflection (another feature of the protector), the protection can be pretty effective.
The Bluebox fellows have posted an interesting Android crackme a few days ago.
The APK presents several oddities, including:
As Jurriaan Bremer pointed out, the replacement bytecode in question can be found at offset 4004h of libnet.so, and is E0h bytes long. The original String.add() is only A6h bytes long, and references exception handlers. Replacing the bytecode is not trivial, but annoying.
After reassembly, JEB decompiles the real String.add() to clean code: (marked-up in the screenshot below)
I’m providing the sources for both com.bluebox.lab.poc.Action and the fixed java.lang.String if you want to complete the challenge.
Enjoy.
Let’s have a quick look at a variant of Android.Uracto, an app that steals (and potentially spams) contacts from Android devices. There is nothing particularly interesting about this piece of malware, but it’s the occasion to demonstrate some of JEB less-known and forthcoming abilities.
Upon startup, the app displays the following spinner, that translates to “Reading the articles…”:
The onCreate() method for the main activity displays the above spinner, and also starts a new Thread, that will create and run a Progress object. Here it is:
The run() method will call postMailList(). This method gets the ContentResolver for the app, and enumerates all entries having the “vnd.android.cursor.item/name” MIME type. According to the documentation, these entries represent “contacts’ proper names”.
A buffer representing the data1, data2, and data3 fields (respectively, Display Name, Given Name, and Family Name) is dynamically created.
[JEB specific]
Notice the optimizations that allowed the creation of that compact construct:
Some of these optimizations are already present in 1.0.x, others will be included in the 1.1 versions.
[/JEB specific]
The final data (“contact1, contact2, …”) is dumped on the external memory storage, encoded and POST’ed to hxxp://jap2012.com/data/main.php.
Find the decompiled activity here: solution.newsandroid.MainviewActivity
Sample MD5: ba73e96caa95999321c1cdd766bdf58b
Let’s inaugurate this blog by looking at a fairly simple piece of Android malware, an SMS interceptor app whose prime targets are South Korean users.
The app impersonates a Starbucks coupon (스타벅스 쿠폰) app.
Let’s check the decompiled Java code.
When the user starts the app, it displays a fake error message, indicating that the server is out-of-service, and terminates. In the meantime, it has registered and started the malicious service com.catchspam.catchservice.
Notice that a preference variable “runYN” is set to “execute” (실행.) More on it later.
The malicious service does two things:
– First, it registers the cellphone number by POST’ing it to hxxp://it7980.com/Android_SMS/installing.php. (If the number is Korean and starts with the prefix +82, it receives “special treatment”.)
– Then, it registers a BroadcastReceiver meant to process incoming text messages.
The BroadcastReceiver com.catchspam.catchsms2 processes SMS_RECEIVED intents. The last PDU is processed and (supposedly) contains the text message.
In the following screenshot, notice that the author implemented a minimal C&C-like behavior:
– If the text reads “execute”, the runYN preference variable will also be set to “execute”.
– If the text matches the “magic passphrase”, that variable will be set to “pause”. (It roughly translates to: “Back and forth the same versus luck ♥ Lee ♥ ♥ Please call 1588-1588”.)
Later, runYN is checked and the interception procedure will bail if it is not set to “execute”. This allows the author to enable/disable the interception, either globally or for specific phone numbers.
The intent broadcast is cancelled to prevent other apps (and eventually, the user) from processing the SMS. Finally, the message is POST’ed to the author’s server. The data format is “mobile=<number>&revsms=<textmessage>”.
SMS stealers can be simple annoyance or steal personal data. In this case, it might be used to capture 2-factor authentication codes sent by online banking websites.
Download the sample here.