LockKnife puts a TUI in front of a Rust core, and concedes where the specialists win

TUI first, headless second, classic interactive is legacy

The product priority section is unusually explicit about which surface matters, and it is not the one most command line tools lead with. The terminal UI is described as the main product and default experience, used for day-to-day investigations, case-driven workflows, result review and operator-guided execution. The headless CLI is the secondary surface, for quick one-off tasks, scripting, CI and remote environments. And the old menu-driven interactive mode is called legacy convenience, kept for people who want the older flow. Two invocations reach the same place, `lockknife --cli` and `lockknife --headless`. The TUI is keyboard driven throughout: Tab moves between panels, Enter opens an action menu, slash searches modules and output, `t` cycles the theme, `c` opens the config editor, `e` exports the last result, `v` opens the result viewer, `y` copies a result from inside that viewer, question mark shows help, and Ctrl with the arrow keys resizes panels. There is no mouse dependency documented anywhere in the keymap.

Python orchestrates, Rust hashes and brute-forces

The v1.x rewrite is described with a clean division of labour. Python handles the command line, device input and output, module dispatch, reporting and the integrations. Rust handles the performance-critical primitives, named as hashing and cryptography, brute force work, and bulk parsing. The split is not decorative: bulk parsing is the operation that dominates wall-clock time on a large image, and hashing is the one that shows up in every loop. The previous edition was Bash only, and the changelog marks it as ending at v0.4.x, so anything written against that version is looking at a different tool. On the Rust side the workspace is small and deliberate, with two members, `lockknife-core` and `lockknife-tui`, which means the TUI is Rust as well rather than a Python panel wrapped around a Rust library. The claim about the TUI being default is backed by the packaging, not just the prose.

Twelve CLI subcommands and a five-level status legend

The core platform is a Python CLI with twelve named subcommands: device, crack, extract, forensics, apk, report, security, intel, ai, network, crypto-wallet and exploit. What the documentation does with that list is more useful than the list itself, because every feature in the catalogue is graded against a five-level legend. Production-ready means a stable core workflow with strong local and offline behaviour. Functional means useful and working, with practical constraints. Best-effort means it works in some environments but is highly dependent on the device, the app and the version. Experimental means an early workflow with notable limitations. Dependency-gated means it needs optional extras, external tools or credentials. A tool that publishes this legend next to its own feature list is telling you where the sharp edges are before you hit them, and the best-effort and dependency-gated categories are where to look first when something does not work on your particular device.

Six extras, and the Linux ones are commented out on purpose

The optional dependency groups map one to one onto capabilities. `apk` pulls `androguard` for static APK work. `frida` pulls `frida-tools` for runtime instrumentation. `ml` brings scikit-learn, numpy and joblib. `yara` brings `yara-python`. `threat-intel` brings VirusTotal's Python client and the Open Threat Exchange client for enrichment. `network` brings scapy. There is a seventh group that is deliberately absent, and the reason is given rather than implied: the exploitation framework dependencies are Linux-only and must be installed manually, because the resolver they use does not properly respect platform markers for those packages. The commented-out block names `bleak` for Bluetooth, `impacket` for network services and `pybluez`, each guarded by a Linux platform marker that is ignored. The macOS install route, for comparison, is a single tap line:

brew install ImKKingshuk/tap/lockknife

So on a macOS or Windows install you get a smaller tool by design, and a `full` group exists for the union. Whether you enable any of it is a question of authorisation and scope, and the project metadata describes itself as an ethical hacking tool for research use.

maturin puts a Rust build behind a Python package

The packaging is the detail that explains how a Python-first project ships a Rust core without asking you to have a Rust toolchain in your working environment. The build backend is maturin, declared in the build-system table with a minimum version, which builds the native extension and wraps it as an importable Python distribution. The project metadata is otherwise plain: name `lockknife`, version 1.2.0, Python 3.12 or newer, GPL-3.0-only, with classifiers for beta status, console environment, information technology and science and research audiences, and operating system entries for macOS, Windows and Linux. The runtime dependency list is short and tells you what the tool is actually made of at the top level: Click for the command line, Rich for terminal rendering, Jinja2 for report templating, defusedxml for parsing untrusted XML, Pydantic and pydantic-settings for configuration, and structlog for logging. That defusedxml entry is a small signal worth noticing in a tool that parses untrusted device data.

The comparison table concedes where the specialists win

There is a positioning table against ALEAPP, MobSF, drozer, objection and the Frida CLI, and it is written in a way that makes it useful rather than promotional. Each row names the other tool's real strength: ALEAPP for normalising mobile artefacts into investigator-friendly reports, MobSF for APK and IPA focused review in a web UI with sandbox analysis, drozer for attack-surface assessment through a CLI shell covering IPC exposure and exported components, objection for Frida-assisted runtime exploration with method browsing, and the Frida CLI for raw attach, spawn and script workflows. The capability grid is where the concessions appear. MobSF is marked as the better answer for APK static review, objection and Frida for runtime instrumentation, and MobSF's own row is marked as a server workflow rather than a scripting one. The recommendation at the end is to use LockKnife for one operator surface across the lifecycle and pair it with the specialists where their depth is needed.

bandit, clippy, deny and gitleaks configs sit at the root

The top-level directory listing reads like a security-conscious project's own tooling, which is a fair signal about how the maintainer works. There is a `bandit.yaml` for the Python security linter, `clippy.toml` for Rust lint configuration and `rustfmt.toml` for formatting, plus `deny.toml` for the dependency and advisory checker, `rust-toolchain.toml` pinning the toolchain, and `maturin.toml` for the build. Secret scanning has its own pair, a `.gitleaks.toml` configuration and a `.gitleaksignore`, and there is a `.pre-commit-config.yaml` so the checks run before a commit lands rather than in review. The Python side is split across `lockknife/` and `lockknife_headless_cli/`, which mirrors the primary and secondary surfaces described in the documentation, and `tests/`, `scripts/` and `docs/` sit beside them. Locking is committed twice, as `uv.lock` and `Cargo.lock`, so both halves of the build are reproducible.

Editorial conclusion

LockKnife suits an investigator who works across a whole case rather than one artefact, since the case workspace, the timeline view and the reporting pipeline are the parts the comparison table claims as native, and the TUI is clearly the surface the author wants you to use. It is the wrong choice for a single task: a static APK review is MobSF's strength and a low-level instrumentation session is Frida's, and the documentation says so. Before you install it, note that it needs Python 3.12 or newer, that the Linux exploitation extras are deliberately left out of the resolver and installed by hand, and that several capabilities are graded best-effort or dependency-gated in the project's own legend, which is the honest signal about what will work on your device. Work only on devices you own or are authorised to examine.

Frequently asked questions

Official sources

1. ImKKingshuk/LockKnife on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases