re-shell: a Nix reverse engineering environment that picks its own tools

A dev shell where the tools appear because of the file

re-shell is a Nix flake based reverse engineering environment designed for use with Claude Code, and the premise is stated in one sentence: drop in a binary, capture, or archive and ask Claude to analyze it, and the right tools and context activate automatically.

That last clause is the whole design. The environment is a reproducible Nix dev shell bundling a full reverse engineering toolchain, with Ghidra, radare2, Frida, mitmproxy and YARA among the tools named, and Claude Code is configured through a CLAUDE.md file that carries discipline-specific skills which auto-activate based on file type and context.

The skills are listed as a table of what activates on what. The Windows RE skill covers PE binaries, .NET assemblies and drivers, with .exe, .dll and .sys as example files. The Android RE skill covers Android packages and DEX bytecode, with .apk and .xapk. The Web RE skill covers HTTP captures, API traffic and protobufs, with .har and .proto.

So the routing is by file extension and by context, and the mechanism is that when Claude detects relevant context the matching skill loads specialized tool documentation and workflows, with no manual configuration needed.

The quick start is short. You need the flakes and nix-command experimental features on, and if not you add them to the nix config file:

echo "experimental-features = nix-command flakes" | sudo tee -a /etc/nix/nix.conf

Then you enter the environment, or use direnv, drop a file into the repo root and start Claude Code:

# Enter the environment (or use direnv)
nix develop
# Drop a file into the repo root and start Claude Code
cp ~/Downloads/suspicious.exe .
claude

The project is written primarily in Nix, the licence is not recorded in the repository metadata, there are no GitHub releases, and the last push was on 2026-08-29.

The interesting design decision is that the environment is the context. Rather than asking an assistant to install tools as it needs them, the toolchain is already present and the selection of which tools to use is handled by the skill loading, which is a different and more reliable arrangement than a conversation that has to rediscover the environment each time.

The Python dependencies are the actual tool list

The pyproject file is the most informative document in the repository, because the dependency list is organised by discipline and it is longer than a list of package names.

