DATE

March 27, 2026

Mobile applications handle some of the most sensitive user data in existence, from banking credentials and health records to personal communications and location history. Yet iOS applications are routinely deployed with security gaps that attackers can exploit at runtime, bypassing protections that developers assumed were unbreakable. Objection, built on top of the Frida dynamic instrumentation toolkit, has become one of the most powerful tools in a mobile pentester's arsenal for exposing exactly these kinds of vulnerabilities.

This guide walks through how professional security teams use Objection during iOS penetration testing engagements, covering setup, core commands, and real-world attack scenarios. If your organization ships an iOS application and has never had it properly tested, the techniques described here may already be being used against you.

If you want a professional assessment of your mobile attack surface, Redfox Cybersecurity's penetration testing services cover iOS application security in depth, providing the kind of findings that automated scanners simply cannot surface.

What Is Objection and Why Does It Matter for iOS Pentesting

Objection is a runtime mobile exploration toolkit built on Frida. It allows security researchers and penetration testers to interact with a running iOS application without needing a jailbroken device in many scenarios, and without modifying the application's binary directly. Because it operates at runtime, it can defeat protections that are only active while the app is executing, such as SSL pinning, jailbreak detection, root checks, and biometric authentication gates.

The toolkit was created by Sensepost and has become a staple in professional mobile penetration testing workflows. Its power lies in its ability to hook into Objective-C and Swift method calls dynamically, manipulate memory, and intercept network traffic all while the application believes it is operating normally.

For iOS specifically, Objection excels at:

  • Bypassing SSL certificate pinning so traffic can be intercepted by a proxy like Burp Suite
  • Defeating jailbreak detection routines that would otherwise cause the app to shut down
  • Dumping the application's keychain entries to expose stored secrets
  • Listing and interacting with the application's local data stores including SQLite databases, plists, and NSUserDefaults
  • Exploring the file system of the application sandbox
  • Hooking specific methods to observe arguments and return values at runtime

Understanding these capabilities is what separates a surface-level mobile security review from a genuine penetration test.

Setting Up Objection for iOS Testing

Prerequisites and Environment Setup

Before running Objection against an iOS target, the testing environment needs to be properly configured. You will need a jailbroken iOS device for full capability (Checkra1n or Palera1n are common jailbreak solutions depending on your device and iOS version), Frida server running on the device, and Objection installed on your host machine.

Install Objection on your host machine using pip:

pip3 install objection

Verify the installation:

objection version

