Diving into the Android Package File (APK): A Primer for Android Pentesting

This is the first installment of my new Android Pentesting Series. I’ve lately been experimenting with various penetration testing approaches for Android devices and apps. This first part will concentrate only on the Android Package File (APK).

Android Penetration Testing

Mobile or Android Penetration Testing seeks to identify security flaws and verify that mobile apps are not subject to attack. Android applications may be manually or automatically inspected.

Android Package (APK) File Structure

An Android Package (apk) is a collection of files. It includes all of the files (codes and assets) needed to operate the Android application. An APK file for Android is essentially a jar file (java archive), which is just a simple zip file with or without compression. All sorts of Java applications need Jar files. APK files may be unpacked using a variety of methods.

Contents of the APK files –

META-INF

The manifest information and other metadata about the java package contained by the jar file are stored in the META-INF folder. This section contains verification information created when the app is signed. The purpose of these files is as follows –

MANIFEST.MF: It holds different data that the Java run-time environment uses when loading the jar file, such as the main class to be launched from the jar file, package version, build number, package creator, security policies/permissions of java applets and java webstart packages, the list of file names in the jar along with their SHA1 digests, and so on.
CERT.SF: This provides a list of all files, as well as their SHA-1 digests. Contains a list of the names/hashes of the MANIFEST.MF file’s related lines.
CERT.RSA: This file includes the signed contents of the CERT.SF file as well as the certificate chain for the public key used to sign the contents.

Assets

Contains assets that developers bundle with the application, and can be retrieved by the AssetManager (Provides access to an application’s raw asset files; see Resources for the way most applications will want to retrieve their resource data. This class presents a lower-level API that allows you to open and read raw files that have been bundled with the application as a simple stream of bytes.). These assets can be images, videos, documents, databases, etc.

lib

Contains native libraries with compiled code, for different device architectures. This is a subfolder that contains the files that executables require. The files in this subfolder include Java Classes, resource, and image files, as well as the Android Manifest file. In the context of an APK file, the lib folder can contain native libraries that are compiled for different CPU architectures. Here is a list of common CPU architectures that native libraries can be compiled for, along with the corresponding folder names that might be used in an APK file to store the native libraries for each architecture. The native libraries included in an APK file’s lib folder are determined by the app’s requirements and the devices on which it is intended to run. The native libraries in the lib folder may be grouped by CPU architecture, with a distinct folder for each architecture supported by the program.

armeabi: lib/armeabi
armeabi-v7a: lib/armeabi-v7a
arm64-v8a: lib/arm64-v8a
mips: lib/mips
mips64: lib/mips64
x86: lib/x86
x86_64: lib/x86_64

res

Contains predefined application resources, like XML files that define a state list of colors, user interface layout, fonts, values, etc.

AndroidManifest.xml

A manifest file that describes the application’s package name, activities, broadcast receivers, resources, version, content providers, etc. It performs some other tasks also –

It is responsible to protect the application to access any protected parts by providing permissions. (Defining Permissions)
It also declares the android API that the application is going to use.
It lists the instrumentation classes. The instrumentation classes provide profiling and other information. This information is removed just before the application is published.

Elements of the AndroidManifest.xml –

<manifest> – Manifest is the root element of the AndroidManifest.xml file. It has a package attribute that describes the package name of the activity class.
<uses-sdk> – Declares the minimum and maximum API levels that the app is compatible with.
<application> – Application is the sub-element of the manifest. It includes the namespace declaration. This element contains several sub-elements that declare the application component such as activity etc. The commonly used attributes of this element, are icon, label, theme, etc.
- – android:icon represents the icon for all the android application components.
- – android:label represents the default label for all the application components.
- – android:theme represents a common theme for all the android activities.
<activity> – Activity is the sub-element of the application and represents an activity that must be defined in the AndroidManifest.xml file. It has many attributes such as label, name, theme, launchMode, etc.
- – android:label represents a label i.e. displayed on the screen
- – android:name represents a name for the activity class. It is a required attribute.
<intent-filter> – intent-filter is the sub-element of activity that describes the type of intent to which activity, service, or broadcast receiver can respond to.
<action> – It adds an action for the intent-filter. The intent-filter must have at least one action element.
<category> – It adds a category name to an intent-filter.
<permission> – custom permission that can be used by other apps to request access to specific features or data.
<permission-tree> – Declares the parent of a group of permissions.
<permission-group> – Declares a group of permissions that are related to a particular feature.
<uses-permission> – requests permission that must be granted in order for it to operate. There is a list of permission APIs. (Ref: Manifest.permission)
<uses-feature> – Declares a single hardware or software feature that is used by the application.
<instrumentation> – Declares an instrumentation class that runs tests against the app.
<service> – Declare a service as one of the application components
<receiver> – Broadcast receivers enable applications to receive intents that are broadcast by the system or by other applications, even when other components of the application are not running.
<provider> – Declares a content provider component. A content provider is a subclass of ContentProvider that supplies structured access to data managed by the application.
<activity-alias> – Declares an alternative name for an activity that can be used to launch it.
<uses-library> – Declares a library that the app requires in order to function properly.
<meta-data> – Contains additional metadata for the app.

classes.dex

Contains all of the Java classes in a dex (Dalvik Executable) file format, which the Android Runtime will execute (managed runtime used by applications and some system services on android). .dex files contain built Android application code. On the device, Android apps are built into .dex (Dalvik Executable) files, which are then packaged into a single .apk file. .dex files may be generated by automatically translating compiled Java programming language programs. These files have a direct impact on the APK.

We compile the code of the given application, which is written in Java, into class files. Then, we cross-compile these class files (with many optimizations) into the Dalvik VM format, creating the classes.dex file. We may also have some .so files, which are generated when we use the NDK and contain application code. We cannot delete the classes.dex file. When we want to change the code, we need to build the classes.dex again and insert it into the existing zip/apk file. However, doing so will invalidate the existing certificate files in the META-INF folder, so we must delete this folder and resign the apk package in order to install it on a phone or emulator.

resources.arsc

Contains pre-compiled resources. It holds information that will link the code to resources. resources.arsc is a compiled file that contains binary data resources used by an Android app. It stands for “Android Resource System Combined.” The resources stored in this file include things like strings, dimensions, and drawables that are used by the app’s user interface. The file is generated automatically when an app is built.

Example Structure

APK File
|-- META-INF
| |-- CERT.RSA
| |-- CERT.SF
| |-- MANIFEST.MF
|-- AndroidManifest.xml
|-- res
| |-- drawable-hdpi
| | |-- icon.png
| |-- drawable-mdpi
| | |-- icon.png
| |-- drawable-xhdpi
| | |-- icon.png
| |-- drawable-xxhdpi
| | |-- icon.png
| |-- layout
| | |-- activity_main.xml
| |-- values
| | |-- strings.xml
|-- assets
|-- classes.dex
|-- lib
| |-- x86
| | |-- libnative-lib.so
|-- resources.arsc

META-INF folder with the app’s certificate files. AndroidManifest.xml file, the app’s manifest file. res folder with the app’s resources, organized by drawable density and layout. assets folder, which is empty in this example. classes.dex file, which contains the compiled code of the app in Dalvik VM format. lib folder with native libraries required by the app. resources.arsc file, a compiled file containing the app’s resources

Penetrating Networks

Navid Fazle Rabbi

Research Interest