As consumers become more dependent on mobile devices, the need for application security has become more of a priority. In this blog post, I will discuss my testing methodology for mobile application assessments and some of the tools I use throughout the testing process.

Rooted and Jailbroken Devices

A mobile assessment begins with a rooted Android and Jailbroken iOS physical device. While testing can be performed without the device being rooted/jailbroken, this is extremely useful for the reverse engineering process.

Magisk is a popular Android rooting software; there are several methods for accomplishing the rooting process, and Magisk has great documentation on how to get started at https://topjohnwu.github.io/Magisk.

If you don’t have access to physical devices, there are ways to set up a virtual device for Android that can be found in this blog post: https://trustedsec.com/blog/set-up-an-android-hacking-lab-for-0.

Next, for iOS, this will be dependent on what device is available to you, because there is different jailbreak software for different versions of iOS.

This web page is a good starting point to determine if your device can be jailbroken and what software needs to be used: https://www.theiphonewiki.com/wiki/Jailbreak.

Two (2) jailbreak solutions that are used the most during my testing are Unc0ver and palera1n.

Unc0ver has a limited amount of supported iOS versions with the ability to jailbreak iOS 11-14.8.

https://unc0ver.dev/

palera1n has been helpful for newer iOS versions. When testing iOS applications, the user may run across minimum version requirements that do not match with the current jailbroken device, making it more difficult on the tester to complete the jailbreak.

https://palera.in/

Free device emulators for iOS are hard to come by, so paid-for services like Corellium are regularly the default in larger organizations. This makes the decision to test on a physical device a preferred method.

Obtaining the Application

Obtaining the application may be dependent on whether you are testing for a work engagement or on personal time. There are a few different ways to go about this:

• The company requesting the testing can provide an APK (Android) or IPA (iOS) file.
• If testing is for personal or training purposes, downloading the app from the Google Play Store or the Apple App Store will be the next option.
• There are other third-party sites that have APKs and IPAs available for download. Proceed with caution because the application may have been tampered with.

Sideloading the Application

Once obtaining the APK and/or IPA, the user needs a method to get the application onto the device.

• Android
  • Command line tool adb install - https://developer.android.com/tools/releases/platform-tools
  • https://book.hacktricks.xyz/mobile-pentesting/android-app-pentesting/adb-commands
• iOS
  • Xcode - https://developer.apple.com/xcode/
  • Filza- https://filzadownload.com/
  • Sideloadly - https://sideloadly.io/

Tools and Methods Used in Testing

One (1) tool that is used at the beginning of testing is MobSF, a static analyzer that analyzes the code of the mobile application without executing it. This tool gives a good baseline of the application and possible areas to focus on during the assessment. For this tool, the tester will upload the obtained APK and/or IPA file to the scanner and wait for the results.

The report given by MobSF provides details about the application, including:

• Permissions used by the application
• The components used in the application
• Vulnerabilities found in the application, with a severity rating for each vulnerability
  • https://github.com/MobSF/Mobile-Security-Framework-MobSF

Bypass Tools

Sometimes, the application may have security controls that will cause the application to not function correctly, or at all. Examples of these security controls are root and jailbreak detections, along with certificate pinning.

For Android and root detection, Magisk offers a Magisk Hideoption that will attempt to hide Magisk from various forms of detection.

For iOS, iHide and Liberty Lite are two (2) often-used Jailbreak bypasses.

• https://github.com/Kc57/iHide
• https://www.ios-repo-updates.com/repository/ryley-s-repo/package/com.ryleyangus.libertylite.beta/

Here is a link to our blog post with additional information on the jailbreak detection bypass tool iHide: https://trustedsec.com/blog/introducing-ihide-a-new-jailbreak-detection-bypass-tool.

Certificate pinning is put in place to help prevent MitM attacks. When this is in place, it causes us as testers to not be able to proxy application traffic. Android and iOS certificate pinning can be potentially bypassed with the publicly available tool objection.

SSL-Kill Switch2 is an additional tool available once the device is jail broken to help assist in disabling certificate pinning.

https://github.com/nabla-c0d3/ssl-kill-switch2

After static analysis with MobSF, the tester may proxy application traffic through a network proxy, like Burp Suite Pro. Depending on the engagement, this tool can be used to help the tester identify the application traffic or new attack paths.

Local Storage Analysis

There is often personal or other application information stored on the device. If a device is stolen or gets infected with malware, access to this information could be detrimental to the device owner.

There are several different local storage locations that can be reviewed.

For Android, local storage can be found:

• Original APK - /data/app/*/base.apk
• Application Storage -data/data/
• Databases/
• lib/: libraries and helpers for the app files
• shared_prefs/
• settings cache

External storage can be accessed in:

• /storage/emulated/0
• /sdcard
• /mnt/sdcard

For iOS local storage:

• BundlePath -/private/var/containers/Bundle/Application/3CB7949C…./appname.app
• CachesDirectory -/var/mobile/Containers/Data/Application/9655FCD2-…. /Library/Caches
• DocumentDirectory-/var/mobile/Containers/Data/Application/9655FCD2-…. /Documents
• LibraryDirectory - /var/mobile/Containers/Data/Application/9655FCD2-…. /Library

Reverse Engineering

Reverse engineering is a technique that a tester can use to better understand the application and how it functions. For Android, if the application does not implement any significant form of code obfuscation, this can allow the tester to decompile and browse the code with relative ease. One (1) tool often used for this process is JADX, a command line and GUI tool used for producing Java source code from Android Dex and APK files.

https://github.com/skylot/jadx

iOS takes a different approach, where it pulls an unencrypted IPA file from the device. Tools such as Frida-ios-dump will assist in pooling that unencrypted IPA file from the iOS devices.

https://github.com/AloneMonkey/frida-ios-dump

After it has been retrieved, the IPA file is then zipped and unzipped, allowing the user to see the package contents.

From there, the focus of the tester is on looking for any property list (plist) or information that may reveal any data. One item to note about plists is they cannot be viewed by a text file and will need to be converted.

This can be done by this command:

plutil -convert xml1 Info.plist

Additional Tools Used in an Engagement

The last item that will be covered is Frida. This tool could have multiple in-depth blog posts created, but we will stay at a high-level overview for now.

Frida is a dynamic instrumentation toolkit for developers, reverse engineers, and security researchers. There are many uses for Frida; some use it to access the application to observe how it runs, augment the application, and watch how the application behaves. It can also be used to dump memory from an application. Frida can also be used as the backbone for Objection, a runtime mobile toolkit. Both Frida and Objection are supported for Android and iOS and have different requirements for getting started.

• https://frida.re/
• https://github.com/sensepost/objection

Once set up, Objection allows the tester to:

• Attempt to bypass and simulate jailbroken or rooted environments.
• Discover loaded classes and list their respective methods.
• Perform common SSL pinning bypasses.
• Execute custom Frida scripts.

Both Android and iOS use the same start command but then differ with ‘objection -g "Process Name" explore’.

Commonly used Android commands in Objection:

• android sslpinning disable
• android root disable
• android keystore list
• android hooking search classes

Commonly used iOS commands in Objection:

• ios nsuserdefaults get
• ios hooking list classes
• ios hooking search classes
• ios nsurlcredentialstorage dump
• ios keychain dump
• ios cookie get 

This blog post may not be a comprehensive list of everything to look for and perform within a mobile application assessment, but these steps can be used as the building blocks to create a methodology for analyzing applications.