Category: Android

Analysis of Android.Golem downloader component

Recently, we came across a new malware which seems to be a module of a recent Android trojan named dubbed Golem.

Golem has been found in several countries and hundreds of thousands of phones have already been infected, according to reports.

We performed detailed analysis of the malware using JEB, the operations achieved by the malware can be divided into several steps:

Step 1

When user start the phone or unlock the screen or light the screen, the malware will automatically download a file named “conf_plugin.txt” which contains configuration information like “update”, “md5”, “url”, etc.

Step 2

Then the malware will check if there is a jar file named “ic.jar” in phone memory, if not or if its md5 is different from the md5 in “conf_plugin.txt” (which means the local dex is different from the dex in remote server), malware will download the dex.

Step 3

After that, the malware will install and run the dex and execute the “onCreate” function in the “com.facebook.mini.service.RunService” class.

The complete process can be represented by the graph below:

Based on the analysis, the malware can automatically download, launch and run application without user’s authorization. The downloaded apps will run with the set of permissions already requested by the downloader:

Through this malware, the attacker can easily get your personal information, contacts or even bank accounts and passwords. Also, the attacker can remotely control your phone to open specified application and perform some bad operations to make illicit profits.

Sample SHA256:
3cb7a4792725d381653fcca18d584f9fbe47d67f455db03e3c53e8e8e7736385

Analysis by Ruoxiao Wang

Deobfuscating Android Triada malware

The Triada malware has received a lot of news coverage recently. Kaspersky was one of the first firm to publish an analysis of this Trojan earlier last week.

The code is obfuscated, and most strings are encrypted. The string encryption algorithm is trivial, but ever-changing across classes: bytes are incremented or decremented by constant values, either stored in a default decryptor method, or retrieved via calls to other methods. The result is something quite annoying to handle if you decide to perform a serious static analysis of the file.

Encrypted string buffers in Triada. Decryption routines can be seen in the decompiled class on the right-hand side.

Our intern Ruoxiao Wang wrote a very handy decryption script for Triada. It needs customizing (the decryption keys are not automatically retrieved) on a per-class basis, but the overall effort is a couple of seconds versus hours spending doing tedious and repetitive semi-manual work.

The script will decrypt the encrypted byte arrays and replace the decompiled Java fields supposedly holding the final strings by their actual value, as seen in the picture below.

Decrypted strings. Comments (in the left-side red box) indicate the string use was not found via xrefs. The right-side red box shows updated String fields after decryption.

The script can also be used as a tutorial on how to use the JEB Java AST API to look for and modify the AST of decompiled code.  (More examples be seen on our GitHub sample script repo.)

Download the Triada decryptor script here:
TriadaStringDecryptor.py

(Specific instructions are located in the script header.)

Setting up JEB2 to parse optimized DEX (odex) files

This blog assumes that JEB version 2.1.0 or above is used along with the OAT plugin 1.0.2 or above.

Parsing support for optimized DEX files was added to JEB2 to allow the analysis of non-deodex’ed files. Since ODEX files are target-dependant, the executing Dalvik VM is no longer restricted to regular opcodes. ODEX files may make use of “illegal” opcodes, optimized opcodes, or even the once regular but now dead extended opcodes. Whenever possible, parsing will take place, and instructions displayed in the assembly view.

In the screenshot below, note that opcode  43h (illegal for non-optimized code) is used, as well as iput-wide-volatile (optimized opcode for field access).

In that second screenshot, notice the use of a non-standard jumbo opcode.

If you are analyzing an extracted ODEX file (one whose header bytes start with “dey\n”), then all versions of JEB2 shall be able to process it. The Project tree will look like the following (project > artifact > odex unit > dex unit):

If you are analyzing an OAT file (DEX file precompiled to native and ready to run within the ART runtime), then you will need one additional plugin: the OAT plugin. This plugin can be registered on Business and Enterprise versions of JEB2. (Note: older versions of JEB 2.0, mainly versions 2.0.12 and above, require the third-party ELF plugin as well.)

Installation steps:

  1. Visit our public GitHub account
  2. Download the latest package of the OAT plugin
  3. Drop the JAR file in the coreplugins folder within your JEB2 installation directory
  4. Restart JEB2. The lines “Plugin loaded … OATPlugin” should be visible in the console
The OAT plugin is loaded (the ELF third-party plugin is no longer required with JEB 2.1+)

Now, you may open an OAT file. The project view should be similar to the following (project > artifact > elf unit > oat unit > dex or odex unit):

Here is another example of an ELF file containing an OAT section, containing 2 optimized DEX files:

An ELF/OAT file containing 2 DEX files

That is it for this blog post. We are planning to release more documentation and tutorials about our APIs In the coming days. In the meantime, remember to check our open-source plugins on GitHub, they are great starting points for anyone interested in writing their own parsers or back-end plugins. Stay tuned, and happy analysis.

Android Dalvik, inside OAT, inside ELF

As a follow up to our last blog on Adobe PDF and Microsoft XLS plugins for JEB2, here is another example of deep analysis support in the case of nested artifacts, as is the case for Android pre-compiled native apps.

