VB2014 paper: Android packers: facing the challenges, building solutions

Figure 1 shows the differences in the file structure of the test application before and after packing by the three providers.

Figure 1. The APK file structure (top left: original APK, top right: file packed with ApkProtect, bottom left: file packed with Ijiami, bottom right: file packed with Bangcle).

(Click here to view a larger version of Figure 1.)

Table 1 lists the files added in the packed APKs, while Table 2 lists the files modified in the corresponding APKs.

Figure 2 displays the code tree of the decompiled classes.dex file for the original APK, and for the file packed with ApkProtect, Ijiami and Bangcle (from left to right, respectively).

Figure 2. Code tree of decompiled classes.dex. From left to right: original, ApkProtect, Ijiami and Bangcle.

(Click here to view a larger version of Figure 2.)

After investigating the code tree of the decompiled classes.dex, we can conclude that ApkProtect is not an Android packing service, but an obfuscating and junk code injecting tool. It is able to encrypt most sensitive strings by using the AES cipher algorithm in the apkprotect2 class, but will not touch the original logic flow and code structures. Therefore, it is relatively simple to analyse and detect applications guarded by ApkProtect.

On the other hand, both Bangcle and Ijiami provide complete packing services. Bangcle supplies a group of standard classes, but still shows encapsulated BroadcastReceiver and Content Provider components from the original classes.dex. Ijiami goes a step further, by replacing the original dex file with its own standard NativeApplication and SuperApplication classes.

Sections 2.1 and 2.2 covered the APK file structure and the code tree of the packed application. However, several key technical issues need to be addressed in order to understand the unpacking process of Ijiami:

Technical issue (1): How to make sure the unpacked code is executed initially.

The key to this technical issue is the Android Application class. The Android reference page [2] describes the Application class as the ‘Base class for those who need to maintain global application state. You can provide your own implementation by specifying its name in your AndroidManifest.xml’s <application> tag, which will cause that class to be instantiated for you when the process for your application/package is created.’ As the context of the entire application, the Application class will be the starting point when executing the program.

When expanding the code tree and taking a detailed view of two standard classes in Ijiami, we found that the SuperApplication class extends Application class accounts to load and run the NativeApplication class, while the NativeApplication class is responsible for loading the native library binary for unpacking (shown in Listing 1).

package com.shell;

import android.app.Application;

public class NativeApplication
{
  static
  {
    System.loadLibrary(“exec”);
    System.loadLibrary(“execmain”);
  }
  
  public static native boolean load(Application paramApplication, String paramString);  
  public static native boolean run(Application paramApplication, String paramString);  
  public static native boolean runAll(Application paramApplication, String paramString);
}

package com.shell;

import android.app.Application;
import android.content.Context;

public class SuperApplication
  extends Application
{
  protected void attachBaseContext(Context paramContext)
  {
    super.attachBaseContext(paramContext);
    NativeApplication.load(this, “com.sophos.andrpacker”);
  }
  
  public void onCreate()
  {
    NativeApplication.run(this, “android.app.Application”);
    super.onCreate();
  }
}

Listing 1: NativeApplication and SuperApplication classes of Ijiami.

Technical issue (2): Where and how to unpack the original dex file, then how to dynamically load the unpacked code.

Lib/armeabi/libexec.so supplies comprehensive code to implement the above functionalities. First, it recognizes and interprets files in the META-INF directory to verify the signature and integrity of encrypted data by using the RSA and AES crypto algorithms, then it decrypts assets/ijiami.dat to the original classes.dex in memory. The library binary then uses the DexClassLoader class to realize the dynamic loading of the unpacked code.

Technical issue (3): Stop runtime anti-debug by modifying the dex header.

When analysing the Ijiami packing service, we discovered that it has the ability to change the original dex header. The modification starts at the beginning of the dex file and runs to 0x28 bytes, filling it with random values. As a result, it can stop runtime debugging to trace the original dex file in memory by searching for DEX_FILE_MAGIC ‘dex\n035\0’. However, this also causes problems for the Volatility project (described in section 4) in locating the original dex file in memory.