dependencies = [
    # General
    "capstone",
    "cryptography>=46.0.5",
    "frida",
    "ipython",
    "numpy>=2.5.1",
    "pillow>=12.3.0",
    "pyghidra",
    "pyusb>=1.3.1",
    "scipy>=1.18.0",
    "yara-python",
    # Android
    "hermes-dec>=0.1.0",
    "pyaxmlparser",
    # Windows
    "dnfile",
    "lief",
    "oletools",
    "pefile",
    "unicorn",
    # Web
    "beautifulsoup4",
    "grpcio",
    "grpcio-tools",
    "haralyzer",
    "protobuf",
    "bleak>=3.0.2",
    "pyserial>=3.5",
    "hidapi>=0.15.0",

The General group holds the cross-discipline tools. capstone is the disassembly library, cryptography at 46.0.5 or newer handles the crypto, frida is the instrumentation framework, ipython gives a shell inside the environment, numpy and scipy do the numeric work, pillow handles images, pyghidra is the Python bridge into Ghidra, pyusb talks to USB devices directly, and yara-python is the signature matching engine.

The Android group is small and specific: hermes-dec for the Hermes bytecode and pyaxmlparser for the Android XML resources. The Windows group is the biggest, with dnfile for .NET assemblies, lief as the binary parser, oletools for the Office formats, pefile for the PE format itself, and unicorn as the CPU emulator.

The Web group is the widest. beautifulsoup4 for HTML, grpcio and grpcio-tools for gRPC, haralyzer for HAR capture files, protobuf for the serialisation, bleak for Bluetooth, pyserial for serial devices and hidapi for human interface devices.

Two of those deserve a note because they change what a question can be answered. pyghidra means the analysis can happen inside Ghidra programmatically rather than through its interface, and yara-python means rule-based detection is available as a library rather than only as a command line tool. Both convert a manual step in a workflow into something an assistant can call.

The version floors are worth noticing. Python 3.13 or newer is required, and the floors on the individual packages are current, with cryptography at 46.0.5, numpy at 2.5.1, pillow at 12.3.0 and scipy at 1.18.0. The bleak and hidapi floors suggest the Bluetooth and HID work is a deliberate part of the environment rather than an accident, since both are physical device access libraries and neither would be present by default in a general reverse engineering setup.

The build backend is hatchling, and the wheel target sets bypass-selection to true, which is the setting that lets a package with a non-standard layout still be installed.

The environment modifies itself, in three different ways

The adding tools section describes an environment that is self-modifying, and the reasoning is stated directly: if an analysis needs a tool that is not installed, Claude can add it.

There are three ways, and they differ in how durable the change is.

Python packages are added with uv add followed by a direnv reload. Node.js packages are added with npm install followed by a direnv reload. And system tools are added to flake.nix followed by a direnv reload.

The asymmetry is the interesting part. The first two are ephemeral in the sense that they change the environment you are working in without changing its definition, and the third changes the definition itself, which is the durable one. A tool added to flake.nix survives the next reload because the shell is rebuilt from the changed flake, whereas a package added with uv or npm survives only for as long as the shell does.

The direnv reload in all three cases is what makes the change visible. The shell is entered by nix develop or by direnv, and reloading is what re-reads the definition and puts the new tool on the path. Without it the agent would add a package and then find it missing.

This is a real property of the design and also its main risk. An environment that can install things on demand is convenient for an assistant that has just discovered it needs a different tool, and it is also an environment where the toolchain during a session is not the toolchain you pinned. The repository layout shows the mitigation. There is a package.json, a package-lock.json, a pyproject.toml, a uv.lock, an .npmrc and a flake.lock, so the additions that are meant to persist are recorded in files that can be reviewed and committed.

The npm package manifest is small and tells its own story. The package is named re-env, version 1.0.0, marked private so it is never published, and it has exactly one dependency, apk-mitm at 1.3.0 or newer.

{
  "name": "re-env",
  "version": "1.0.0",
  "private": true,
  "dependencies": {
    "apk-mitm": "^1.3.0"
  }

One dependency that is an Android traffic interception tool, sitting alongside the Python dependencies for Android analysis. That pairing makes sense as a single workflow, since capturing the traffic of an application and then reversing the application are two halves of the same task.

Two gitignored output directories, and why they are separated

The output directories section is short and the split it defines is a small piece of good practice that many tool directories get wrong.

There is a tmp directory for intermediate work products, and an artifacts directory for final deliverables such as reports and analysis notes. Both are gitignored.

The separation is the point. A reverse engineering session produces a lot of scratch output, decompiled fragments, extracted strings, intermediate scripts and partial results, and only a small part of that is worth keeping. Putting the two in different directories with different meanings means a report can be handed over without the surrounding noise, and it means the scratch area can be deleted without losing anything.

The gitignoring of both is what makes that separation useful in practice. If the artifacts directory were tracked, a session would produce diff noise in every repository the tool was dropped into, and if tmp were tracked the repository would fill with generated files. Both being ignored means the environment can be used in a working copy without polluting it.

The top level of the repository matches this structure. There is a .claude/ directory for the agent configuration, a CLAUDE.md at the root for the skills, an .envrc for direnv, a .gitignore, an .npmrc, a flake.nix and a flake.lock for the environment definition, a package.json and package-lock.json, a pyproject.toml and a uv.lock.

The .envrc is the direnv entry point and it is what makes the environment enter automatically when you cd into the directory, rather than requiring you to remember nix develop. That is a small difference in convenience with a large effect on habit, because an environment you have to enter by hand is an environment you will forget to enter.

The flake.lock and the two language locks together are the reproducibility story. The flake.lock pins the Nix inputs, the uv.lock pins the Python packages and the package-lock pins the Node ones, so the environment as defined is reconstructible, and the self-modifying behaviour described earlier adds to those files rather than drifting from them.

What the design assumes, and where the boundary is

It is worth being precise about the claim, because the phrasing can be read as more than it should be.

The environment is not doing the analysis on its own. It supplies a toolchain, a documented workflow per file type, and the ability to install a missing tool on demand. The analysis is done by Claude Code reading the CLAUDE.md file and the skill that matches the artefact it is looking at. The description is that the right tools and context activate automatically, and automatic here means the context is loaded for the model, not that a decision is made without the model.

That distinction matters for anyone evaluating the project. The value is in the removal of setup friction and in the discipline-specific workflows being written down once rather than rediscovered per session. The value is not in a new analysis capability, because nothing here adds a capability that Ghidra or radare2 do not have.

The scope is also bounded in a way that is easy to miss. There are three skills and three file families. A PE binary, an APK and a HAR file are covered. A firmware image, a memory dump or a protocol capture would need a skill written for it, and the mechanism to add one is not described.

The platform assumptions are visible too. The Python floor of 3.13 is recent, the package floors are current, and the Nix experimental features requirement means the environment needs a Nix installation with flakes enabled. That is a real constraint for anyone on a system where Nix is not already present, and it is the reason the quick start opens with enabling the experimental features rather than with installing a tool.

For anyone considering this, the questions to ask are practical. Whether your targets are the three file types covered, whether a Nix dev shell fits your workstation, and whether you are comfortable with an environment that can install packages into itself during a session. The last one is a policy question as much as a technical one, and the lockfiles are there to answer it, because everything the environment adds on purpose is recorded in a file you can read.

Editorial conclusion

re-shell suits someone doing reverse engineering who wants the toolchain and the workflow written down once instead of rebuilt per session, and the three file-type skills are the part that carries the value rather than the package list. It does not suit you if your targets are outside the three families covered, since there is no described way to add a fourth skill, and it does not suit you on a machine without Nix, since the quick start assumes flakes and nix-command are already enabled. Before you use it on real work, decide how you feel about an environment that installs packages into itself during a session, and check that the uv.lock, package-lock.json and flake.lock are committed so the additions are reviewable.

Frequently asked questions

Official sources

1. Issues
2. README
3. schlarpc/re-shell on GitHub