Getting the IPA file

• Get the IPA from the client or download the IPA from the app store.


• The IPA from the app store is encrypted so it needs to be decrypted by dumping the binary from memory.

• Frida-iOS-Dump
• Frida-IPA-Dump

Installing on the device

• Sign the IPA using iOS-app-signer and install the IPA using iOS-deploy


• If using a free developer account then the provisioning profile needs to be trusted and the app needs to be verified from “General > Profile and Device Management”.


• Currently Cydia-impactor does not work reliably and you’ll need a mac in order to install the app on the device.
• References to learn more
• Code Signing
• Provisioning Profile

• iOS-app-signer
• iOS-deploy

Filesystem analysis

• Each app is given a unique 32 char UUID which represents its App directory sandbox location


• Each app is also given a unique 36 char Data-UUID which contains all the application data.


• The app IPA package can be found at the following location./private/var/containers/Bundle/Application/UUID/App.appThis contains all the resources that are shipped with the IPA and hence should always be checked for Sensitive Credentials.


• The Info.plist file is located at the following location./private/var/containers/Bundle/Application/UUID/App.app/Info.plistThe file contains all the details about the application and so much also be checked for hard coded secrets/credentials.


• All the application data is located at the following location./private/var/mobile/Containers/Data/Application/Data-UUIDThis data location should be checked for local storage issues like storage of sensitive data in encrypted format and storing it in Plist files.

• Data Protection API is an additional protection mechanism which can be used to provide additional protection to important files like financial records and personal data.There are mainly four main Data Protection Classes.


• No Protection (NSFileProtectionNone): No protection applied on file.


• Protected Until First User Authentication (NSFileProtectionCompleteUntilFirstUserAuthentication):File will remain accessible while the phone is unlocked and will remain unlocked until reboot.


• Protected Unless Open (NSFileProtectionCompleteUnlessOpen): The file will be unlocked when accessed and will be unlocked till reboot.


• Complete Protection (NSFileProtectionComplete): The file is unlocked when opened and then shorts after the device is locked the file is made inaccessible.


• Use this frida codeshare script* to list Data protection classes of files in the app/data directory.


• When looking for insecure storage of sensitive data on the file system focus on the following key areas.


• Sensitive data stored in plist files instead of the keychain as they can be easily read in the itunes backup.


• Sensitive data stored in bad encoding schemes like base64.


• Sensitive data stored in unencrypted SQLite, Core Data or RealmDB databases.


• Sensitive data leaked in caches in the Data Directory of the app.

• References to learn more
• Reverse Engineering
• ios file structure
• App sandbox
• ios data protection
• NS file protection
• keychain

• Objection
• Passionfruit
• OpenSSH on Cydia

Network analysis

Check if the application does SSL pinning by adding burp CA and trusting it as a root CA.
• Setup burp proxy and goto http://burp
• Download the certificate and goto General > Profile to install the certificate
• Goto General > About > Certificate trust Settings to trust the certificate as a Root CA by toggling the Portswigger CA option

To do API testing and traffic capture you’ll need to bypass the SSL pinning if implemented.

• Download SSL Kill Switch -2 deb file from github.


• - Transfer deb file to the device using SSH


• - Install via: dpkg -i <package>.deb


• Restart SpringBoard: killall -HUP SpringBoard

OR

• Use ios ssl-pinning disable from objection to bypass SSL ssl-pinning implementations during the run time of the application.

• References to learn more
• SSL-Pinning check/Setup Proxy

• Burp Suite
• ssl-kill-switch2
• iOS SSL pinning bypass

Check if UI screens with sensitive details are protected against screenshots

• This data is located at /var/mobile/Containers/Data/Application/UUID/Library/Caches/Snapshots/Sensitive details should not get captured in the screenshot

• Sensitive data in iOS is recommended to be stored in the keychain, however there is no platform API to clear keychain data on app uninstall. This is called keychain persistence.


• The application should clear keychain items on logout like authentication token etc.
• 
  
• To test install and use the app to populate the keychain and then uninstall the app.


• Reinstall the app to check if you can still access the app with the user login details.


• Text input is cached for UITextFields inputs and stored in the following location for language prediction which can cause leakage of sensitive data like credit card info./private/var/mobile/Library/Keyboard/dynamic-text.datInput data into the application at multiple places and see if it appears in the keyboard cache.


• URL schemes are a very good attack vector to your application and cause much damage.


• URL schemes are defined in the CFBundleURLTypes key of the Info.plist file of the app.
• Trace the usage of *[* *openURL*] selecter in the disassembly to understand the query parameters and the URL handling.
• Ensure URL parameters are properly validated and malformed URLs are discarded
• 
  
• Ensure to only open URLs from trusted domains.
• Check if domain validation is properly implemented.

• Passionfruit
• iOS URL Fuzzer

WebViews should be properly protected against XSS and phishing attacks.

• UIWebVIew is deprecated since iOS 12 and is not recommended because JavaScript cannot be disable for it.


• WXWebView features much richer JavaScript support and also comes with JS enabled by default which can be disabled


