Apktool set-up for Android lab

2013-07-01

John Foremost

Independent researcher, USA
Editor: Helen Martin

Abstract

With a wide variety of e-crime-related threats being discovered every day for Android, the analysis of suspect Android packages is becoming an ever more important task for security researchers. John Foremost introduces Apktool, a very powerful freeware tool for analysing APK files.


The demand for and use of mobile devices – especially those running the Android operating system – are amazingly pervasive in 2013. And a wide variety of e-crime-related threats are being discovered every day for Android, including SMS spam, hacktivism, diallers, banking MiTM attacks, and more.

Analysis of suspect Android packages (APK files) starts with analysing static data, such as a cryptographic hash, and then moves onto freeware anti-virus and sandbox scans, as discussed in [1]. A researcher then typically needs to unpack the app to take a deeper look at permissions, resources, and the code. This article introduces Apktool, a freeware Linux program that is a very powerful tool for analysing APK files.

Introduction to Apktool

The official home page for the Apktool project [2] describes it as a ‘tool for reverse engineering Android APK files’. While it is designed for reverse engineering, using it simply to unpack and convert files can also be very useful, even for a junior analyst. One of its greatest strengths is that it enables the editing of XML in a humanly readable format, and the compiling of an edited app. The project page for this tool is well developed and documented. Its authors encourage users to join them on Freenode #apktool for online chatting. Their website identifies the following requirements for installation:

  • JRE 1.6 (Java Runtime Environment)

  • aapt command in a PATH

  • basic knowledge of SDK, aapt, PATH, smali and the Google search engine may be useful.

That may seem a little intimidating at first, but it basically means you have to have Java and the Android SDK installed. Java is a platform-independent, class-based object-oriented language. ‘aapt’ is short for the Android Asset Package Tool, which comes with the Android SDK by default and is usually configured within the path variable for Linux accordingly. This is important so that Apktool can run properly when calling aapt, so that the operating system knows where to find it. This guide installs a copy of aapt in the same local directory as Apktool so that it can always find the file easily. The Android SDK is found at [3], which provides developers with tools for the building, testing and debugging of apps for Android.

Quick start

Experienced users can follow the quick start steps described below to set up Apktool within 15 minutes or less. Ubuntu is the example OS for installation here:

  1. Install JDK: sudo apt-get install openjdk-7-jre-headless

  2. Download and extract apktool1.5.2.tar.bz2 and apktool-install-linux-r05-ibot.tar.bz2 from the project page.

  3. Change the permissions to allow execution for each file, aapt, apktool, apktool.jar. To harden security, change to Read-Write for the owner and Read-Only for others (chmod 755).

  4. Using root permissions, move the files into /usr/local/bin.

  5. Type ‘apktool’ inside a terminal window to check functionality.

Initial set-up

I downloaded a fresh copy of ubuntu-12.04.2-desktop-i386 for this example, within a VMware environment. Apktool can be installed on Windows, Linux or Mac provided the requirements are met. This article reviews how to set it up in a Linux environment as that is my preference (as well as that of many in the security industry) for automation and analysis of Android code. Users of other operating systems can obtain specific instructions for their OS at the project page [2] as well as following the general guidelines provided in this article.

To get started it’s a good idea to create a snapshot of your OS, if using VMware, so that you can return to the starting point if something goes wrong. Then start the install process by making sure Java is installed.

JRE 1.6 (Java Runtime Environment) is the first requirement. To check whether JRE is installed, enter the following command inside a terminal window: java version. This returns the version number. If it does not exist, or you need to reinstall or update it, you can use the Ubuntu Software Center or apt-get to install openjdk. In a fresh installation of Ubuntu, Java is not installed by default, and a Java version command results in suggestions of a few packages that may be what the user is looking for. While Apktool requires JRE, Java Development Kit (JDK) is a more powerful package, which is aimed at developers, and is a requirement of other possibly related tools and configurations. To install JDK, enter the command ‘sudo apt-get install openjdk-7-jre-headless’ in the terminal.

The ‘sudo’ command shown in Figure 1 requires a password for elevated privileges. Once this is entered a large amount of data is pushed to the terminal. Simply answer ‘Y’ for yes or default settings, as prompted, to download and install the JDK package. Figure 2 shows where the user followed defaults to initiate part of what is downloaded for this package.

To install JDK, enter the command ‘sudo apt-get install openjdk-7-jre-headless’.

Figure 1. To install JDK, enter the command ‘sudo apt-get install openjdk-7-jre-headless’.

Following defaults to initiate part of what is downloaded for the package.

Figure 2. Following defaults to initiate part of what is downloaded for the package.

Naturally, a wide variety of dependencies and various updates may take place during the installation of a package like JDK. Once installation is completed, enter the ‘java version’ command again to get output similar to that shown in Figure 3, confirming it is installed.

Output confirms installation.

Figure 3. Output confirms installation.

Once JDK is set up, the user can install Apktool. However, the project page also notes that SDK with PATH configuration for aapt is needed. On Linux this requires GNU C library (glibc) 2.7 or later and Ubuntu OS 8.04 or later (we are using 12+ in this example). While there are other granular requirements, such as 64 bit environments, a current Ubuntu distribution meets all the requirements to simply install SDK. A download of SDK Tools for Ubuntu is performed from http://dl.google.com/android/android-sdk_r21.1-linux.tgz. Once downloaded, the file is unpacked by right-clicking and selecting ‘Extract Here’ with the mouse or similar methods. The extracted directory should be moved to a desired location, such as the home directory for the current user. This completes the installation of SDK on the file system, although additional configuration updates may take place later through programs that use SDK (which are not covered in this article).

