As the mobile application pentesting is quite new, more and more people are trying to make this switch and start learning about Android and iOS Pentesting. Before deep-diving into the different techniques that could allow a pentester to bypass or circumvent the client-side protections, I would like to briefly present two tools that are a must-have in the pentester’s toolkit: Frida and Objection.
What is Frida? Frida is a dynamic code instrumentation toolkit that allows reverse engineers to inject snippets of JavaScript or library into native apps on iOS and Android (but not only) and to debug a running process. In other words, it allows you to inject your custom JavaScript code and programmatically and interactively inspect and change running processes. As Frida performs dynamic instrumentation, it doesn’t need access to the application’s source code. Furthermore, if you don’t have a rooted or Jailbroken device, don’t worry, Frida works also on normal devices.
As per their Github page, Objection is a runtime mobile exploration toolkit that is powered by Frida and built to help you assess the security posture of your mobile applications without needing a jailbreak. With that said, Objection is capable of the following:
objection
or just Frida
itself.To be able to assess the security posture of an application, we should be able to first identify the type of the testing application and its respective framework in which the application was written. Mainly, there are three types of mobile applications: Native, Web-based, and Hybrid.
The Native applications are written in either Java, Kotlin, Objective-C, or Swift. Xamarin can be used to build both iOS and Android applications.
Web-based applications can be broken down into two categories, Bookmarks and PWA (Progressive Web App), which is simply a native app running inside a browser.
Hybrid applications make use of both Native and Web capabilities to build powerful applications. Such applications are built using React Native, Ionic, Flutter, or Cordova.
There are multiple methods to circumvent the client-side security that blocks the usage of the testing application in an unsafe environment such as Rooted or Jailbroken devices. Next, I will give you the top-most used methods for iOS and Android.
If you would search the Cydia store, you will discover lots of applications that perform the bypass without any inside knowledge from the pentester side. Those applications are iHide, Shadow, Hestia, and Liberty. Of course, always would be a new application available as the iOS version grows up.
A more interesting method would be to use the aforementioned Frida toolkit to perform a dynamic bypass of the Jailbreak detection mechanism. Since the immersive growth of Frida, all the scripts released are pasted in the official repository, https://codeshare.frida.re/, like this script used to bypass common detections.
Objection has its own built-in module to bypass/disable the jailbreak detection mechanisms and can be used as easily as:
root# objection –g app.name explore
[usb]> ios jailbreak disable
If none of the above methods worked for you, for any particular reason, there would be another method, but much more difficult to achieve as it would involve using Reverse Engineering skills. If you do not possess such skills, Frida and Objection come in help, as they have the capabilities to identify classes and methods that might be used for detecting unsafe environments. You can easily make use of the ios hooking search classes string, ios hooking watch class *classname*, ios hooking watch method “method” –dump return, or ios hooking set return_value “method” value methods to perform the actual bypass, as can be seen in the following screenshots.
With much more spreading along with the smartphones users, with over 70% market share, the Android is clearly of much more interest. By being open sourced, Android is the attackers’ target when it comes to security and enforced protections. With all that, there are still efficient methods to bypass and circumvent the Root detection mechanism and even Emulator detection. With that said, you can take a look at the following repositories and use the scripts to bypass the common root and emulator detection mechanisms on different frameworks:
By exploring the application using objection, you can easily try to bypass the root detection by simply calling the android root disable method, as in the following:
root# objection -g app.name explore
[usb]> android root disable
A third method of bypassing the client-side protections would involve the usage of Reverse Engineering skills and smali patching. For this, you would need to disassembly the apk via apktool and discover the methods used to perform the checks. After that, if the method returns a boolean, just change the value from 1 to 0, or if it is a void method, return before any other calls are made. Such an example can be seen below:
SSL Pinning, or pinning for short, is the process of associating a host with its certificate or public key. Once you know a host’s certificate or public key, you pin it to that host. SSL pinning allows the application to only trust a valid or pre-defined certificate or Public Key. This technique is used as an additional security layer for application traffic, restricting the set of trusted certificates through pinning prevents attackers from further analyzing the app’s functionality how it communicates with the backend server.
Security testing on the Flutter-based Android or iOS apps that have SSL pinning implemented can be very hard, and it can be very difficult to bypass that SSL Pinning.
There are multiple methods to bypass the SSL pinning in Flutter-based apps with Ghidra or Frida (you can read more about it here). But, I want to recommend you the reFlutter framework that has awesome functionality to reverse engineer and patch the Flutter apps in a blink of an eye.
With a simple search on the Cydia Store, you can find the SSL Kill Switch 2 application, which is basically a Blackbox tool to disable SSL certificate validation, including certificate pinning, within iOS and macOS applications. As a working method, the application patches low-level functions responsible for handling SSL/TLS connections in order to override and disable the system’s default certificate validation, as well as any kind of custom certificate validation, including certificate pinning.
Again, if you can’t use the SSL Kill Switch 2, you can use the aforementioned Frida toolkit to perform a dynamic bypass of the SSL Pinning mechanism. You can search in the codeshare for SSL Pinning bypass scripts tailored for your iOS version, for example, you can use this script to bypass the Certificate Pinning in the iOS 12.
root# frida --codeshare machoreverser/ios12-ssl-bypass -f YOUR_BINARY
If you are the type of person that likes built-in modules, Objection can easily be your first choice, as it has its own SSL Pinning bypass module. There is no guarantee that such a method will work for your specific application, and you should try any other method described in this post. The following snippet shows how objection can be used:
root# objection -g app.name explore
[usb]> ios-sslpinning-disable
There are times when none of the aforementioned methods would work due to multiple reasons (incompatible iOS version, custom Certificate Pinning mechanism, etc.). In such cases, you can try to Reverse Engineer the application and inject your own certificate, or entirely disable the calling classes and methods. You can have a look also on Appknox‘s blog post that shows a couple more bypassing methods.
An interesting and easy bypass of Android’s Certificate Pinning would be the usage of an actual feature introduced by Android starting with version 7 (API 24) called Network Security Configuration. This feature allows an application to customize its security configuration in a declarative way using an XML file, in this way, no code is necessary. To abuse this functionality in order to achieve a bypass of the SSL Pinning, you can either patch the application yourself or use the tool Uncertify that does this job for you. Down below is a configuration example that accepts any User-installed Certificate on the device.
<?xml version="1.0" encoding="utf-8"?> <network-security-config> <base-config> <trust-anchors> <certificates src="user"/> <certificates src="system"/> </trust-anchors> </base-config> </network-security-config>
Frida always comes up with multiple scripts that allow the bypass of the Android’s SSL Pinning mechanism, but there would be no guarantee that any of the scripts would work. You can find such scripts on Frida’s codeshare, like the ones given below:
Objection can always be a savior and can help you when hard times come, by using the following built-in method:
root# objection -g app.name explore
[usb]> android sslpinning disable
Another method of bypassing the client-side protections would involve again the usage of Reverse Engineering skills and smali patching. For this, you would need to disassembly the apk via apktool and discover the methods used to perform the Pinning. The certificate pinning bypass can be very difficult sometimes and would be hard to explain it all here, but you can find a very good blog post here that explains the method of smali patching.
As JailBreak/Rooted detection and SSL Pinning are client-side mechanisms, there is no specific solution to stop attackers from bypassing these restrictions. As the attacker has no time limit to bypass the restrictions, he can understand and reverse engineer the application and follow step-by-step the decompiled code. But what can developers do to stop, or better slow down, the attackers? The answer is pretty straightforward: Obfuscation. As long as the compiled code is hardly obfuscated, the attacker would have to spend more time reverse-engineering the application. There are multiple solutions that allow you to achieve this goal and should be chosen according to your needs.
Another method would force the developers to create and deliver custom detection mechanisms, that would not be bypassed by current market tools.
Android Developers have a method to protect the applications against security threats which is known as SafetyNet. SafetyNet provides a set of services and APIs that help protect your app against security threats, including device tampering, bad URLs, potentially harmful apps, and fake users.
As there are multiple solutions posted by multiple researchers and developers, I give you a shortlist of references that would help you achieve your final goal: Application Security.