Category Archives: JEB1

JEB Jar Plugins

Maintenance release 1.5.201408040 introduces support for Java Archive (Jar) plugins. Unlike Java scripts/plugins, running JEB using a JDK is not required, as the Jar plugin already contains compiled code.

Jar plugins allow for complex, multi-class plugins, and referencing external libraries is easy via Manifest entries.

The plugins/ sub-directory of your JEB installation directory contains a sample JAR plugin (SamplePluginJar.jar) as well as the associated source code (SamplePluginJar-src.zip). You can use this plugin’s source code as a template for your own Jar plugins. The build.xml file is a simple Apache Ant build file used to compile source files (located in src/) and package the generated *.class files into a single Jar, with appropriate JEB-specific Manifest entries set up.

About JEB-specific Manifest entries: unlike single source (Python, Java source) plugins, that define plugin metadata with a special comment line (#? for Python, //? for Java), Jar plugins use Manifest entries prefixed by JebPlugin- to define those entries:

  • JebPlugin-entryclass: (mandatory) set to the class that contains the plugin entry-point
  • JebPlugin-name: (optional) plugin name (as it will appear in “Action / Custom Actions…” menu)
  • Jeb-Plugin-shortcut: (optional) keyboard shortcut
  • JebPlugin-help: (optional) help information
  • JebPlugin-author: (optional) plugin’s author information

The above values can be set up by customizing the build.xml Ant file. Also, just like stand-alone Jar files loaded by the Java VM executable, the Manifest entry Class-Path can be set to reference external Jar files or repository of *.class files. Those entries will be added to the class path when JEB loads the plugin.

Please let us know on the forum if you have any question.

Using the AST Tagging API

JEB version 1.5.201404100 introduces new methods to the AST IElement objects, attachTag() and retrieveTag(). These methods allow an API user to tag elements of Abstract Syntax Trees. When a tagged tree is rendered (that is, when decompiled Java code is being generated), tags are processed and provided to the user alongside the decompiled code, with associated text coordinates (line, column). Within the API documentation, a “located tag” is referred to as a mark.

One example use case: Tagging nodes of an AST can be useful if the yielded source code is of specific interest, and potentially require follow-up human analysis.

The example below shows how one can navigate a Class tree, looking for specific calls to findViewById:

def processTree(e):
  if isinstance(e, Call) and e.getMethod().getName() == 'findViewById' and ... :
    print 'Tagging Call element:', e #e.getMethod().getName()
    e.attachTag('testTag', 'Calling interesting findViewById')
  if e:
    # recursively process sub-elements
    for e1 in e.getSubElements():
      processTree(e1)

sig = ...
ast = self.jeb.getDecompiledClassTree(sig)  # assume the class was decompiled
processTree(e)

The Class tree can be rendered by calling the newly introduced overloaded decompile(sig, is_class, regenerate, marks) method:

marks = []
decompiled_class = self.jeb.decompile(sig, True, False, marks)
print marks

Remember to set regenerate to False since you want to avoid re-decompilation (doing so would generate a new, tag-less AST).

The marks array will contain the precise locations (lines and columns) of each tag within the decompiled_class text buffer.

Hopefully, this simplistic example showed you how to use the new AST tagging methods. Happy reversing and code analysis.

Developing JEB plugins in Java with Eclipse

This tutorial explains how to configure an Eclipse IDE project to develop JEB plugins efficiently.

1 – Create a regular Java project. In this example, the project is named JEBPlugin.

2 – Add jeb.jar to the Build path. Edit the project Build path (right-click, Build Path, Configure Build Path…).

Select “Add External JARs…“, add select jeb.jar located in your JEB/bin installation folder.

3 – Attach the API docs to the JEB jar file. Unfold the newly added “jeb.jar” entry, click Javadoc location, then Edit.

Point to either the online Java doc at https://www.pnfsoftware.com/jeb1/apidoc or use an offline Javadoc archive, either present in your JEB installation folder (typically, doc/apidoc.zip), or downloaded from https://www.pnfsoftware.com/jeb1/downloads.

4 – You’re done! You can now develop native Java JEB plugins. Remember that the main plugin class must be in the default package (ie, no package), and implement jeb.api.IScript. This blog contains several How-to’s on plugin development. You will find even more examples on our Download section on the main website.

Decompiled Java Code Manipulation using JEB API – Part 3: Defeating Reflection

This is the third and final part of our series of blogs showing how to use JEB’s API to manipulate decompiled Java syntax trees. (See Part 1, Part 2.)

Today, we will show how to leverage the API to defeat the main obfuscation scheme used to protect the infamous OBad trojan: generalized reflection.

Want a visual TL;DR? Have a look at the following demo video.

Download the scripts: 1, 2, 3
Demo video

Reflection is a powerful feature used by interpreted languages to query information about what is currently loaded and executed by the virtual machine. Using reflection, a program can find references to classes and items within classes, and act on those items, for example, execute methods.

Example:

java.lang.System.exit(3);

can be rewritten to:

java.lang.Class.forName("java.lang.System")
        .getMethod("exit", Integer.TYPE).invoke(null, 3);

Combined with string encryption, reflection can seriously bloat and obscure a program, slowing down the reverse-engineering process.

Based on the above code example, it appears that a solution to remove reflection code automatically or semi-automatically is both useful and realistic. Let’s see how we can to achieve this goal using JEB’s AST API.

As said in the introduction, consider the Android trojan OBad. The video shows the use of a preliminary script to decrypt the scripts. Refer to the script ObadDecrypt.py linked above; we won’t cover the details of string decryption here, as they have been covered in a previous blog.

After string decryption, OclIIOlC.onCreate looks like the following piece of Java code:

    protected void onCreate(Bundle arg9) {
        Object v1_2;
        Object v9;
        super.onCreate(arg9);
        if(Class.forName("android.os.Build").getField("MODEL").get(null).equals(new String(CIOIIolc.IoOoOIOI(CIOIIolc.cOIcOOo(IoOoOIOI.cOIcOOo("cmA4"), CIOIIolc.cOIcOOo("ÞÜëÇØÚâØÞÜÄØåØÞÜéê×èêÉÛè".getBytes())))))) {
            System.exit(0);
        }

        Context v0 = OcooIclc.cOIcOOo;
        Class v2 = MainService.class;
        try {
            v9 = Class.forName("android.content.Intent").getDeclaredConstructor(Class.forName("android.content.Context"), Class.class).newInstance(v0, v2);
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        try {
            Class.forName("android.content.Intent").getMethod("addFlags", Integer.TYPE).invoke(v9, Integer.valueOf(268435456));
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        Context v1_1 = OcooIclc.cOIcOOo;
        try {
            Class.forName("android.content.Context").getMethod("startService", Class.forName("android.content.Intent")).invoke(v1_1, v9);
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        v1_1 = this.getApplicationContext();
        try {
            v1_2 = Class.forName("android.content.Context").getMethod("getPackageManager", null).invoke(v1_1, null);
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        ComponentName v0_2 = this.getComponentName();
        try {
            Class.forName("android.content.pm.PackageManager").getMethod("setComponentEnabledSetting", Class.forName("android.content.ComponentName"), Integer.TYPE, Integer.TYPE).invoke(v1_2, v0_2, Integer.valueOf(2), Integer.valueOf(1));
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        this.finish();
    }

Let’s remove reflection. The steps are:

  1. Recursively walk the AST and check the statements
    Note: we could enumerate all elements instead, however, the script is intended as a demo, not an exhaustive solution to this problem
  2. Look for Call statements (eg, foo()), or Assignments whose right part is a Call (eg, r = bar())
  3. Check if the Call matches the following nested Call pattern:
    Class.forName(…).getMethod(…).invoke(…)
    Note: the script does not take care of class instantiation or field access through reflection, for the same reasons stated above.
  4. Extract the reflection information:
    1. Fully-qualified name of the class
    2. Method name and prototype
    3. Invocation arguments
  5. Create a new method, register it to the DEX object
  6. Create a Call element that accurately mirrors the reflection calls
    Note: There are limitations, especially considering the return type
  7. Finally, replace the reflection call by the direct method call

A deobfuscated / “unreflected” version of the source code above looks like:

    protected void onCreate(Bundle arg9) {
        // ...
        // ...

        try {
            v9.addFlags(Integer.valueOf(268435456));
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        Context v1_1 = OcooIclc.cOIcOOo;
        try {
            v1_1.startService(v9);
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        v1_1 = this.getApplicationContext();
        try {
            v1_2 = v1_1.getPackageManager();
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        ComponentName v0_2 = this.getComponentName();
        try {
            v1_2.setComponentEnabledSetting(v0_2, Integer.valueOf(2),
                    Integer.valueOf(1));
        }
        catch(Throwable v0_1) {
            throw v0_1.getCause();
        }

        this.finish();
    }

We can now remove the try-catchall. This is what the third script is doing.

At this stage, the value and potential of the AST API package should have been clearly demonstrated. We encourage users of JEB to experiment with it, tweak our sample scripts, create their own, and eventually contribute by sending us their useful deobfuscation and/or optimization scripts. We will be happy to make them available to our user base through the Resources page.

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->(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->()V, v0
          iput-object             v0, p0, TileView->b0431бб0431б0431:Paint
:26
          packed-switch           v2, :B0
:2C
          packed-switch           v2, :C0
:32
          goto                    :2C
:34
          sget-object             v0, xxxkkk$xkkxkk->b04310431б0431б0431:[I
          invoke-virtual          Context->obtainStyledAttributes(AttributeSet, [I)TypedArray, p1, p2, v0
          move-result-object      v0
          const/16                v1, 0xC
          invoke-virtual          TypedArray->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->bб0431ббб0431:I
          invoke-virtual          TypedArray->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.

JEB Plugin How-To: Jump to an Activity

The API that shipped with JEB 1.3 allows direct access to the Android Manifest. Here, we are just demonstrating how some of the new methods that shipped with the API. This plugin allows a user to jump from an Activity tag in the manifest to the corresponding code in the Assembly view:

#? name=Jump to an Activity, shortcut=Ctrl+Shift+J

from jeb.api import IScript
from jeb.api.ui import View
from jeb.api.ui import CodePosition


class JumpToActivity(IScript):

  def run(self, jeb):

    # basic requirements
    ui = jeb.getUI()
    if not ui:
      return

    if jeb.getApiVersion() < 2:
      print 'Please upgrade to JEB 1.3'
      return

    ui.focusView(View.Type.MANIFEST)
    v = ui.getView(View.Type.MANIFEST)
    if not v:
      print 'No Manifest'
      return

    # whole copy of the Manifest
    text = v.getText()

    # retrieve the package name
    pname = ''
    pos = text.find('package="')
    if pos >= 0:
      pos += 9
      pos1 = text.find('"', pos)
      if pos1 >= 0:
        pname = text[pos:pos1]

    # the Activity name should be the on-caret item
    aname = v.getActiveItem()
    if not aname:
      print 'Please position the caret on the Activity name'
      return

    # absolute class classname
    if aname.startswith('.'):
      if not pname:
        print 'Package name not found'
        return
      aname = pname + aname

    ui.focusView(View.Type.ASSEMBLY)
    a = ui.getView(View.Type.ASSEMBLY)
    if not a:
      print 'No Assembly view'
      return

    # internal class name
    classname = 'L' + aname.replace('.', '/') + ';'
    if not a.setCodePosition(CodePosition(classname)):
      print 'Class not found: '+aname
      ui.focusView(View.Type.MANIFEST)

Feel free to experiment with the script, and customize it to your needs. Leave a comment if you have any questions. More sample scripts will be posted in the next week to showcase more other capabilities of API v2.

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.