binsider: a terminal UI for reading ELF binaries

What binsider is for, and who actually needs it

The problem is the first ten minutes with a binary you did not build. On Linux that usually means running file, stat, ldd, readelf, strings and strace in sequence, then scrolling back through interleaved output to connect a symbol to a section to a syscall. binsider collapses that sequence into one screen. The README describes it as a tool that can "perform static and dynamic analysis, inspect strings, examine linked libraries, and perform hexdumps, all within a user-friendly terminal user interface."

The intended reader is a reverse engineer or a security-adjacent developer working on a Linux host, comfortable in a terminal, who wants orientation rather than a full decompilation workflow. The repository topics list reverse-engineering, static-analysis, dynamic-analysis and elf, which matches that audience. It is not aimed at people who want a GUI, and it is not aimed at anyone analysing Windows PE or macOS Mach-O files: every feature named in the README is framed around ELF.

How the analysis is put together

The dependency list in Cargo.toml is the clearest description of the architecture available. Static parsing comes from the elf crate, string extraction from rust-strings, linked library resolution from lddtree, and the hexdump view from heh. The interface is built on ratatui, with tui-input, tui-popup and tui-big-text handling the interactive pieces.

Dynamic analysis is different, and this is the design decision worth noticing. It is behind a Cargo feature called dynamic-analysis, which is enabled by default and pulls in lurk-cli. Syscall tracing therefore comes from an external crate rather than from binsider's own ptrace code, and the nix dependency with its ptrace and signal features is what supports process control. The practical consequence is that dynamic analysis can be compiled out entirely with --no-default-features, leaving a static-only binary. If you are building binsider for an environment where ptrace is restricted, that is a supported path rather than a hack.

The repository also carries an ARCHITECTURE.md, which suggests the module boundaries are documented separately from the README. The README itself does not describe the internal data flow, so anyone needing to know how a section table becomes a rendered widget should read that file rather than the front page.

Installing binsider and running it on a real binary

The README gives cargo as the primary installation route. The published crate is binsider, and the current version in Cargo.toml is 0.3.2.

cargo install binsider

After that the README states you are "pretty much set" and that you run it by passing a binary path. There is no subcommand layer in the documented invocation.

binsider <binary>

The README points to a separate installation page for other methods, so if cargo is not your package manager, that page is the place to look rather than guessing at distributions.

A container image exists under the Docker Hub namespace orhunp/binsider, and the Dockerfile in the repository shows what it builds. The builder stage uses rust:1.88-slim-bullseye and the runner stage uses debian:bullseye-slim, copies the compiled binary to /app/binsider, drops to USER 1000:1000 and sets the entrypoint to ./binsider. The image therefore expects a binary path as its argument. Note the multi-stage build compiles with cargo build --locked --release, so the dependency set is pinned to Cargo.lock.

FROM debian:bullseye-slim AS runner
WORKDIR /app
COPY --from=builder /src/build-out/binsider .
USER 1000:1000
ENTRYPOINT ["./binsider"]

Inside the tool, the README documents five views: general analysis (file size, ownership, permissions, date, linked shared libraries), static analysis (sections, segments, symbols, relocations), dynamic analysis (system calls, signals, execution flow), string extraction, and a hexdump dashboard. General analysis is described as similar to stat(1) and ldd(1); dynamic analysis as similar to strace(1) and ltrace(1). The repository ships examples/demo.rs, which is a small Rust program you can compile and point binsider at if you want a known target instead of a system binary.

Where binsider stops being the right tool

The README does not mention disassembly, decompilation, or any output format other than the TUI. If your goal is to recover logic from stripped code, binsider gives you the layout and the strings and then hands the problem back to you. There is no documented non-interactive mode, no JSON export, and no exit-code contract for scripting, so it does not slot into a CI pipeline that needs to assert something about a binary.

Dynamic analysis carries the usual caveats of any ptrace-based tracer, and binsider's documentation does not claim to solve them. Tracing a setuid binary, a process inside a container without CAP_SYS_PTRACE, or a target protected by a Yama ptrace_scope setting will not behave the way a plain static view does. The README does not document rollback, partial trace results, or what the dynamic panel shows when the trace fails, so treat a failed trace as an open question rather than a handled case.

There is also a platform boundary the README never softens: this is an ELF tool. Feeding it a PE or Mach-O file is outside what any of the documented features address.

binsider compared with the command line tools it mirrors

The obvious alternative is the set of utilities binsider explicitly compares itself to: readelf, objdump, strings, ldd, strace and ltrace, plus hexdump or xxd. The difference is not capability, it is mode of work. The classic tools are composable and scriptable: readelf -S produces text you can grep, diff, or store as an artifact, and each tool does one thing with output you can pipe. binsider inverts that. It gives you a single interactive session where the section list, the symbol table, the strings and the hex bytes are navigable in place, which is faster for exploration and useless for automation.

If you already have a workflow built on readelf and strace, binsider is an addition for the exploratory phase, not a replacement. The same applies against a full disassembler: those tools answer what the code does, while binsider answers what the file contains and how it behaves at the syscall boundary. The README's own framing, that binsider is similar to stat, ldd, strace, ltrace and strings, is honest about which layer it occupies.

Maintenance, build cost and licensing

The last push to the default branch was on 2026-09-20, three days before this writing, and the repository is not archived. The most recent tagged release listed is v0.3.2 from 2026-02-01, with v0.3.1 and v0.3.0 before it. Commits are landing more often than releases, which is normal for a project at this stage but means the README may describe behaviour newer than the last tag you install from crates.io.

Upgrade cost is dominated by the Rust toolchain floor. Cargo.toml sets rust-version = "1.88.0", so an older stable toolchain will refuse to build it, and the Dockerfile pins rust:1.88-slim-bullseye for the same reason. The release profile uses lto = true, codegen-units = 1 and strip = true, which is good for the shipped binary and slow for a from-source build. A contributor also needs the dependencies to resolve cleanly against Cargo.lock, since the container build uses --locked.

On licensing, the README states the project is "Licensed under either of Apache License Version 2.0 or The MIT License at your option", and Cargo.toml declares license = "MIT OR Apache-2.0". Both LICENSE-APACHE and LICENSE-MIT are present at the repository root. That dual arrangement is the common Rust convention and is permissive, but whether it fits a given product is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt binsider if you routinely open unfamiliar ELF files on Linux and want sections, strings, hexdump and a syscall trace in one terminal session instead of chaining readelf, strings and strace. Skip it if you need disassembly, cross-platform PE or Mach-O work, or a scriptable output format for a pipeline, because the README documents a TUI and nothing else. Before relying on it, check that your toolchain meets the rust-version = "1.88.0" floor and, on a kernel with restricted ptrace, confirm the dynamic analysis panel actually receives events.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. orhun/binsider on GitHub
3. Project website
4. README
5. Releases