Decompiled Java Code Manipulation using JEB API – Part 2: Decrypting Strings

This is part 2 of our series of blogs showing how to use JEB’s API to manipulate decompiled Java syntax trees. (Missed Part 1?)

Let’s see how the API can be leveraged to decrypt strings, and plug the decrypted strings back into the source code.

Download the script
Demo video

As shown in the video, we are going to focus on a protected version of Cyanide. The strings are encrypted, and that the decompiled Java code does not look pretty:

    ...
    protected void onCreate(Bundle arg5) {
        super.onCreate(arg5);
        this.setContentView(2130903040);
        if(new File(MainActivity.鷭(-387, -15, 608)).exists()) {
            MainActivity.鷭(MainActivity.鷭(-389, 52, 159));
            MainActivity.鷭(MainActivity.鷭(-333, 37, 17));
            MainActivity.鷭(MainActivity.鷭(-407, 53, 629),
                    MainActivity.鷭(-395, -15, 0), this);
            MainActivity.鷭(MainActivity.鷭(-398, 53, 92),
                    MainActivity.鷭(-386, -15, 586), this);
            MainActivity.鷭(MainActivity.鷭(-402, 52, 102),
                    MainActivity.鷭(-378, -15, 665), this);
            MainActivity.鷭(MainActivity.鷭(-368, 37, 119));
            MainActivity.鷭(this);
            return;
        }

        ...
        ...

MainActivity.鷭(x, y, z) is the decryptor method. The parameters indirectly reference a static array of bytes, that contains the encrypted strings for the class.

Our script is going to do the following:

  1. Search the encrypted byte array
    1. Enumerate the fields of the class
    2. Look for a byte[] field marked private static final
    3. Verify that this field is referenced in <clinit>, the static {…} initializer for the class
    4. The field should also be referenced in another method: the decryptor
  2. Check the structure of <clinit>
    1. It should look like: encrypted_strings = new byte[]{………}
    2. Retrieve the encrypted bytes
  3. The decryptor was analyzed in a previous blog post
    1. The decryptor constants need to be extracted manually (let’s keep the script simple)
  4. Then, for every method of the class, we will:
    1. Enumerate the statements and sub-elements of the AST recursively
    2. Look for Call elements
    3. If the Call matches the decryptor method, we extract the argument provided to the Call
    4. We use these arguments to decrypt the string
    5. Finally, we replace the Call by a newly created Constant element that represent the decrypted string

(Note: The JEB python script is just a little over 100 lines, and took less than 1 hour to write. It could be greatly improved, for instance, the decryptor constants could be found programmatically, but this added complexity is out of the scope of this introductory blog post.)

Here what the deobfuscated code snippet looks like:

    ...
    protected void onCreate(Bundle arg5) {
        super.onCreate(arg5);
        this.setContentView(2130903040);
        if(new File("/data/last_alog/onboot").exists()) {
            MainActivity.鷭("rm /data/last_alog/*");
            MainActivity.鷭("cat /system/etc/install-recovery.sh > /system/etc/install-recovery.sh.backup");
            MainActivity.鷭("su", "/system/etc/su", this);
            MainActivity.鷭("supersu.apk", "/system/etc/supersu.apk", this);
            MainActivity.鷭("root.sh", "/system/etc/install-recovery.sh", this);
            MainActivity.鷭("chmod 755 /system/etc/install-recovery.sh");
            MainActivity.鷭(this);
            return;
        }
        ...
        ...

In part 3, we will show how to defeat a complex obfuscation scheme used by many bytecode protectors: reflection.

Decompiled Java Code Manipulation using JEB API – Part 1: Removing Junk Code

This is the first post of a 3-part blogs series that will demonstrate the new features of JEB’s jeb.api.ast API package.

Classes of this package allow read and write access on the Abstract Syntax Trees (AST) of the decompiled Java code produced by JEB. In a  nutshell, it allows power users to implement complex deobfuscation schemes or their own optimizations strategies.

Download the script
Demo video

Let’s jump straight to the crux of the matter: this piece of code has been obfuscating by a well-known Android/Java protector software:

/*.method public constructor (Context, AttributeSet, I)V
          .registers 8
          const/4                 v3, 0x1
          const/4                 v2, 0x0
          invoke-direct           View-&amp;amp;gt;(Context, AttributeSet, I)V, p0, p1, p2, p3
          new-instance            v0, Paint
:E
          packed-switch           v3, :90
:14
          packed-switch           v2, :A0
:1A
          goto                    :14
:1C
          invoke-direct           Paint-&amp;amp;gt;()V, v0
          iput-object             v0, p0, TileView-&amp;amp;gt;b0431бб0431б0431:Paint
:26
          packed-switch           v2, :B0
:2C
          packed-switch           v2, :C0
:32
          goto                    :2C
:34
          sget-object             v0, xxxkkk$xkkxkk-&amp;amp;gt;b04310431б0431б0431:[I
          invoke-virtual          Context-&amp;amp;gt;obtainStyledAttributes(AttributeSet, [I)TypedArray, p1, p2, v0
          move-result-object      v0
          const/16                v1, 0xC
          invoke-virtual          TypedArray-&amp;amp;gt;getInt(I, I)I, v0, v2, v1
          move-result             v1
:4C
          packed-switch           v2, : D0
:52
          packed-switch           v2, :E0
:58
          goto                    :52
:5A
          packed-switch           v2, :F0
:60
          packed-switch           v3, :FC
:66
          packed-switch           v3, :10C
:6C
          goto                    :66
:6E
          packed-switch           v2, :11C
:74
          packed-switch           v3, :12C
:7A
          goto                    :74
:7C
          packed-switch           v2, :13C
:82
          sput                    v1, TileView-&amp;amp;gt;bб0431ббб0431:I
          invoke-virtual          TypedArray-&amp;amp;gt;recycle()V, v0
          return-void
          .packed-switch 0x0
              :E
              :1C
          .end packed-switch
          .packed-switch 0x0
              :1C
              :E
          .end packed-switch
          .packed-switch 0x0
              :34
              :26
          .end packed-switch
          .packed-switch 0x0
              :34
              :26
          .end packed-switch
          .packed-switch 0x0
              :5A
              :4C
          .end packed-switch
          .packed-switch 0x0
              :5A
              :4C
          .end packed-switch
          .packed-switch 0x0
              :60
          .end packed-switch
          .packed-switch 0x0
              :4C
              :6E
          .end packed-switch
          .packed-switch 0x0
              :4C
              :6E
          .end packed-switch
          .packed-switch 0x0
              :7C
              :4C
          .end packed-switch
          .packed-switch 0x0
              :4C
              :7C
          .end packed-switch
          .packed-switch 0x0
              :82
          .end packed-switch
.end method*/

JEB decompiles this Dalvik bytecode to the following Java code:

    public TileView(Context arg5, AttributeSet arg6, int arg7) {
        super(arg5, arg6, arg7);
    label_3:
        switch(1) {
            case 0: {
                goto label_3;
            }
            case 1: {
                goto label_6;
            }
        }

        while(true) {
            switch(0) {
                case 0: {
                    goto label_6;
                }
                case 1: {
                    goto label_3;
                }
            }
        }

    label_6:
        this.b0431бб0431б0431 = new Paint();
    label_8:
        switch(0) {
            case 0: {
                goto label_11;
            }
            case 1: {
                goto label_8;
            }
        }

        while(true) {
            switch(0) {
                case 0: {
                    goto label_11;
                }
                case 1: {
                    goto label_8;
                }
            }
        }

    label_11:
        TypedArray v0 = arg5.obtainStyledAttributes(arg6,
                xkkxkk.b04310431б0431б0431);
        int v1 = v0.getInt(0, 12);
    label_15:
        switch(0) {
            case 0: {
                goto label_18;
            }
            case 1: {
                goto label_15;
            }
        }

        while(true) {
            switch(0) {
                case 0: {
                    goto label_18;
                }
                case 1: {
                    goto label_15;
                }
            }
        }

    label_18:
        switch(1) {
            case 0: {
                goto label_15;
            }
            case 1: {
                goto label_21;
            }
        }

        while(true) {
            switch(1) {
                case 0: {
                    goto label_15;
                }
                case 1: {
                    goto label_21;
                }
            }
        }

    label_21:
        switch(0) {
            case 0: {
                goto label_24;
            }
            case 1: {
                goto label_15;
            }
        }

        while(true) {
            switch(1) {
                case 0: {
                    goto label_15;
                }
                case 1: {
                    goto label_24;
                }
            }
        }

    label_24:
        TileView.bб0431ббб0431 = v1;
        v0.recycle();
    }

As one can see, dummy switches as well as pseudo-infinite loops have been inserted within the original Java code, in order to produce flow obfuscation. Using the AST API, we’re going to implement a JEB plugin that cleans the obfuscated code.

1

A dummy switch construct looks like the following:

switch(X) {
case X:
  goto next;
case Y:
  goto label_fake1:
case Z:
  goto label_fake2:
}
...
next:

The above piece of code is equivalent to:

goto next;
...
next:

Which can be reduced to a single label:

next:

In order to find the dummy switches, the JEB script is going to do the following:

  1. Recursively enumerate the statements of a method body, looking for SwitchStm elements
  2. Check that the switch is a dummy switch:
    1. The switched expression must be a Constant
    2. The case block associated with that constant must start with a Goto statement
  3. Replace the switch by the goto
  4. Find the first Label that follows the (now replaced) switch
  5. If a label is found, is at the same block level as the switch, and is the label pointed to by the goto that replaced the switch, then all the expressions between the goto and the label can be discarded
  6. Finally, apply standard JEB optimizations that remove the remaining useless gotos and labels

This algorithm fits in a less than a 100-line Python script. Download the script, experiment with it, and get accustomed to the API.

The cleaned-up code is this very simple, more readable method:

    public TileView(Context arg5, AttributeSet arg6, int arg7) {
        super(arg5, arg6, arg7);
        this.b0431бб0431б0431 = new Paint();
        TypedArray v0 = arg5.obtainStyledAttributes(arg6,
                xkkxkk.b04310431б0431б0431);
        int v1 = v0.getInt(0, 12);
        TileView.bб0431ббб0431 = v1;
        v0.recycle();
    }

In Part Deux, we will show how the AST API can be leveraged to decrypt encrypted strings of a protected piece of code.

Android OBad decompiled sources

This threat was initially reported by Kaspersky and seems to have gathered quite some amount of attention lately.

I’m attaching the sources decompiled by JEB 1.2 to this post, for analysts who’d like to take a look at it. One particularity of OBad: it’s been protected by a well-known commercial obfuscator (which was briefly mentioned here and there). This protector employs generalized string encryption and calls methods through reflection, which makes raw source code a bit difficult to read – the sources have not been refactored and marked-up, the usefulness of it all is very limited: you be warned.

Archive: obad_decomp.zip

Sample MD5: f7be25e4f19a3a82d2e206de8ac979c8

Edit (June 11)

Jurriaan Bremer was kind enough to provide oboy.dex, a version of OBad with encrypted strings replaced by their decoded versions. JEB handles the file okay, despite the multiple string duplicates (which is one of the reasons why it could not be loaded on a phone.) I’ve attached the decompiled sources for his version below. (I also disabled the try-catch support for improved clarity.)

Archive: oboy_decompiled.zip

JEB’s decompiled sources for Android/BadNews.A

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

SMS Spy ZertSecurity with decompiled, analyzed Java sources

The implementation of this Android malware is strong and clean. Nothing really innovative though.

0

Here’s a short summary:

  • Masquerades as a German certificate installer app. The fake login/pin is used to uniquely identify the phone (on top of the phone number and IMEI.)
  • Achieves SMS interception, most likely to break 2-factor authentication. There are 3 modes of operation: do nothing, intercept and proceed, intercept and cancel SMS broadcast.
  • Multiple command-and-control servers. Two hard-coded domains are hxxp://app-smartsystem.(com|net)/sms/d_m009.php
  • The C&C urls can be updated, either by contacting the existing the existing C&C, or via SMS sent by the master. Such SMS contain the string “&Sign28tepXXX”.
  • The communication with the C&C is encrypted using AES-ECB, with the static key “0523850789a8cfed”. The server also base64-encodes its payloads. (The client does not.)
  • The malware will try to start at boot time (BOOT_COMPLETED receiver), and also registers a 15-minute timer to query the server for updated C&C urls.

 

1

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

A look inside an Android app protector

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:

1

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.

2

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.

3

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.

Help for the Bluebox challenge

The Bluebox fellows have posted an interesting Android crackme a few days ago.

The APK presents several oddities, including:

  • APK entries marked as password-protected.
  • Reuse of java.lang.String to confuse tools and analysts.
  • Some basic cryptography in the APK.
  • The most interesting part: a native library that replaces the bytecode for the custom String.add() upon loading the main activity class

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.

addbc

After reassembly, JEB decompiles the real String.add() to clean code: (marked-up in the screenshot below)

addfixed

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.

Bad Java decompilation means erroneous statement in research paper

Back in July 9, 2012, Martin Georgiev et al. published a paper entitled “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software” (download) that points out broken SSL certificates validation in various applications and third-party libraries.

One of the case studied is the Chase mobile banking app for Android. It turns out the version studied by the authors was 2.5 or earlier, released on April 23, 2012. (The APK can be found on Android-Drawer.) In paragraph 10.1, the authors wrote:

“Decompilation and analysis of this app’s code show that it overrides the default X509TrustManager. The replacement code simply returns without checking the server’s certificate. The code below is the result of reverse-engineering, thus variable names and other details may differ from the actual code.”

While the first statement is true (X509Certificate.checkServerTrusted() is overriden), the second is false. The claim was made because of improper decompilation to Java:

public final void checkServerTrusted(X509Certificate[]paramArrayOfX509Certificate,    String paramString)
{
  if ((paramArrayOfX509Certificate != null)
    && (paramArrayOfX509Certificate.length == 1))
    paramArrayOfX509Certificate[0].checkValidity();
  while (true)
  {
    return;  // makes checkServerTrusted unreachable
    this.a.checkServerTrusted(paramArrayOfX509Certificate, paramString);
  }
}

The decompiled code is incorrect: the “while(true) { return; …” is a misconstruct that lets the reverse engineer believe that this.a.checkServerTrusted() is never called.

Unfortunately, the authors relied in part on this faulty piece of Java code to claim that:

“Note the unreachable invocation of checkServerTrusted. We conjecture that this was a temporary plug during development that somehow found its way into the production version of the app.

Chase [is] completely insecure against a man-in-the-middle attack.”

Note that the conclusion that Chase is insecure to MiTM attacks is not disputed here. Martin Georgiev confirmed that the app was tested and was vulnerable to such attacks.

The authors may have run out of time and probably skipped the Dalvik bytecode verification step.

In fact, the routine in question is pretty simple, and JEB decompiles it to a clean:1

Now, it looks clear that the original checkServerTrusted() gets called, if and only if the certificates’ array is null or the array does not contain just one certificate.

Decompilation is not a guaranteed process, but one should use professional tools to minimize exposure to bugs. A manual check of the low-level bytecode or assembly is also a requirement before making claims that a particular code path is or is not executed.

Thanks to Juliano Rizzo for pointing out this potential issue.

Japanese Contact Stealer

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…”:

2

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:

3

4

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”.

5

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:

  • for-loop optimization
  • string concatenation
  • aggressive variable substitution

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.

6

Find the decompiled activity here: solution.newsandroid.MainviewActivity

Sample MD5: ba73e96caa95999321c1cdd766bdf58b

Korean SMS Interceptor

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.

1

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.

3

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.

4

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.

5

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.