MobileHackingCheatSheet
Basics on commands/tools/info on how to assess the security of mobile applications
Top Related Projects
The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
The Leading Security Assessment Framework for Android.
Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
The Mobile App Pentest cheat sheet was created to provide concise collection of high value information on specific mobile application penetration testing topics.
A big list of Android Hackerone disclosed reports and other resources.
Quick Overview
The MobileHackingCheatSheet repository by Randorisec is a comprehensive collection of resources, tools, and techniques for mobile application security testing and hacking. It covers both Android and iOS platforms, providing a valuable reference for security professionals, penetration testers, and mobile app developers interested in improving their app's security.
Pros
- Extensive coverage of both Android and iOS platforms
- Regularly updated with new tools and techniques
- Well-organized structure, making it easy to find specific information
- Includes both free and commercial tools, providing options for different budgets
Cons
- Some sections may lack detailed explanations or examples
- Requires a good understanding of mobile security concepts to fully utilize
- May not cover all the latest vulnerabilities or techniques in rapidly evolving mobile security landscape
- Some linked resources may become outdated or unavailable over time
Note: As this is not a code library, the code example and quick start sections have been omitted as per the instructions.
Competitor Comparisons
The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
Pros of owasp-mastg
- Comprehensive and detailed guide covering various aspects of mobile app security
- Regularly updated with contributions from a large community of security experts
- Includes practical examples and code snippets for better understanding
Cons of owasp-mastg
- Can be overwhelming for beginners due to its extensive content
- Requires more time to navigate and find specific information
- May contain some outdated information in less frequently updated sections
Code Comparison
MobileHackingCheatSheet:
adb shell pm list packages | grep -i 'keyword'
owasp-mastg:
PackageManager pm = getPackageManager();
List<ApplicationInfo> packages = pm.getInstalledApplications(PackageManager.GET_META_DATA);
for (ApplicationInfo packageInfo : packages) {
Log.d("App", "Installed package: " + packageInfo.packageName);
Log.d("App", "Source dir: " + packageInfo.sourceDir);
Log.d("App", "Launch Activity: " + pm.getLaunchIntentForPackage(packageInfo.packageName));
}
The MobileHackingCheatSheet provides a concise command for listing packages, while owasp-mastg offers a more detailed Java code snippet for retrieving and logging installed package information.
The Leading Security Assessment Framework for Android.
Pros of drozer
- Comprehensive Android security assessment framework
- Actively maintained with regular updates
- Supports a wide range of Android vulnerabilities and attack vectors
Cons of drozer
- Steeper learning curve for beginners
- Requires more setup and configuration
- Limited to Android platform only
Code Comparison
MobileHackingCheatSheet provides a collection of commands and techniques:
adb shell pm list packages
adb shell pm path com.example.app
adb pull /data/app/com.example.app-1.apk
drozer uses a custom console for executing commands:
run app.package.list
run app.package.info -a com.example.app
run app.package.attacksurface com.example.app
MobileHackingCheatSheet offers a quick reference for various mobile hacking techniques across platforms, while drozer provides a more focused and powerful toolset specifically for Android security testing. MobileHackingCheatSheet is easier to get started with but may lack depth, whereas drozer offers more comprehensive capabilities at the cost of a steeper learning curve.
Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
Pros of Mobile-Security-Framework-MobSF
- Comprehensive automated security assessment tool for mobile applications
- Supports both Android and iOS platforms
- Actively maintained with regular updates and a large community
Cons of Mobile-Security-Framework-MobSF
- Requires more setup and resources to run compared to a simple cheat sheet
- May have a steeper learning curve for beginners
- Limited to automated analysis, lacking manual testing guidance
Code Comparison
MobileHackingCheatSheet:
# Android
## ADB
### Install APK
adb install <apk>
Mobile-Security-Framework-MobSF:
def start_analysis(app_path, rescan):
"""Start the analysis."""
if platform.system() == "Windows":
raise Exception("MobSF Static Analysis is not supported in Windows.")
return StaticAnalyzer.scan(app_path, rescan)
The MobileHackingCheatSheet provides concise command-line instructions for mobile hacking tasks, while Mobile-Security-Framework-MobSF offers a more complex Python-based framework for automated security analysis.
Mobile-Security-Framework-MobSF is better suited for in-depth, automated security assessments of mobile applications, while MobileHackingCheatSheet serves as a quick reference guide for manual testing and common mobile hacking techniques.
The Mobile App Pentest cheat sheet was created to provide concise collection of high value information on specific mobile application penetration testing topics.
Pros of MobileApp-Pentest-Cheatsheet
- More comprehensive coverage of mobile app security testing topics
- Includes detailed sections on both Android and iOS platforms
- Regularly updated with recent contributions
Cons of MobileApp-Pentest-Cheatsheet
- Less focused on specific tools and commands
- May be overwhelming for beginners due to its extensive content
- Lacks a clear structure for quick reference during pentesting
Code Comparison
MobileApp-Pentest-Cheatsheet:
adb shell pm list packages -f | grep -i 'keyword'
MobileHackingCheatSheet:
frida-ps -U
The MobileApp-Pentest-Cheatsheet example shows an ADB command for package listing, while MobileHackingCheatSheet demonstrates a Frida command for process listing. This highlights the different focus areas of each repository.
Summary
MobileApp-Pentest-Cheatsheet offers a more extensive resource for mobile app security testing, covering both Android and iOS platforms in detail. It provides a wealth of information but may be less accessible for quick reference during pentesting. On the other hand, MobileHackingCheatSheet appears to be more concise and tool-focused, potentially making it easier to use during active testing scenarios. The choice between the two depends on the user's specific needs and level of expertise in mobile app security testing.
A big list of Android Hackerone disclosed reports and other resources.
Pros of Android-Reports-and-Resources
- More comprehensive collection of Android security resources, including reports, tools, and tutorials
- Regularly updated with new content and contributions from the community
- Includes specific sections for bug bounty reports and CTF writeups
Cons of Android-Reports-and-Resources
- Focuses solely on Android, lacking coverage of iOS and other mobile platforms
- Less structured organization compared to MobileHackingCheatSheet
- May be overwhelming for beginners due to the large amount of information
Code Comparison
While both repositories primarily consist of markdown files and don't contain significant code, here's a comparison of their directory structures:
Android-Reports-and-Resources:
├── Android_Reports
├── Android_Resources
├── CTF
└── README.md
MobileHackingCheatSheet:
├── Android
├── iOS
├── Mobile_App_Security_Checklist
└── README.md
The MobileHackingCheatSheet repository has a more organized structure, separating content by platform (Android and iOS) and including a dedicated security checklist. Android-Reports-and-Resources, on the other hand, focuses exclusively on Android and organizes content by type (reports, resources, and CTF writeups).
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
The Mobile Hacking CheatSheet
The Mobile Hacking CheatSheet is an attempt to summarise a few interesting basics info regarding tools and commands needed to assess the security of Android and iOS mobile applications.
PDF versions:
Main Steps
- Review the codebase
- Run the app
- Dynamic instrumentation
- Analyze network communications
OWASP Mobile Security Testing Project
Mobile Security Testing Guide
https://github.com/OWASP/owasp-mstg
Mobile Application Security Verification Standard
https://github.com/OWASP/owasp-masvs
Mobile Security Checklist
https://github.com/OWASP/owasp-mstg/tree/master/Checklists
Android CheatSheet
APK Structure
- META-INF: Files related to the signature scheme (v1 scheme only)
- lib: Folder containing native libraries (ARM, MIPS, x86, x64)
- assets: Folder containing application specific files
- res: Folder containing all the resources files (layouts, strings, etc.) of the application
- classes.dex [classes2.dex] ...: Dalvik bytecode of the application
- AndroidManifest.xml: Manifest file describing essential information about the app (permissions, components, etc.)
Package Name
The package name represents the appâs unique identifier (e.g. for YouTube):
com.google.android.youtube
Data Storage
User applications
/data/data/<package-name>/
Shared Preferences Files
/data/data/<package-name>/shared_prefs/
SQLite Databases
/data/data/<package-name>/databases/
Internal Storage
/data/data/<package-name>/files/
adb
Connect throug USB
adb -d shell
Connect through TCP/IP
adb -e shell
Get a shell or execute the specified command
adb shell [cmd]
List processes
adb shell ps
List Android devices connected to your machine
adb devices
Dump the log messages from Android system
adb logcat
Copy local file to Android device
adb push <local> <device>
Copy file from the Android device
adb pull <remote> <local>
Install APK file on the Android device
adb install <APK_file>
Install an App Bundle
adb install-multiple <APK_file1> <APK_file2> <APK_file3> ...
Set-up port forwarding using TCP protocol from host to Android device
adb forward tcp:<local_port> tcp:remote_port
List all packages on the device
adb shell pm list packages
Find the path where the APK is stored for the selected package name
adb shell pm path <package-name>
List only installed apps (not system apps) and the associated path
adb shell pm list packages -f -3
List packages names matching the specified pattern
adb shell pm list packages -f -3 [pattern]
Application Signing
For signing your APK file, you have 2 options
-
jarsigner: Only supports v1 signature scheme (JAR signature)
jarsigner -verbose -keystore <keystore_name> -storepass <keystore_password> <APK_file> <alias_name>
-
apksigner: Official tool from Android SDK (since version 24.0.3), which supports all the signature schemes (from v1 to v4)
apksigner sign --ks <keystore_name> --ks-pass pass:<keystore_password> <APK_file>
To create your own keystore, the following one-liner can be used:
keytool -genkeypair -dname "cn=John Doe, ou=Security, o=Randorisec, c=FR" -alias <alias_name>
-keystore <keystore_name> -storepass <keystore_password> -validity <days> -keyalg RSA -keysize 2048 -sigalg SHA1withRSA
Code Tampering
To tamper an APK file, the foolowing steps should be performed:
-
Disassemble the app with
apktool
and save the smali code into output directoryapktool d <APK_file> -o <directory_output>
-
Modify the smali code of your app (or the resource files if needed)
-
Build the modified APK with
apktool
apktool b <directory_output> -o <new_APK_file>
-
Sign the APK (see Application Signing)
-
(Optional) Use
zipalign
to provide optimization to the APK filezipalign -fv 4 <input_APK> <output_APK>
Frida
Installation
Install Frida and Python bindings on your system using pip
pip install frida frida-tools
Download the Frida server binary matching the targeted architecture and your Frida version
VER=`frida --version`
ABI=`adb shell getprop ro.product.cpu.abi`
wget https://github.com/frida/frida/releases/download/$VER/frida-server-$VER-android-$ABI.xz
xz -d frida-server-$VER-android-$ABI.xz
Upload and execute the Frida server binary on your Android device (root privileges are needed)
VER=`frida --version`
ABI=`adb shell getprop ro.product.cpu.abi`
adb root
adb push frida-server-$VER-android-$ABI /data/local/tmp/frida
adb shell "chmod 755 /data/local/tmp/frida"
adb shell "/data/local/tmp/frida"
Tools
List running processes (emulators or devices connected through USB)
frida-ps -U
List only installed applications
frida-ps -U -i
Attach Frida client to the specified application (emulator or device connected through USB)
frida -U <package_name>
Spawn the specified application (emulator or device connected through USB)
frida -U -f <package_name>
Spawn the specified application without any pause at the beginning (emulator or device connected through USB)
frida -U -f <package_name> --no-pause
Load a Frida script when attaching to the specified application
frida -U -l <script_file> <package_name>
Objection
Inject Frida Gadget library inside an APK file by specifying the targeted architecture (if emulator not running or device not connected)
objection patchapk --source <APK_file> -V <frida_version> --architecture <arch>
Inject Frida Gadget library inside an APK file using lastest Frida version available on Github (if emulator running or device connected to the device)
objection patchapk --source <APK_file>
SSL/TLS Interception with BurpSuite
Before Android 7
- Launch
BurpSuite
and modify Proxy settings in order to listen on "All interfaces" (or a specific interface) - Edit the Wireless network settings in your device or the emulator proxy settings (Android Studio)
- Export the CA certificate from Burp and save it with ".cer" extension
- Push the exported certificate on the device with adb (into the SD card)
- Go to "Settings->Security" and select "Install from device storage"
- Select for "Credentials use" select "VPN and apps"
References:
- Configuring an Android device to work with Burp
- Installing BurpSuite's CA certificate in an Android device
After Android 7
From Android 7, the Android system no longer trusts the user supplied CA certificates. To be able to intercept SSL/TLS communication, you have 3 options:
- Use an older version of Android
- Use a rooted device and install the BurpSuite CA certificate inside the sytem store certificate
- Tamper the targeted application in order to re-enable the user store certificate
In order to tamper the targeted Android application, we are going to add or modify the network security configuration file. This file on recent Android versions allows to force the application to trust the user supplied CA certificates. The following steps should be performed:
-
Install the Burpsuite's CA certificate on your Android device (see Before Android 7)
-
Disassemble the targeted app (APK file) with
apktool
-
Add or modify the
network_security_config.xml
file (usually onres/xml/
folder). The content of the file should be:<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="system" /> <certificates src="user" /> </trust-anchors> </base-config> </network-security-config>
-
If the
network_security_config.xml
file is not present on your app, theAndroidManifest.xml
also need to be modified by adding thenetworkSecurityConfig
tag as follow:<application android:name="AppName" android:networkSecurityConfig="@xml/network_security_config">
-
Build the modified app with
apktool
and then sign the newly created APK file (see Application Signing)
Content Provider
Query a Content Provider
adb shell content query --uri content://<provider_authority_name>/<table_name>
Insert an element on a Content Provider
adb shell content insert --uri content://<provider_authority_name>/<table_name>
--bind <param_name>:<param_type>:<param_value>
Delete a row on a Content Provider
adb shell content delete --uri content://<provider_authority_name>/<table_name>
--where "<param_name>='<param_value>'"
Activity Manager
Start an Activity with the specified Intent
adb shell am start -n <package_name/activity_name> -a <intent_action>
Start an Activity with the specified Intent and extra parameters
adb shell am start -n <package_name/activity_name> -a <intent_action> --es <param_name> <string_value> --ez <param_name> <boolean_value> --ei <param_name> <int_value> â¦
iOS CheatSheet
Filesystem
App list database
/User/Library/FrontBoard/applicationState.db
Binary directory: include all the static resources of the app
/private/var/containers/Bundle/Application/UUID/App.app
Path of the binary (executable)
/private/var/containers/Bundle/Application/UUID/App.app/App
App metadata: configuration of the app (icon to display, supported document types, etc.)
/private/var/containers/Bundle/Application/UUID/App.app/Info.plist
Data directory
/private/var/mobile/Containers/Data/Application/Data-UUID
UUID (Universally Unique Identifier): random 36 alphanumeric characters string unique to the app Data-UUID: random 36 alphanumeric characters string unique to the app
Default password
By default the root password on your jailbroken iOS device is alpine
If you've changed it and want to reset it:
- Open
/etc/passwd
or/private/etc/master.passwd
with a file manager app (e.g. iFile/Fileza) - Change the hash to:
/smx7MYTQIi2M
- root password will be
alpine
Bundle ID
The bundle ID (aka package name) represents the appâs unique identifier (e.g. for YouTube)
com.google.ios.youtube
How to find the data and binary directories
Grep is the not-so-quick ân dirty way to find where are the data and binary directories of your app
iPhone:~ root# grep -r <App_name> /private/var/*
How to find the data and binary directories and the Bundle ID
By launching Frida with the ios-app-info script
frida -U <App_name> -c dki/ios-app-info
And then
[iPhone::App]-> appInfo()
Or manually by opening the app list database
iPhone:~ root# sqlite3 /User/Library/FrontBoard/applicationState.db
And displaying the key_tab table to get the binary directories
sqlite> select * from key_tab;
Or displaying the application_identifier_tab table to get the bundle IDs
sqlite> select * from application_identifier_tab;
App decryption
- Add https://level3tjg.xyz/repo/ src to Cydia and install bfdecrypt tool
- Go to bfdecrypt pref pane in Settings and set the app to decrypt
- Launch the app to decrypt: decrypted IPA is stored in the Documents folder of the app
Dynamic analysis with Frida
List running processes
frida-ps âU
Analyse the calls to a method by launching Frida with the objc-method-observer script
frida -U <App_name> âc mrmacete/objc-method-observer
And then using the command observeSomething
[iPhone::App]-> observeSomething('*[* *<Method_name>*]â);
Hook the calls to the method <Method_name>
frida-trace -U <App_name> -m "-[* <Method_name>*]"
Then open the JavaScript handler file to edit the onEnter
or onLeave
functions to manipulate the behavior of the app
Dynamic analysis with Objection
Inject objection
objection -g "<App_name>" explore
List the classes (output will contain thousands of lines)
ios hooking list classes
List the methods of a class
ios hooking list class_methods <Class_name>
Search for classes|methods names containing
ios hooking search classes|methods <String>
Analyse the calls to the method <Method_name>
ios hooking watch method "-[<Class_name> <Method_name>]"
Hook the <Method_name> and return true to each call
ios hooking set return_value "-[<Class_name> <Method_name>]" true
Get the NSLog (syslog)
Impactor (http://www.cydiaimpactor.com) let you display the NSLog (syslog) on command line
./Impactor idevicesyslog -u <UDID>
SSL Interception with BurpSuite
- Launch Burp and modify proxy settings in order to listen on âAll interfacesâ
- Browse to the IP/port of your Burp proxy using Safari
- Tap on the âCA Certificateâ at the top right of the screen
- Tap on âAllowâ on the pop-up asking to download a configuration profile
- Go to âSettings->Profile Downloadedâ and select the âPortSwigger CAâ profile
- Tap on âInstallâ then âInstallâ again and then âInstallâ one last time
- Edit the wireless network settings on your device to set a proxy (âSettings->Wi-Fiâ then tap on the blue âiâ, slide to the bottom of the screen and tap on âConfigure Proxyâ)
- Tap on âManualâ, set the IP/port of your Burp proxy, tap on âSaveâ
- Go to âSettings->General->About->Certificate Trust Settingsâ & toggle on the PortSwiggerCA
Bypass SSL Pinning using SSL Kill Switch 2
Download and install SSL Kill Switch 2 tweak
wget https://github.com/nabla-c0d3/ssl-kill-switch2/releases/download/0.14/com.nablac0d3.sslkillswitch2_0.14.deb
dpkg -i com.nablac0d3.sslkillswitch2_0.14.deb
killall -HUP SpringBoard
Go to âSettings->SSL Kill Switch 2â to âDisable Certificate Validationâ
UDID (Unique Device Identifier)
UDID is a string that is used to identify a device. Needed for some operations like signature, app installation, network monitoring.
- Get the UDID with MacOS
idevice_id âl
or
ioreg -p IOUSB -l | grep "USB Serial"
or by launching Impactor without parameters
- Get the UDID with Linux
usbfluxctl list
or
lsusb -s :`lsusb | grep iPhone | cut -d ' ' -f 4 | sed 's/://'` -v | grep iSerial | awk '{print $3}'
or by launching Impactor without parameters
Network capture (works also on non jailbroken devices)
- With MacOS (install Xcode and additional tools and connect the device with USB)
rvictl -s <UDID>
tcpdump or tshark or wireshark âi rvi0
- With Linux or Windows (get https://github.com/gh2o/rvi_capture and connect the device with USB)
./rvi_capture.py --udid <UDID> iPhone.pcap
Sideloading an app
Sideloading an app including an instrumentation library like Frida let you interact with the app even if itâs installed on a non jailbroken device.
With IPAPatch
Hereâs the process to do it with IPAPatch: Clone the IPAPatch project
git clone https://github.com/Naituw/IPAPatch
Move the IPA of the app you want to sideload to the Assets directory
mv <IPAfile> IPAPatch/Assets/
Download the FridaGadget library (in Assets/Dylibs/FridaGadget.dylib)
curl -O https://build.frida.re/frida/ios/lib/FridaGadget.dylib
Select the identity to sign the app
security find-identity -p codesigning âv
Sign FridaGadget library
codesign -f -s <IDENTITY> FridaGadget.dylib
Then open IPAPatch Xcode project, Build and Run.
With Objection
Hereâs the process to do it with Objection (detailed steps on https://github.com/sensepost/objection/wiki/Patching-iOS-Applications)
security find-identity -p codesigning âv
objection patchipa --source <IPAfile> --codesign-signature <IDENTITY>
unzip <patchedIPAfile>
ios-deploy --bundle Payload/my-app.app -W âd
objection explore
Data Protection Class
Four levels are provided by iOS to encrypt automatically files on the device:
NSProtectionComplete
: file is only accessible when device is unlocked (files are encrypted with a key derived from the user PIN code & an AES key generated by the device)NSProtectionCompleteUntilFirstUserAuthentication
: (defaut class) same except as before, but the decryption key is not deleted when the device is lockedProtectedUnlessOpen
: file is accessible until openNoProtection
: file is accessible even if device is locked
Get Data Protection Class
By launching Frida with the ios-dataprotection script
frida -U <App_name> -c ay-kay/ios-dataprotection
License
The Mobile Hacking CheatSheet is an open source project released under the CC-BY-SA 4.0 licence.
Top Related Projects
The Mobile Application Security Testing Guide (MASTG) is a comprehensive manual for mobile app security testing and reverse engineering. It describes the technical processes for verifying the controls listed in the OWASP Mobile Application Security Verification Standard (MASVS).
The Leading Security Assessment Framework for Android.
Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.
The Mobile App Pentest cheat sheet was created to provide concise collection of high value information on specific mobile application penetration testing topics.
A big list of Android Hackerone disclosed reports and other resources.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot