Android Pentesting Methodology (Pt. 2)

Android Pentesting Methodology (Pt. 2)

In part 1 of the “Android Pentesting Methodology” series, we briefly discussed the Android architecture. In part 2 of the same series, we’re going to explore what APKs are, start reversing Android applications and discuss popular debugging tools. 

Android is a very developer-friendly platform (OS). Unlike other mobile operating systems, Android is an open-source platform that allows you to activate developer options and sideload apps without too many problems. Furthermore, the Android Open-Source Project allows developers to investigate the source code and tweak the operating system’s functionality as they see fit.  

Working with Android applications necessitates the use of Java bytecode and Java native code. Certain developers may view this as a disadvantage. Android developers use the Java Native Interface to increase app speed, support older code, and, of course, confound people who try to see inside their apps.

What is an APK (Android Package Kit)?

The Android Package with the file extension apk is the file format used by the Android operating system, and several other Android-based operating systems for distribution and installation of mobile apps, mobile games and middleware. We can write apps in either Java or Kotlin.

In other words, the package file format used by Android OS for distribution and installation of mobile apps is known as APK. In Android, APK is the same as .exe in Windows. 

APK (or .apk) is the file extension for every Android application. An Android application is a compressed file that contains all of the materials and code that were utilized in its creation.

When extracting an APK file, it contains the following files:

1) META-INF: This consists of three files – MANIFEST.MF, CERT.SF, and CERT.RSA.

  • MF: This file contains various information that the Java run-time environment uses when loading the .jar file, such as the main class to be run from the jar file, the package’s version, build number, creator, security policies/permissions for Java applets and Java web start packages, the list of file names in the jar along with their SHA1 digests, and so on.
  • SF: This includes a list of all files as well as their SHA-1 digests.
  • RSA: This file contains the signed contents of the CERT.SF file, as well as the certificate chain for the public key that was used to sign them.

2) RES: RES contains resources that are not compiled. Resources are the additional files and static content that your code uses, such as bitmaps, layout definitions, user interface strings, animation instructions, and more.

3) AndroidManifest.xml: Every APK includes a manifest file, AndroidManifest.xml, stored in the root directory of its project hierarchy. Because it describes the structure and information of our application, as well as its components, requirements, and permissions, the manifest file is a most important part of any application.

4) Resources.arsc: Resources that enable app developers to separate content and external files from the application code and maintain them independently. If resources are made configuration aware, strings can be translated and UI layouts can be changed at runtime based on the language settings and screen properties of the device.  

It contains an unreadable file. resources.arsc file that is compiled by the Android build tool chain alongside the actual code. Simple values, such as integers, booleans, and strings, are saved in the resources.arsc file, as are references to more complicated resources, such as UI layouts, which are stored in separate binary XML files.

5) Classes.dex: The classes compiled in the .dex file format understandable by the Dalvik virtual machine.

Android Components

An Android application can incorporate aspects from other apps on the device. If your application uses a scrolling list of photos and another app has created and made accessible a suitable scroller, you can use that scroller to do the task. The system can instantiate and run critical components of Android applications as needed.

When the system needs any components of the app, it must start the components and instantiate the Java objects for that section. There is no single-entry point [main () function] in Android apps. The system can instantiate and run critical components of Android applications as needed.

The following are typical Android application components:

  • Activities
  • Services
  • Broadcast Receivers
  • Content Providers

For more information refer to this link.

Testing Environment

Now the basics are clear so we can set the Testing Environment for pentesting Android applications.

For that, we would need a physical device or else an Android emulator which should be running on the latest android version. 

The tools and apps you’ll need, as well as instructions on how to rapidly set up an Android test lab, are included below.

1) Genymotion

The Genymotion emulator is a virtual device that runs on your computer and functions similarly to a traditional Android emulator. It’s a VirtualBox-based emulator. It supports a broad range of Android versions and can imitate a number of Android devices. Because VirtualBox is compatible on multiple platforms, Genymotion can be run on any platform, including Windows, Linux, and Mac. Genymotion allows you to produce both bespoke and standard device images, both of which are simple to download and use. You can download it by here.

For installing Genymotion, refer to the this blog.

2) Smali