Those apps are run using ART, the newest Android Runtime. They are native Linux ELF .so files, embedding a custom Android OAT file, which in turns contains one or more Dalvik DEX bytecode files. See the pictures below for an example:

jeb2-elf-oat-1 jeb2-elf-oat-2

 

The ELF and OAT plugins will be open sourced.

Stay tuned for more news within the next few days!

 

Red October Malware for Android

Blue Coat Systems recently released a paper about the Inception APT (also dubbed Cloud Atlas, it may be connected to the Red October APT). One component of this APT is an Android trojan, masquerading as a Whatsapp update package. It is able to record audio calls, as well as gather, encrypt and exfiltrate user information.

The 4 strings partially written in Hindi that have been speculated on are those:

redoctober-android-img1

redoctober-android-img2

redoctober-android-img3

For researchers wanting to have a peak inside the APK, we are providing JEB decompiled Java code for one such sample.

Download is here: cloudatlas-android-malware-decompiled.zip

FinFisher FinSpy Mobile app for Android decompiled

The fully decompiled code and assets of 421and.apk can be found here: FinSpyMobileAndroid-decompiled.zip (no password).

This particular APK, although not the latest, is not obfuscated and easily reveals most capabilities of the malware:

  • Location tracker
  • Information stealer (calendar, contact list, text messages, Whatsapp databases, etc.)
  • Remotely controlled through encrypted communication over SMS and data

A great recap of the full story can be read on Netzpolitik. Real time updates are on Twitter.

Decompiled Java code for Android MisoSMS

Yesterday was eventful on the Android malware front. After Mouabad reported by Lookout, FireEye reported MisoSMS. It might also have been reported by Sophos at roughly the same time.

The malicious application is used in several campaigns to steal SMS and send them to China, according to FireEye’s blog post.

Many of you would like to examine and study its code, that’s why I uploaded an archive with the source code decompiled by JEB 1.4, as well as a cleaned-up manifest. Link: MisoSMS_JEB_decomp_20131217

misosms_mainact

Decompiling Android Mouabad

Lookout has an interesting article about Android Mouabad. Yet another Korean SMS malware!

The APK fully decompiled by JEB 1.4 can be found here: mouabad_JEB_decomp_20131217.zip. I haven’t refactored or commented the code, these are raw decompiled classes.

mouabad_sms_receiver

Sample MD5 68DF97CD5FB2A54B135B5A5071AE11CF is available on Contagio.

JEB 1.3: How to Sign and Match Third-Party Library Code

JEB 1.3 ships with two plugins that allow users to create signatures for library code, and apply signatures onto DEX files. (Note: we are not talking about digital signatures here, but rather, binary strings that are used to identify a method or body of code.)

Combined with the new navigation bar, portions of a DEX file that contain third-party frameworks (such as those ubiquitous ad libraries) or already analyzed code, can be easily identified: such areas will be marked using a light-green color in the navigation bar.

Applying signatures

In practice, applying signatures is extremely easy:

1- Load the file in JEB: as can be seen below, the navigation bar is mostly blue, which means no library code has been spotted yet. (Note: The orange marks identify public constant fields – public static final.)

1

2- Fire up the Library Recognition plugin. (Menu: Action / Custom Action / Library Recognition.)

2

3- By default, the plugin looks for library signature files (*.sig extension) stored in the “sigs” sub-directory.

4- The signatures are applied where they can be applied, and the results are visible both in the navigation bar (the light-green portions) and the console window. Here, many Google AdMob routines were recognized; it appears they make up for more than half of the entire DEX file.

3

Close examination of the navigation bar shows that it is divided into two parts:

  • The upper half concerns methods and fields.
  • The lower half concerns classes as a whole.

Due to how the matching algorithm works, an entire class may be marked as library code, when not all corresponding methods and fields may be.

Creating signatures

JEB ships with library signatures for popular Google and Android frameworks. But it is also extremely easy to create your own library signatures.

Let’s take an example. That same APK file contains the Android Support classes; let’s sign them.

1- Execute the Signature Generator plugin. (Menu: Action / Custom Action / Signature Generator.) Note that the plugin may also be executed from the command line and take arguments from the command line, in Automation mode. This is particularly useful for bulk signature creation.

4

2- The plugin asks the user for two pieces of information:

  • The library name: it is recommended to use the format “<libraryname>-<version>”. Here, we will go for: android-support-13
  • The regular expression that identifies which methods should be signed. We want to sign all methods of the android.support.v4 package, so we will input: Landroid/support/v4/.* (Java internal name convention)

After proceeding, the plugin signs the target code. The signing results appears in the Console window:

5

3- The signature file is created in the “sigs” directory. Later on, when you apply signatures to other DEX files, the android-support signatures will be automatically checked and matched against those DEX files.

If you were to re-apply signatures to the currently examined APK file, the android-support methods and classes would obviously be matched, and the navigation bar would reveal that most of this APK is library code:

6

In a future blog post, we will spend some time describing how the signing and matching algorithms work. Keep in mind the library code signing/matching system is plugins-based, which means it can be customized or tweaked by JEB users. Just have a look at the ApplySigs.py and GenSig.py files in the plugins directory if you’re curious about that.

Stay tuned.