This subsection explains the anti-tamper, anti-decompiler, anti runtime injection and anti-debug capabilities of Bangcle, based on detailed reverse engineering analysis. Let us begin with the entrypoint of the source code – the ApplicationWrapper class, as shown in Listing 2.

  public void onCreate()
  {
    super.onCreate();
    if (Util.getCustomClassLoader() == null) {
      Util.runAll(this);
    }
    String str = FirstApplication;
    try
    {
      this.cl = ((DexClassLoader)Util.getCustomClassLoader());
      realApplication = (Application)getClassLoader().loadClass(str).newInstance();
      if (realApplication != null)
      {
        localACall = ACall.getACall();
        localACall.at1(realApplication, getBaseContext());
        localACall.set2(this, realApplication, this.cl, getBaseContext());
      }
}...

Listing 2: Entrypoint of Bangcle source code – ApplicationWrapper class.

The Util class in the entrypoint of the source code implements the main functionalities in the Applications layer of the Android architecture. The functionalities include verifying the integrity of classes.dex, checking if the architecture is x86 or ARM, copying the required native library binaries, encrypted classes.jar, and JNI binary to specific locations, creating child processes, then using the MyClassLoader class to load the decrypted classes.jar at runtime. Listing 3 displays the core method in the Util class.

  public static void runAll(Context paramContext)
  {
    x86Ctx = paramContext;
    doCheck(paramContext); // checking integrity of classes.dex
    checkUpdate(paramContext);
    try
    {
      File localFile = new File(“/data/data/” + paramContext.getPackageName() + “/.cache/”);
      if (!localFile.exists()) {
        localFile.mkdir();
      }
      checkX86(paramContext); // If it is x86 platform, copy related library binary
      CopyBinaryFile(paramContext); // copy encrypted classes.jar and JNI binary 
      createChildProcess(paramContext); // create child processes
      tryDo(paramContext);
      runPkg(paramContext, paramContext.getPackageName()); // call MyClassLoader
      return;
}...

Listing 3: Runall method of Bangcle’s Util class.

Meanwhile, Bangcle’s ACall class deals with binaries such as libsecexe.so in the Android Libraries layer. However, it is impossible to establish a relationship between the Java source code and the libsecexe.so binary since almost all function names in the binary are encrypted (shown in Figure 3). The standard format of the method name should follow the following template: Java_package_class_method, namely the Java package name, class name, then function method name [3].

Figure 3. The function names in the ACall class and libsecexe.so.

(Click here to view a larger version of Figure 3.)

When it is running, the Bangcle-packed application creates three processes (shown in Figure 4) instead of only one process in the original application. Moreover, the three processes in Bangcle are performing ptrace (process trace) so that debugging tools like gdb have trouble connecting them. This is because ptrace in Android limits only one process to observe and examine the trace’s memory and registers. Figure 4 also demonstrates the evidence of mutual tracing in three Bangcle processes [4], [5].

Figure 4. Three processes from a single Bangcle application as well as the anti-ptrace log.

Finally, we summarize Bangcle’s capabilities:

Figure 5 shows a trend line of Android malicious applications based on three packers. Since September 2013, there has been a dramatic increase in the number of malicious applications packed using Bangcle – Bangcle’s scanning engines have not been able to achieve the developers’ aim of avoiding packing malware applications. Meanwhile, the use of ApkProtect and Ijiami has seen a continuous and steady growth over the last five months.

Figure 5. The trend lines of Android malicious applications based on three packers.

Existing RE tools are not able to disassemble the payloads of packed samples due to the anti-decompiler characteristics of packers. The payloads of packed samples are encrypted by advanced cryptographies such as AES and DES. The packing process and the crypto key generation are classified as confidential. Moreover, the algorithms are embedded in the native binaries to make RE much more difficult.

Dynamic analysis systems such as DroidBox, Apk-Analyzer.net and Ijinshan.com [6] are unable to offer successful dynamic results for packed Android applications. The systems either provide very basic static information or simply crash when attempting to start applications. Figure 6 shows screenshots of the running behaviours of the test application in DroidBox and Ijinshan.com.

Figure 6. Neither DroidBox nor Ijinshan.com is able to offer dynamic analysis.

(Click here to view a larger version of Figure 6.)

So far, Android packers present two runtime anti-debug challenges: Ijiami is capable of modifying the dex header to prevent memory searching, while Bangcle prevents anti debugging by creating three interactive processes. Both cause serious consequences for existing debugging tools – even the Volatility project (see section 4).

By taking advantage of Android packers, cybercriminals are able to change an application’s dex file as a means of thwarting signature-based scanners. Even if an anti virus scanner has a database that includes the signature of the original APK sample, it will be unable to detect the newly packed version of the malware. Figure 7 displays a recent SMSSend example, showing the original malware as well as the version packed with ApkProtect.

Figure 7. An original SMSSend sample plus its packed version (packed with ApkProtect).

(Click here to view a larger version of Figure 7.)

In order to perform memory analysis, a copy of the RAM from a target Android device or emulator is required. As Android is based on Linux, a newly developed Loadable Kernel Module (LKM), named LiME (Linux Memory Extractor) [7] is used for acquisition of volatile memory. It is necessary to cross compile LiME for use on an Android device/emulator. Additional steps are required for the prerequisites and environment setting. These steps, which can be found in several online wiki documents ([8], [9], [10], [11]) consist of:

Volatility [12] is a single and cohesive framework for memory analysis of Windows, Linux, Mac and Android systems. It is open source, Python based, extensible and has scriptable APIs. Volatility also pre-ships with a list of very useful plug-ins for Android including Linux_pslist (which gathers active tasks by walking the task_struct), Linux_proc_maps (which gathers process maps for Linux), and Linux_dump_map (which writes selected process memory mappings to disk). However, a working Android Volatility profile with specific module.dwarf and the System.map is required to use these plug-ins. The configuration can be found in [12].

The following is the core part of this paper: a Volatility plug-in is designed to locate the offset of the original dex file in the memory map via a specific process ID (PID). The relevant code of the plug-in is shown in Listing 4.

1 signatures = {
2  ’map_header’ : ’rule map_header { \
3     strings: \
4     $hex = {00 00 ?? ?? 01 00 00 00 00 00 00 00 01 00 ?? ?? ?? ?? ?? ?? 70 00 00 00 02 00} \
5     condition: $hex }’
6 }
7 
8 class apk_packer_find_dex(linux_common.AbstractLinuxCommand):
9  ”””Gather information about the dex Dump in Memory running in the system”””
10
11  def __init__(self, config, *args, **kwargs):
12   linux_common.AbstractLinuxCommand.__init__(self, config, *args, **kwargs)  
13   self._config.add_option(’PID’, short_option=’p’, default=None,
14    help=’Operate on a specific Android application Process ID’,
15    action=’store’, type=’str’)
16
17  def calculate(self):
18   ””” Required: Runs YARA search to find hits ””” 
19   rules = yara.compile(sources = signatures)
20
21   proc_maps = linux_proc_maps.linux_proc_maps(self._config).calculate()
22
23   for task, vma in proc_maps:
24    if not vma.vm_file:
25     if vma.vm_start <= task.mm.start_brk and vma.vm_end >= task.mm.brk:
26      continue
27     elif vma.vm_start <= task.mm.start_stack and vma.vm_end >= task.mm.start_stack:
28      continue
29     elif vma.vm_end - vma.vm_start > 0x1000:
30      proc_as = task.get_process_address_space()
31      maxlen = vma.vm_end - vma.vm_start
32   
33      data = proc_as.zread(vma.vm_start, maxlen - 1)
34
35      if data:
36       for match in rules.match(data = data):
37        for moffset, _name, _value in match.strings:
38         (usize,) = struct.unpack(‘I’, data[moffset - 4 : moffset])
39 
40         i = 0
41         offset = moffset
42         while  i < usize:
43
44          (maptype,) = struct.unpack(’H’, data[offset: offset+2])
45          (mapoffset,) = struct.unpack(’I’, data[offset+8: offset+12])
46 
47          if maptype == 0x1000:
48           yield task, vma, moffset - 4 - mapoffset, moffset
49           break
50          i += 1
51          offset += 12 
52
53  def render_text(self, outfd, data):
54   self.table_header(outfd, [(”Task”, ”10”), 
55           (”VM Start”, ”[addrpad]”), 
56           (”VM End”, ”[addrpad]”), 
57           (”Dex Offset”, ”[addr]”),          
58           (”Map Offset”, ”[addr]”)]) 
59   for (task, vma, offset, moffset) in data:
60     self.table_row(outfd, task.pid, vma.vm_start, vma.vm_end, offset, moffset - 4)

Listing 4: Apk_packer_find_dex plug-in.

In Volatility, each plug-in is able to call another one. Additionally, the results from one plug-in can be provided for further processing in other plug-ins [13]. A plug-in usually consists of a class name and three standard functions [14]: __init__(), calculate() and render_text(). In Listing 4, the class name is apk_packer_find_dex. The first function of the __init__() plug-in is the constructor of the class object with the capability of calling the super class constructor and/or defining additional command line options. The apk_packer_find_dex plug-in specifies a parameter name (--PID), a short option (-p) and help description.

The calculate() function loads an address space, accesses and parses the data, then prepares the output. Line 21 in the calculate() function in Listing 4 gets a process mapping list from a specific PID (the same as /proc/$PID/maps). The list contains the mapped memory regions and the access permissions of the heap, stack, and dynamically linked libraries. Lines 23–33 are a loop to read data from anonymous mappings because the original dex file should be unpacked in one of them. Lines 36-37 utilize a YARA rule to locate the offset of the map_list in the dex file. The YARA rule is declared in variable signatures based on the map_list structure shown in Figure 8.

Figure 8. The header_item and map_list structure in a dex file, and their relationship.

(Click here to view a larger version of Figure 8.)

As discussed in section 2.3, the dex header is modified by the Ijiami packer, the map_list structure is thus a credible alternative for finding the original dex file. We know that the map_items in a map_list should start from TYPE_HEADER_ITEM, then TYPE_STRING_ID_ITEM followed by TYPE_TYPE_ID_ITEM. We also know that the size (count of the number of items) of HEADER_ITEM must be one, while HEADER_ITEM_OFFSET should begin from 0x0000, and header_size is always 0x70. All of these findings help to assign a specific search string for $hex in the YARA rule.

Once the offset of the map_list has been discovered, lines 41–47 in the calculate() function keep scanning map_list to find TYPE_MAP_LIST and the corresponding map_list_offset. Line 48 uses yield to generate a list of outputs including virtual memory start and end offsets as well as the dex and map_list offset in the memory. Finally, the render_text() function accepts the outputs and prints the data on screen in a standard fashion.

We use quotation marks around the word ‘original’ because we can’t acquire the raw dex file: Bangcle inserts its monitoring code into the original dex file before packing, and it is difficult to restore the first 0x28 bytes in the header section for an Ijiami dex file. However, the closest to the original dex file can be acquired using the following four steps:

Figure 9. Patch DEX_FILE_MAGIC back into an unpacked Ijiami dex file.

(Click here to view a larger version of Figure 9.)