Chepy: CyberChef's recipe model as a Python library and CLI

What Chepy is

Chepy is a Python library with a handy CLI that is aimed to mirror some of the capabilities of CyberChef, and a reasonable amount of effort was put behind it to make it compatible with the various functionalities that CyberChef offers, all in a pure Pythonic manner.

The CyberChef concept of stacking different modules is kept alive in Chepy, and that is the central design decision. In CyberChef you drag operations into a pipeline and they run left to right. In Chepy the same pipeline is a chain of method calls, which means the recipe is a piece of Python rather than a picture in a browser.

That is the whole value proposition, and it comes with the obvious caveat, stated in the README: there is still a long way to go for Chepy as it does not offer every single ability of CyberChef.

The comparison section in the README lists the advantages as pure Python with a supporting and accessible Python API, a CLI with full autocompletion, support for PE, ELF and other file format specific parsing, extensibility through plugins, and scalability through the full Python library. It also notes that the Chepy Python library is significantly faster than the CyberChef Node library, that it works with HTTP and HTTPS requests without CORS issues, and that it can interface with the full CyberChef web app to a certain degree, so it is easy to move from one to the other if you need to.

The project is GPL-3.0 licensed, the documentation is on Read the Docs, the plugins have their own documentation, and the current release is 7.6.0 from 2026-04-17, with the last push to the repository on 2026-04-27.

The chaining API, and what the example shows

The example in the README is the clearest statement of the model, and it is worth reading line by line because each call is one step of a CyberChef recipe.

from chepy import Chepy

file_path = "/tmp/demo/encoding"

print(
    Chepy(file_path)
    .load_file()
    .reverse()
    .rot_13()
    .from_base64()
    .from_base32()
    .hexdump_to_str()
    .o
)

The chain loads a file, reverses the bytes, applies rot13, decodes base64, decodes base32, converts a hexdump to a string, and then the terminal .o prints the result.

Two details are worth noting. The methods are named after the operation, and the encodings use the from prefix because the direction of the operation is a property of the data rather than of the call, so from_base64 and from_base32 are unambiguous when the chain contains several of them. And the final .o is the output accessor rather than a print method, which means the result of a chain is a value you can keep, pass to another function, or print, and the CLI prints it for you.

The same chain is the whole mental model. If you have used CyberChef, this is the same recipe with a different syntax, and the README's own comparison puts a CyberChef screenshot next to this snippet to make the mapping obvious.

The CLI, and the plugin system

The command line interface is the part that makes Chepy useful in a terminal, and the README highlights that it has full autocompletion.

That is a real feature rather than a detail. The operation names are long and there are many of them, and typing them by hand is a good way to get one subtly wrong. Autocompletion also exposes the naming scheme, which is what tells you which of the two directions a given operation works in.

The interface is also the reason the underlying library is built around the same chaining model, because a shell pipeline and a method chain are the same idea and the operations compose in the same order either way.

The plugin system is the extension mechanism, and it is documented separately. The stated advantages include extending the tool through plugins and the note that Chepy can interface with the full CyberChef web app to a certain degree, so a workflow can start in the shell and continue in the browser when it needs the operation that only exists there.

The plugin extras are also where the file format support comes from. The optional dependency set includes scapy for network data, pefile and pyelftools for Windows and ELF binaries, pydriller for analysing binaries, pyexiftool for image metadata, a Markdown library, and a user agent parser, with the magic file support coming from a separate Chepy ML plugin. The project is also listed in the Remnux Linux distribution, which is the clearest evidence that the tool is used by people doing this work for a living.

Installing it, three ways

There are three installation routes, and each of them suits a different situation.

The first is from PyPI, and it is one line.

pip3 install chepy
# optionally with extra requirements
pip3 install chepy[extras]

The extras variant pulls in the plugin dependencies, which is the difference between the core library and the library with the file format parsing.

The second is from the source, and the recursive clone matters because the plugins live in submodules. The author explains the editable install in the comment, so that a later git pull does not require reinstalling unless the dependencies have changed.

git clone --recursive https://github.com/securisec/chepy.git
cd chepy
pip3 install -e .

The third is a standalone binary, which is the one to reach for when you want to drop the tool on a machine with no Python environment of your own. It is built with PyInstaller from the cli.py entry point, packaging all the dependencies together, and the binary ends up in the dist folder.

git clone https://github.com/securisec/chepy.git
cd chepy
pip install .
pip install pyinstaller
pyinstaller cli.py --name chepy --onefile

There is a Docker route in the repository as well, with a container that has a data volume and the chepy executable as its entry point, although the README marks that section as commented out.

The dependency footprint and the Python ceiling

The requirements list and the setup script together describe how heavy this tool is, and it is worth knowing before you install it.

The core requirements are a long list. There are encoding libraries, base58, msgpack, lz4, parsel for selectors, jmespath for JSON queries, pycryptodome and pycipher for the crypto operations, PGPy for OpenPGP, passlib for password hashing, pyOpenSSL, exrex for regular expression conversion, a colour library, a prompt toolkit, and the fire library that provides the command line parsing with autocompletion. There is a lazy import mechanism in there, which is the standard trick for keeping a library with this many optional capabilities from paying for all of them at import time.

The setup script then adds the plugin dependencies as an extra, with the plugin list containing scapy, pefile, pyelftools, pydriller, pyexiftool, Markdown and a user agent parser, and the core extra is requests.

Two constraints in the metadata are worth flagging. The classifier says Python 3.12 and the requirement is a version below 3.13, so the package will not install on a newer interpreter as it stands, which is the kind of ceiling that matters in a container image you rebuild regularly. And the version number is read out of a version file in the package with exec, which is a small thing that means there is one source of truth for the version.

The console entry point is declared as a script, so the command is chepy, and the packages exclude the tests and the docs directory from the distribution.

How the project builds and tests itself

The Makefile and the Dockerfile show two different testing strategies, and the second one is more thorough than most projects of this size manage.

The Makefile has a test target that runs the core test suite with coverage, using a separate coverage configuration file, and a test-all target that additionally runs the plugin test suite. Both disable the normal pytest configuration with the noconftest flag, which keeps the plugin tests isolated from the core ones, and both set an environment variable that the project uses to select the coverage core.

The Dockerfile does something more interesting. The build stage installs the requirements, creates a virtual environment, installs the test tooling including a static analysis tool, and copies the project in. It then removes the plugin requirements line from the plugin configuration so the plugins can be installed separately, installs the project in editable mode, installs it again inside the virtual environment, and copies the plugin data files into the right place in the virtual environment's site-packages.

After that it runs the core test suite with coverage reporting, rewrites a configuration flag in the user config to enable plugins, and runs the plugin test suite. Then it checks that the package imports at all, runs the static analysis pass with a list of specific checks ignored, and strips the tests, the build output, the docs and the ignore directory out of the image.

The final stage is a slim Python base with exiftool and the magic library installed, the application copied in, a smoke check that the binary runs and prints its version, the plugin flag enabled in the config, a data volume declared and the chepy executable as the entry point.

That is a lot of machinery for a research tool, and it is the part of the repository that shows the project is maintained rather than merely published.

Editorial conclusion

Adopt Chepy if you want CyberChef style operations in a script or on a machine with no browser, because the chaining API is the same model and the library is pure Python, so it composes with everything else you have installed. Do not expect parity, since the README states plainly that Chepy does not offer every single thing CyberChef does. Before you install it in a pipeline, check the Python ceiling, because the package metadata requires a version below 3.13, and add the extras only if you need the file format parsing, since the plugin dependencies pull in a much larger set of libraries.

Frequently asked questions

Official sources

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