objection: runtime mobile exploration without a jailbreak

What objection solves for mobile pentesters

objection is a runtime mobile exploration toolkit built on Frida, and the README states it is designed to help assess the security posture of mobile applications without needing a jailbreak. That last clause is the whole point. Traditional iOS assessment assumed a jailbroken device before you could attach to a running process; objection moves the workflow to Frida's injection model, which the project uses for both iOS and Android.

The audience is narrow and specific: mobile penetration testers and security engineers who are already comfortable with instrumentation. The README lists the capability set as inspecting and interacting with container file systems, bypassing SSL pinning, dumping keychains, memory related tasks such as dumping and patching, and exploring and manipulating objects on the heap. Each of those is an interactive operation against a live process, not a static scan.

If your question is what an app's binary contains, objection is the wrong shape of tool. It answers what an app does while it runs, and what you can change about that while it runs.

How the Frida agent and the Python CLI fit together

The repository layout makes the architecture legible. There is a top-level agent/ directory, and the Makefile builds it with a Node toolchain:

frida-agent:
	cd agent && npm run build

That agent is the JavaScript payload that runs inside the target process. The Python side lives in objection/, and pyproject.toml declares the console entry point as objection = "objection.console.cli:cli", so the objection command is a thin CLI over that package. The package data section ships agent.js alongside helpfiles, keystores, JavaScript assets and XML assets, which confirms the agent is bundled into the installed Python package rather than fetched at runtime.

The dependency list tells you what the CLI delegates to: frida>=16.0.0 and frida-tools>=10.0.0 for the instrumentation channel, click for argument parsing, prompt-toolkit for the interactive shell, flask for the HTTP surface, litecli for SQLite work, and tabulate for output formatting. So the data flow is: you type a command in the objection REPL, the Python layer translates it into an agent message, the injected agent executes it in the target process, and results come back to your terminal. Every capability the README lists is an agent-side action surfaced through that channel.

Installing objection and running a first session

The README is explicit that installation is a matter of one pip command, and that the same command with --upgrade updates an existing install. The package requires Python 3.11 or newer according to pyproject.toml, and it pulls Frida 16 or newer as a dependency.

pip3 install objection

After that, the objection command should be on your PATH. The README points to the wiki Installation page for more detailed update and installation instructions, so if the pip route fails on your platform, that page is the documented next stop rather than anything in the README itself.

For a first real use, the workflow is to have a target application running on a connected device or emulator, then start the interactive session and attach. The README does not print a canonical attach command, but it does describe the operations you would reach for once attached: container file system inspection, SSL pinning bypass, keychain dumping, memory dumping and patching, and heap object exploration. A session therefore looks less like a one-shot command and more like a REPL where you issue those operations in sequence against the live process. The wiki Features page is where the project says the full command list lives.

Where the jailbreak-free promise gets thin

The README's headline claim is assessment without a jailbreak, and that is a real reduction in setup friction. It is not the same as needing nothing. objection depends on Frida, and Frida depends on getting code into the target process. On a stock, non-jailbroken iOS device that generally means a repackaged application or a developer-signed build, which is a materially different engagement model from attaching to whatever is already installed on a test device. The README does not walk through that constraint, and the wiki Installation page is the documented place to look.

The second limitation is version coupling. pyproject.toml pins frida>=16.0.0 and frida-tools>=10.0.0, and the agent is compiled from the agent/ directory with an npm build step. That means a Frida release that changes its injection behaviour can break the bundled agent until the project rebuilds and ships it. If you are building from source rather than installing the published package, you own that build step yourself.

Third, the tool is interactive by design. There is no batch mode described in the README, and the CLI is built around prompt-toolkit. If you need something that runs unattended in CI against a fleet of apps, you are looking at the Flask surface or at driving Frida directly, not at the objection REPL.

objection against using Frida directly

The honest alternative is Frida itself. objection is a wrapper: frida and frida-tools are both dependencies, and the objection agent is JavaScript that Frida injects. Nothing objection does is impossible from a Frida script, and a competent Frida user can write a targeted hook for one specific pinning implementation in less time than it takes to learn the objection command set.

The difference in approach is abstraction versus precision. objection gives you a broad, pre-built set of operations (keychain dump, container file system access, heap exploration) behind a stable CLI, which is useful when you are moving fast across several apps and do not want to rewrite hooks each time. Frida gives you raw control over exactly which class or symbol you hook, which matters when the app uses a custom pinning scheme that objection's generic bypass does not cover. objection is the faster default; Frida is the escape hatch when the default misses.

Maintenance, release cadence and the GPL question

The repository is not archived, and the last push was on 2026-09-17. Recent releases are 1.12.5 on 2026-06-02, 1.12.4 on 2026-03-25, and 1.12.3 on 2026-01-27, so the project has shipped roughly quarterly through 2026 and the version in pyproject.toml matches the latest release at 1.12.5.

Upgrade cost is low if you installed from PyPI, since the README documents pip3 install --upgrade objection as the update path. Building from source is heavier: the Makefile default target runs clean, frida-agent and sdist, the agent build needs Node and npm, and the sdist step uses uv build. Contributors also get pytest via uv run pytest, with the test configuration in pyproject.toml pointing at the tests/ directory.

The licence is GPL-3.0-or-later. The README notes that permissions beyond the scope of that licence may be available through SensePost's contact page. For practical purposes: if you are using objection as a tool during an assessment, the copyleft obligations attach to distribution, not to running it. If you plan to ship objection inside a commercial product, or to link it into proprietary tooling, the GPL terms and the stated contact route for extended permissions are the two things to read before you build. That is a summary of what the repository states, not legal advice.

Editorial conclusion

Adopt objection if you already use Frida and want a scripted, repeatable way to inspect iOS or Android apps at runtime during an authorised assessment. Do not adopt it if you need static analysis, if your target has no Frida support, or if you cannot run code on the device. Before committing, verify that your Python is 3.11 or newer, that frida>=16.0.0 resolves on your platform, and that the GPL-3.0-or-later terms fit how you plan to redistribute anything you build on top of it.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. sensepost/objection on GitHub