• SFSafariViewContruller is another common choice, JS is enabled by default and cannot be disabled and shared cookies and site data with Apple Safari.


• Verify if the app is allowing local files read via loaded WebView content by checking the value/s of loadFileURL:allowingReadAccessToURL:. in the disassembly of the app binary.

• References to learn more
• Web view xss

Check if LocalAuthentication mechanisms like TouchID/FaceID are properly implemented.

• Find any sensitive data which is protected by Biometric lock using the LocaAuthentication framework.


• Use the ios ui biometric_bypass from objection to check if we are able to bypass the biometric authentication.

• iOS Biometric Bypass

Always check for hard coded credentials in the application binary

• Many developers hard coded credentials in the app, search for secret, crypt, private, token etc.
• Many apps use third party backend systems, analyse and .json and .xml files for credentials.
• Many apps contain hidden features, search for develop, debug, fake, test in the app binary.


• Referrences
  • iOS Hardcoded credentials

• Hopper Disassembler

Check if app logs contain any sensitive data which the developer might have left during the development process and forgot to remove the logging

• To check logs connect the device to mac.
• Goto Xcode -> Devices and Simulators -> View device logs to see the logs 
• Grep the logs for sensitive data files

Check for Jailbreak detection Implementation

• Install the app on the jailbroken device if it is not showing any alert regarding the jailbroken device or not blocking the app to run. Then it is not protected with jailbreak detection

• Other References
• Demystifying Frida
• Binary Analysis and Debugging
• local storage issues

Getting APK files and gathering info

• Get the Application directly from the client
• Download the app from the play store and pull it using ADB(rooted android device/non-rooted devices).
• Search for the app on play store and download it
• adb shell pm list packages -f | grep app_name
• It will show the com.package_name

or

• Look manually from the list of packages


• adb shell pm path com.package_name.


• adb pull /data/app/com.package_name..apk


• Check for application ecosystem
• React Native Application
• com.facebook.com.react entry in the AndroidManifest.xml file
• Flutter Application
• io.flutter folder from decompiling the app
• flutter.embedding entry in the AndroidManifest.xml file


• Download it from
• APKpure


• apk-downloader


• apkmirror


• apk-dl


• androidappsapk


• - A tool to download apk directly from play store PlaystoreDownloader

• adb tools

Installing on the device

• Simple to install it from the play store.


• If have apk on host system use
  “adb install application.apk”

• Note: Make sure and keep an eye on the Mobile device for the permission pop up while installing it.

• adb tools
• Emulator
  or
  
• Mobile device

APk file analysis by reverse engineering

• APK package file contains the code of the application. (it is similar to zip file).it contains assets, res, lib, META-INF, AndroidManifest.xml, classes.dex(Dalvik binary bytecode)


• To see all these contents Convert .apk file to .zip file and extract(unzip) it.


• To read AndroidManifest.xml use Apktool

  Apktool d application.apk

  cd application

  Open AndroidManifest.XML in any text editor and analyze it.



• Reverse engineering DEX bytecode :


• Rename application.apk to application.zip and extract it.You will get classes.dex file


• Use d2j-dex2jar -f classes.dex file to get the java classes files.



JD-GUI (java decompiler ) to read the java source code from the java classes files.

• References to learn more
• AndroidAPPRE
• Android App Reverse Engineering LIVE!

• adb tools
• dex2jar
• JDGUI

Static Analysis (manually and automated)

• After getting the java source code, Analyze it and look for the sensitive information hardcoded into code like password, API keys


• Case Study: https://hackerone.com/reports/351555


• Use MobSF for Static Analysis to speed up the process

• MobSF
• adb tools
• apktool
• dex2jar
• JDGUI

Check App is Debuggable

• Android allows full-system backup which includes app data which are debuggable
• Attacker could take the backup of a debuggable app via adb
• Check android:debuggable attribute in AndroidManifest.xml file
• if the attribute value is true then its vulerable

Check for Typos in custom permission in Android manifest file

• Developers can use custom permission for android components to be used by autorized application only


• Typo in using custom permissions which don’t match declared custom permissions can be misused by unauthorized application
• Case Study: https://hackerone.com/reports/440749

Test for Exported Activity

• By default android activitiy is not exported but if an intent-filter is defined then it's generally exported


• It is also possible that non exported activities could be executed by the exported activity, Check if you can control the execution of non exported activity via exported one using adb

• MobSF

Test for exported broadcast receiver

• Check for the exported broadcast receiver in the AndroidManifest.xml file


• Check if the attacker could send the payload to this exported broadcast receiver or the input is handled by the apk in any way

• MobSF

Check for SSL pinning & its bypass

• Setup burp proxy(or another similar proxy) go to Http://burp
• Go to Settings > additional settings > privacy > certificates >install certificates from sd card (select the downloaded location) to install as a root CA certificate
• Capture the traffic of app



or



• If SSL certificate pinning is enabled you need to bypass it to capture and analyze the app traffic.
Use Frida and objection to bypass

