objection: a Frida console that hides its real interface in a wiki

pip3 install objection gives you a console, not a capability list

Installation is one command, and the upgrade path is a second one:

pip3 install objection

pip3 install --upgrade objection

What you get is a console entry point, declared in the project metadata as objection.console.cli:cli, built on click 8.2.0 or later. The surrounding dependency set explains the shape of the tool better than the docs do: litecli, prompt-toolkit pinned below 4.0.0, pygments and tabulate mean the session is a tab-completed, colorised interactive shell rather than a stream of subcommands. Python 3.11 is the floor. Note what is not in that dependency list: no target device driver, no instrumentation harness of its own. The capabilities come from Frida, which objection requires at 16.0.0 or later along with frida-tools 10.0.0 or later, so your real compatibility floor is Frida's, not the tool's.

The agent is JavaScript built by npm, and pip never builds it for you

The repository carries an agent directory at its root, and agent.js is listed in the package data, which means the JavaScript agent is shipped as a file inside the Python distribution rather than compiled at install time. Rebuilding it is a separate step handled by the build tooling:

frida-agent:
	cd agent && npm run build

That target needs a Node toolchain, and the default make target chains clean, frida-agent and sdist, so a source build expects npm on the machine even though the install path expects nothing but pip. The practical consequence for a reader: upgrading Frida on its own is not covered by the pip upgrade, and a mismatch between the agent.js you built and the Frida version you installed shows up as a failing session rather than as an install error. If you plan to modify the agent, budget for a JavaScript build step and read the Frida side yourself.

The capability list ends in a link, so the repo cannot answer what a command does

The stated capabilities are compact: inspecting and interacting with container file systems, bypassing SSL pinning, dumping keychains, dumping and patching memory, and exploring and manipulating objects on the heap, on both iOS and Android, without a jailbreak. That is the whole enumeration, and it closes with a pointer to a wiki features page, with screenshots hosted in a second wiki page. So the README names the outcomes but not the commands, the flags, or the order of operations, although the package data does ship console help files (console/helpfiles/*.txt). For an assessor, the gap is concrete: the README does not explain how a session attaches to a process, how a spawned application is selected, or what an SSL pinning bypass costs in setup. Budget an hour in the wiki before your first session, and treat the pinning and keychain entries as capability claims to verify on your own build rather than as documented procedures.

GPL-3.0-or-later with a permissions clause that points at a sales page

The license line reads GPL-3.0-or-later in the package metadata, and the LICENSE file in the root is the GNU General Public v3. The README adds a sentence with real consequences: permissions beyond the scope of this license may be available through the contact address at sensepost.com. A GPL-3.0 grant covers internal security testing and most research use, including modified versions you publish, but it obliges you to license derivative work under the same terms and it says nothing about embedding the tool inside a commercial product. The author of record is Leon Jacobs with a sensepost.com address, which is a commercial consultancy, so the dual licensing pattern here is deliberate. If you need to ship objection inside a product, resolve the exception in writing before you build the pipeline on top of it.

A Makefile that publishes source distributions and keeps test tools out of the install

The build file is short and tells you the release path. sdist runs uv build, test runs uv run pytest, and publication goes through uv publish, with a testupload target pointing at TestPyPI first.

sdist:
	uv build

testupload:
	uv publish --index testpypi

Test tooling sits in a separate dev group rather than in the runtime dependencies: pytest 7.0.0 or later and pytest-cov 4.0.0 or later are declared under dependency groups, and the pytest configuration pins testpaths to tests with strict markers. So installing objection from PyPI gives you no test runner, and a contributor path depends on uv being present. The build backend is setuptools 70.0.0 or later with wheel, and package data is listed by hand for console help files, JKS assets, JavaScript and XML assets, and agent.js. Hand-listed package data is where packaging bugs surface, so check that your install actually contains the agent file before blaming Frida.

Three releases in 2026 and a floor that lets Frida drift underneath you

The release history is unhurried: 1.12.5 on 2026-06-02, 1.12.4 on 2026-03-25, and 1.12.3 on 2026-01-27, with the version string duplicated in pyproject.toml at 1.12.5. The last push to the default branch master was on 2026-10-27 and the repository is not archived, so work continues between those tags. The friction is the dependency floor rather than the release cadence: frida 16.0.0 or later and frida-tools 10.0.0 or later are open-ended lower bounds, so a fresh pip install in six months may pull a Frida that this release never ran against. For repeatable assessments, pin both objection and frida in the same lock step and record which Frida build you validated, because the README offers no compatibility matrix and the wiki is the only place one could live.

Flask is a runtime dependency with nothing in the repo explaining who serves HTTP

Read the dependency list for entries that do not obviously belong to a terminal tool. flask 3.0.0 or later sits among click, requests, prompt-toolkit and semver as a hard runtime requirement, and no file in the root explains which component opens a listening socket or what it serves. That is a question worth answering yourself before you run the tool on a shared machine or inside a lab network, because a pentest framework that can bind a local port has a different exposure profile from one that cannot. The same applies to MANIFEST.in and the images directory: both exist at the root, neither is described. The honest summary is that the package metadata is more informative than the documentation, and that what it does not say is where the trust boundary sits.

Editorial conclusion

Use objection when you own or have written authorization to test an application and you already know Frida, because the tool assumes that knowledge and ships almost no reference material of its own. Do not treat it as a self-contained learning resource, and do not build a commercial workflow on the GPL-3.0-or-later grant without checking the permissions clause Sensepost points at. Before a first run, confirm the Frida version your target expects, confirm what listens on localhost when the tool starts, and read the wiki pages the repository defers to.

Frequently asked questions

Official sources

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