The majority of Android applications are written in Java and compiled into Dalvik bytecode. Dalvik bytecode is formed by first compiling Java code to .class files, then using the dx tool to convert the JVM bytecode to the Dalvik .dex format.

smali code

Smali is an assembler or disassembler for the DEX format used by Dalvik, Android’s Java VM implementation. The syntax is loosely based on dedexer’s syntax, and supports the full functionality of the DEX format.

3) ADB (Android Debug Bridge)

This is the most important tool for connecting to an Android device (emulated or physical).

It lets you operate your device from a computer through USB or network, send data back and forth, install and uninstall app, execute shell commands, backups, and view logs, among other things. The Android SDK includes the Platform-Tools component. It provides tools like adb that interact with the Android platform. These are necessary components for Android debugging, so we must install them. Here’s where you can get the Android SDK Platform-Tools. In order to connect with adb on a physical device, it is important to enable the USB-Debugging option. You can access this by navigating to “Settings >> Developer” options.

Some basic commands for the adb to operate the android devices 

				
					•	adb devices (lists connected devices) 
•	adb root (restarts adb with root permissions) 
•	adb shell install <apk>  (install app) 
•	adb shell list packages (list package names) 
•	adb shell ls (list directory contents) 
•	adb shell path <package> (path to the apk file) 
•	adb shell (starts the background terminal) 
•	exit (exits the background terminal)
•	adb help (list all commands) 
•	adb -s <deviceName> <command> (redirect command to specific device) 
•	adb –d <command> (only sends commands to the USB device that is connected) 
•	adb –e <command> (only sends commands to the emulators that are connected) 
				
			

4) Other Tools

Dex2jar: A command line that decompiles an APK to JAR files or DEX/SMALI format. Dex2Jar converts an APK’s classes.dex file to classes.jar or vice versa. As a result, we can read the source code of an android applications using any java de-compiler. We only get .class files here, not the real Java source code developed by the application developer.

When converting DEX to JAR, you may get an Out of Memory Error if the DEX file is huge. In this case, we must increase the amount of the JVM RAM in the d2j invoke script.

It is also possible to obtain “.smali” files straight from the classes.dex file, and vice versa. That is, with this format, you can directly alter the source code of an application.

ApkTool: A reverse engineering tool for Android applications. It can decode resources to almost their original form and recreate them after certain changes. It also simplifies working with an app due to the project-like file structure and automation of some repetitive operations such as APK creation, decoding, rebuilding JAR file, etc.

Bytecode-viewer: Bytecode Viewer (BCV) is a Java/Android Reverse Engineering Suite that is advanced and lightweight. We can use several open-source tools to power this project. BCV is a supplement that aids in the reversal process.

JEB (trial version): Commercial, very powerful dissembler and debugger, but if you can afford it, it is highly recommended and one of the best tools for reverse engineering Android APKs.

Frida: Grease monkey for native apps and a dynamic code instrumentation toolkit that allows you to hook methods.

Xposed Framework: A powerful framework that allows you to change the APK without changing the code at runtime hooking.

Drozer: Allows you to look for security flaws in applications and devices by taking the role of an app and communicating with the Dalvik VM, the IPC endpoints of other apps, and the underlying OS.

Reverse Engineering Android APKs

Dex2jar

(i) Download the dex2jar tool.
(ii) Provide .dex file as input and convert it into .jar file. Run the following command:

				
					d2j.bat <package-name>
				
			
android

(iii) Launch JD-GUI. You can get it from here.
(iv) Go to File -> Open -> Choose the.jar file to open.

ApkTool

(i) Download ApkTool, give the APK file as input and decompile it using the following command:

				
					apktool d <filename>.apk
				
			

(ii) We can now read the “AndroidManifest.xml” file.

apk tool

(iii) We can also read smali files using a Java decompiler or with VS code.

These steps will help unzip the APK file and convert it into a readable format. In the next blog (part 3) we will be going through the “AndroidManifest.xml” file, along with static and dynamic analysis of Android apps.

By partnering with Redfox Security, you’ll get the best security and technical skills required to execute an effective and thorough penetration test. Our offensive security experts have years of experience assisting organizations in protecting their digital assets through penetration testing services. To schedule a call with one of our technical specialists, call 1-800-917-0850 now.

Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.

“Join us on our journey of growth and development by signing up for our comprehensive courses.