Installing Apktool

The current version of Apktool at the time of writing this article is 1.5.2, released in February 2013. Updates take place regularly, which is great news for anyone that uses it and/or hopes to integrate it into production for analysis of code. Unlike some tools in the freeware market for Android security researchers, which are full of bugs and functionality issues, the current version of Apktool is highly robust and dependable.

Installation, no matter what OS you are using, is a matter of downloading Apktool and the Apktool install files, unpacking them, and then installing it with admin/root permissions. Apktool for your OS can be downloaded from http://code.google.com/p/android-apktool/. In this example apktool-install-linux-r05-ibot.tar.bz2 and apktool1.5.2.tar.bz2 are downloaded for Ubuntu. Extract the contents to reveal three files in total: aapt, apktool and apktool.jar.

Change permissions of the three files to read, write and execute for the owner, and read and execute only for others. (This is a permissions value of 755 for chmod geeks.) Commands like chown and chmod can be used, but in Ubuntu most users will simply right-click on a file, select Properties, and click on the Permissions tab. It is trivial to use this GUI method to assign permissions for each file, as desired (see Figure 4).

File permissions.

Figure 4. File permissions.

Once permissions are set for the files, copy or move them into /usr/local/bin. Elevated rights are needed to do this. Inside a terminal window, type ‘sudo cp filename /usr/local/bin’, where the filename is aapt, apktool, and apktool.jar when run for each file operation. Another easy way is to type ‘sudo nautilus’ inside a terminal window to open up a GUI file system management tool as sudo. If any error messages or dialogs appear they can probably be ignored. Simply browse to the /usr/local/bin directory and then drag and drop the three files into the Nautilus window. When properly installed all three files will be in the appropriate directory:

All three files in the appropriate directory.

Figure 5. All three files in the appropriate directory.

To test Apktool, type ‘apktool’ in a terminal window to see the standard output (Figure 6).

Type ‘apktool’ in a terminal window to see the standard output.

Figure 6. Type ‘apktool’ in a terminal window to see the standard output.

It is not uncommon to try to run the tool for the first time and get an error message along the lines of ‘“apktool” isn’t recognized as a command’. This may indicate that PATH variables are not set up correctly, that files may be missing from the two downloads required for apktool, or that the required support for JRE and SDK are not present. By following the instructions in this article a version of JDK can be installed and validated and SDK can be downloaded and placed in the user directory. Users encountering this error after following such instructions should make sure that all three files exist in the /user/local/bin directory, as shown.

Using Apktool

Using a terminal, simply type ‘apktool’ to run the tool. A common operation is to decompile an APK file to take a closer look at permissions, resources and source code. To decompile an APK file using Apktool, enter the following command: ‘apktool d file directory’.

Figure 7 shows a terminal command for Apktool to decompile a file inside the user ‘code’ directory, with the output to be created in a new folder within that same directory called ‘output’:

Terminal command to decompile a file inside the user ‘code’ directory.

Figure 7. Terminal command to decompile a file inside the user ‘code’ directory.

While it can clutter a terminal window, it can be very quick simply to drag and drop a file and directory for the last two statements of a terminal command. To do this, type ‘apktool d ’ (including the space), and then drag and drop the APK file into the window, enter a space, and then drag and drop the output directory over the terminal window. Another shortcut is to navigate to the local directory (such as ‘code’ in this case), and then press the tab as you type in local filenames so that it auto-completes in whole or in part.

An efficient method is to set up a lab build where code commonly resides, such as a directory within the home directory called ‘code’ or ‘apks’. Then create shell scripts with executable permissions simply to double click and perform the action of the script, such as decompiling all files found within the code directory.

Output of a decompiled APK using Apktool includes a yml file, AndroidManifest.xml, smali, assets, and res directories. Humanly readable decoded XML is a fantastic feature of APKs decoded by Apktool. Additionally, they can be edited and then recompiled/packaged using Apktool, which is also very powerful for analysis and debugging research. An image of a decompiled XML file is shown in Figure 8.

Decompiled XML file.

Figure 8. Decompiled XML file.

A review of the humanly readable XML manifest file for the app analysed reveals two important permissions related to boot and the SD Card. Moghava is an Android threat that ‘stamps’ images on the SD card with a political/religious figure. Apktool makes it easy to decompile and quickly inspect the manifest XML for such permissions and related actions as an analyst begins analysis of a possible APK threat.

Apktool has many other powerful options. One of the most obvious is the ‘b’ option, to build an app from the modified code. This enables a researcher or developer to decompile, modify, and recompile an app which lends itself to a multitude of possible applications. Other parameters exist, such as ‘s’ where only the resources are decompiled and the source code is not, to speed up operations if a developer only desires to make a few changes to resources before recompiling an app.

Apktool also makes it possible to debug smali source code step by step. This is true debugger operational capability which reveals more advanced and powerful features of Apktool. For more information on Smali debugging using Apktool go to [4].

Apktool is a very powerful tool for security researchers concerned with analysing Android threats. Using the steps described in this article, researchers should be able to set it up and start making use of its many useful features.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.