On the jailbroken iOS device, install the Frida server via Cydia or Sileo by adding the Frida repository (https://build.frida.re). Once installed, start the Frida server on the device and forward the port from your host:

iproxy 27042 27042

Verify that Frida can see the device and its running processes:

frida-ps -U

This will list all running processes on the connected iOS device. Identify your target application's process name or bundle identifier from this list.

Attaching Objection to a Running iOS App

Once the environment is ready, attaching Objection to a target process is straightforward. Use the bundle identifier of the application:

objection --gadget "com.example.targetapp" explore

Alternatively, attach by process name:

objection --gadget "TargetApp" explore

If the application is not already running, you can launch and instrument it simultaneously using Frida's spawn mechanism:

objection --gadget "com.example.targetapp" explore --startup-command "ios sslpinning disable"

That startup command flag is particularly useful when you need to disable SSL pinning before the application has a chance to initialize its networking stack.

iOS SSL Pinning Bypass with Objection

SSL pinning is one of the first protections pentesters encounter on iOS applications. It prevents traffic interception by tools like Burp Suite by validating that the server's certificate matches a pinned value embedded in the application. Objection makes bypassing this trivial in most cases.

Disabling SSL Pinning at Runtime

Once attached to the target app, run:

ios sslpinning disable

This command hooks into common iOS SSL pinning implementations including those using NSURLSession, AFNetworking, Alamofire, and TrustKit. It patches the certificate validation methods at runtime so that any certificate, including Burp Suite's CA, is accepted.

After running this command, configure your iOS device to use Burp Suite as an HTTP proxy and install the Burp CA certificate on the device. You should now see decrypted HTTPS traffic from the application flowing through Burp.

For applications using custom or more aggressive pinning implementations, you may need to identify the specific method performing the validation and hook it manually using Frida scripts. Objection's REPL allows you to execute raw Frida scripts inline:

objection run "ObjC.classes.NSURLSession['- URLSession:didReceiveChallenge:completionHandler:'].implementation = ...;"

Testing your iOS app's resistance to man-in-the-middle attacks is a core component of any serious mobile security engagement. Redfox Cybersecurity's mobile penetration testing team performs deep traffic analysis to identify API vulnerabilities that only become visible once pinning is bypassed.

Bypassing Jailbreak Detection on iOS

Many financial and enterprise iOS applications implement jailbreak detection to refuse operation on compromised devices. From a penetration testing perspective, jailbreak detection must be bypassed to fully assess the application in a controlled testing environment.

Disabling Jailbreak Detection

Objection provides a built-in command for this:

ios jailbreak disable

This hooks common jailbreak detection methods that check for the presence of files like /Applications/Cydia.app, /bin/bash, and /etc/apt, as well as methods that test whether the sandbox can be escaped by writing outside the app container. It also patches calls to canOpenURL: that check for Cydia's URL scheme.

For more sophisticated detection mechanisms, you can list all the Objective-C classes in the running application to identify custom detection logic:

ios hooking list classes

Then search for classes whose names suggest security or jailbreak checking:

ios hooking list classes | grep -i jail
ios hooking list classes | grep -i security
ios hooking list classes | grep -i detect

Once you identify the relevant class, list its methods:

ios hooking list class_methods JailbreakDetectionManager

And hook the specific method to observe its behavior or modify its return value:

ios hooking watch method "-[JailbreakDetectionManager isDeviceJailbroken]" --dump-return

To override the return value entirely:

ios hooking set return_value "-[JailbreakDetectionManager isDeviceJailbroken]" false

Exploring iOS Application Data Storage

Dumping the Keychain

The iOS Keychain is where applications store sensitive data such as authentication tokens, passwords, encryption keys, and session identifiers. It is one of the highest-value targets during an iOS penetration test.

Dump all keychain entries accessible to the current application:

ios keychain dump

This outputs all keychain items including their service name, account, access group, and value. Credentials stored without proper access controls, or stored using the kSecAttrAccessibleAlways attribute, represent a significant finding since they remain accessible even when the device is locked.

To dump keychain contents to a file for reporting:

ios keychain dump --json keychain_output.json

Exploring the Application File System

iOS applications run in a sandboxed environment, but the sandbox itself can contain a surprising amount of sensitive data. Objection makes navigating this environment straightforward.

Print the application's bundle and data directories:

env

This returns paths like the application bundle, documents directory, caches directory, and library directory. Navigate the file system from within Objection:

file ls /var/mobile/Containers/Data/Application/<UUID>/Documents/

Download files from the device to your host for analysis:

file download /var/mobile/Containers/Data/Application/<UUID>/Library/Preferences/com.example.targetapp.plist

Plist files stored in the Preferences directory often contain API keys, user settings, and other configuration data that should not persist in plaintext.

Interacting with SQLite Databases

Many iOS applications store structured data in SQLite databases. List SQLite databases in the application container:

sqlite connect /var/mobile/Containers/Data/Application/<UUID>/Library/Application Support/appdata.sqlite

Once connected, execute queries directly:

sqlite execute query "SELECT * FROM users;"
sqlite execute query "SELECT token, expiry FROM sessions;"

Sensitive data found in SQLite without encryption is a reportable finding, particularly when it includes PII, session tokens, or health data governed by regulations like HIPAA or GDPR.

Hooking and Tracing Methods at Runtime

Watching Method Arguments

One of Objection's most powerful features is the ability to watch Objective-C method calls in real time, logging the arguments passed and the values returned. This is invaluable for understanding how an application processes data and for identifying where sensitive information flows.

Hook all methods in a class and watch for calls:

ios hooking watch class AppAuthManager

Watch a specific method and print its arguments:

ios hooking watch method "-[AppAuthManager validateToken:]" --dump-args

To also capture the return value:

ios hooking watch method "-[AppAuthManager validateToken:]" --dump-args --dump-return

This type of method tracing often uncovers hardcoded credentials passed as arguments, cryptographic keys being computed in memory, and authentication logic that can be bypassed by manipulating return values.

Finding and Hooking Swift Methods

Modern iOS applications use Swift rather than Objective-C, which requires a slightly different approach. List Swift classes:

ios hooking list classes | grep -v "^NS\|^UI\|^CF\|^CA\|^CL\|^AV"

Use Frida's inline scripting within Objection to intercept Swift functions by their mangled names. The Swift demangle utility can help identify the correct symbol names from a binary analysis tool like Hopper or Ghidra used alongside Objection.

Performing a Complete iOS Pentesting Workflow

Pulling together the individual techniques into a coherent workflow is what defines a professional mobile penetration test. A typical iOS engagement using Objection follows this sequence:

First, enumerate the application. Attach Objection, run env to understand the directory structure, and dump the keychain immediately. List all classes and identify any security-sensitive logic worth targeting.

Second, bypass transport protections. Disable SSL pinning and route traffic through Burp Suite. Systematically walk through all application features while capturing traffic, looking for insecure API endpoints, missing authentication headers, and sensitive data transmitted in query parameters.

Third, analyze local storage. Download and review all plist files, SQLite databases, and files in the Documents and Caches directories. Flag any sensitive data stored without encryption.

Fourth, attack authentication. Use method hooking to observe authentication flows. Attempt to manipulate return values from token validation methods. Test whether the application enforces token expiry server-side or trusts client-side logic.

Fifth, review cryptographic implementations. Watch for hardcoded keys, weak algorithms like MD5 or SHA1 used for passwords, and ECB mode encryption visible through method tracing.

These findings, properly documented and risk-rated, form the basis of an actionable penetration test report.

If your organization needs this level of assessment performed by certified mobile security professionals, Redfox Cybersecurity offers comprehensive penetration testing services covering iOS and Android applications, APIs, and the backend infrastructure that supports them.

Common iOS Vulnerabilities Uncovered Through Objection Testing

Through runtime analysis with Objection, professional pentesters routinely uncover the following categories of vulnerabilities in iOS applications:

Insecure data storage remains the most prevalent finding. Applications store tokens, credentials, and PII in NSUserDefaults, unencrypted SQLite databases, or plist files accessible to anyone with physical or logical access to the device.

Weak or missing SSL pinning leaves applications vulnerable to network-level interception on hostile networks such as airport or hotel Wi-Fi. Even when developers implement pinning, the implementation is frequently bypassed by Objection's default bypass in seconds.

Broken authentication logic at the client side allows token manipulation or authentication method return value overrides to grant unauthorized access. Applications that perform authentication checks locally without server-side validation are particularly vulnerable.

Sensitive data leakage into system logs is another common finding. iOS applications that log debug information in production builds expose tokens, API responses, and user data to anyone with access to the device logs, readable via idevicesyslog or Console.app.

Excessive permissions and entitlements can grant an application access to capabilities beyond what its functionality requires, expanding its attack surface unnecessarily.

Wrapping Up

Objection represents a meaningful shift in how mobile penetration testing is conducted. What previously required custom Frida scripts, deep binary analysis, and significant manual effort can now be accomplished through a consistent command-line interface that dramatically accelerates the assessment timeline without sacrificing depth.

For development teams building iOS applications, the techniques described here represent exactly what a skilled attacker or security researcher would run against your product. Runtime bypasses, keychain dumping, and SSL pinning defeats are not theoretical exercises. They are standard steps in any credible mobile security engagement.

The appropriate response is not to avoid testing, but to commission it proactively. Security findings discovered internally in a controlled engagement are far less damaging than the same findings discovered by an adversary.

Redfox Cybersecurity's penetration testing services are built around the methodologies described in this guide, conducted by experienced mobile security professionals who deliver findings your development team can act on. Whether you are preparing for a compliance audit, releasing a new application, or responding to a security incident, a proper iOS penetration test gives you the visibility needed to ship with confidence.

Reach out to Redfox Cybersecurity to scope your next mobile security engagement.