• Install Frida client on the host and run Frida server on a Mobile device(place the Frida server on a mobile device using:

>adb push Frida-server /data/local/tmp/
> adb shell
> cd /data/local/tmp/
> chmod +x frida-server (make it executable )
> ./frida-server &


or


> adb shell "chmod 755 /data/local/tmp/frida-server"
> adb shell "/data/local/tmp/frida-server &"

• Test if Frida server is running properly using :

> Frida-ps -Ua


• Using objection to bypass sslpinning

> objection -g com.package_name explore
> android sslpinning disable

• References to learn more
• SSL pinning/proxy setup
• Xposed-framework
• Frida
• Objection

• Burp Proxy
• Device/Emulator
• Xposed
• frida
• Objection

Analyzing App logs using pidcat tool

• shows log entries for processes from a specific application package
• pidcat target-app-package-name

• Pidcat
• Logcat

Check app UI is protected against a screenshot of sensitive information

• adb shell /system/bin/screencap /sdcard/img.png
  

  Here screen cap is the command-line utility to take screenshots of a device.



• Download it using adb pull /sdcard/img.png


• Read it using display img.png (on linux)

Note (Sensitive info should not be captured in the screenshot)

Check root detection mechanism is implemented

• Install the app on the rooted device if it is not showing any alert regarding the rooted device or not blocking the app to run. Then it is not protected with root detection.

Check shared preferences for persistent login

• For the first time for the login, the app asks for the user name and password and later it does not ask for the username and password.it stores the login key in login_account.xml at the shared preferences.it can be stolen by other app and attacker can use it

Checking for Keyboard cache

• Location /data/data/com.android.providers.userdictionary/databases/user_dict.db


• - Use SQLite to read it(user_dict.db)

• SQLite browser

Test for vulnerable Broadcast receivers

• Check for the intent which send by the broadcast (it can be a user input)
  and Check AndroidManifest file for broadcast receiver which has android exported=”true”(insecure way)
• - And develop the exploit according to the app functionality

Test for Intent Sniffing

• Application could send broadcast intent without specifying the broadcast target
• Any malicious app could intercept these implicit broadcast
• Search sendBroadcast function in the decompiled code
• Case Study: https://hackerone.com/reports/56002

Test for Deep Linking Vulnerabilities

• Deep link are URLs which navigate users directly to the specific content in an applications
• To define deep links, intent filters are defined in AndroidManifest.xml file
• Intent filter must also include a category with the DEFAULT or BROWSABLE value
• Check for if scheme,host and parameters are validated properly

Test for WebView Vulnerabilities

• It allows to show web pages as an activity
• In smali code look for these strings
• @JavascriptInterface ,setJavaScriptEnabled ,setWebViewClient
• Check for dangerous WebView settings like setAllowFileAccess(true)

Test for local encryption issues

• Check for weak crypto alogs if used


• Vulnerable algo/outdated cipher: such as DES and 3DES,RC2,RC4, MD5 and SHA1,Dual_EC_DRBG and SHA1PRNG,BLOWFISH


• Inspect the app code to check used crypto algo instances


• Common configuration issues


• Check if symmetric encryption is used with hardcoded crypto keys.


• If app is using two way ssl ,check for the client SSL Certificate password locally (should not store it locally )

Finding Storage issues from android manifest file

• uses-permission : android:name="android.permission.WRITE_EXTERNAL_STORAGE"


• Check code for used file permission keywords/API to store data like : MODE_WORLD_READABLE or MODE_WORLD_WRITABLE (these two allow any app to read the file and write to this file)
• Check external storage for sensitive info stored (you can analyse the code to know more like above)

cd /mnt/sdcard
use ls and ls -l file_name_found_from_source_code
Note : In unix files starting with . are ignored by the ls command
so use ls -l file_name_to_check

• SharedPreferences class (it stores key-value pairs)


• FileOutPutStream class (it uses internal or external storage),getExternal* function (use external storage)
• getReadableDatabase function (returns a SQLiteDatabase for reading)
• 
  getCacheDir and getExternalCacheDirs(use cached files)


• Check for the bad practises used for encrypting the files


• getWritableDatabase function (returns a SQLiteDatabase for writing)

Check for Input Validation issues

• For e.g. : login page ,try to login without using username and password (vai SQLinjection),keep checking the logs of the app you might see the SQli error


• Input validation check for URI schemes :
• Reading app files stored in sdcard or internal storage using "file:///path_of_file" schema to read the files
file:///sdcard/.file_name.txt or file:///data/data/com.app.name/shared_prefs/ app_preferences.xml

Check for Access Control issues

• Some of the componentes can be accessed by other apps if the are not properly protected.Components like activities,services,content providers
• e.g. In a app one activity shows the API key and password (activity might handle some other sensitive info) inside the app.Try to get the same info from the outside of the app.Note: Check if the Activity/Component is exported and app is allowing access of info outside the application.then it is an issue
• check usingadb shell am start com.app_name/.Activity_name(activity which is exported and have sensitive information)this will launch the activityadb shell am start -n com.app_name/.Activity_name -a com.app_name.action.VIEW_Action_name-a it specifies the intent action and above will launch the activity