REHex: a hex editor built for reverse engineering, not for patching a save file

What REHex is for, and who it is actually for

The README calls REHex a cross-platform hex editor for reverse engineering, and everything else. The qualifier matters. A general-purpose hex editor assumes you know the offset you want and you are there to change it. REHex assumes the opposite: you have a file whose structure you do not yet understand, and you want to build that understanding inside the editor.

The feature list reads like a checklist for that job. Inline disassembly of machine code, decoding of integer and floating point value types, highlighting and annotation of byte ranges, virtual address mapping, binary templates that annotate data automatically, and side by side comparison of whole files or selections. Each of those answers a question you ask while reversing: what instruction is at this offset, what does this four-byte field mean, where does this range end, what address does this offset correspond to at runtime, what changed between two firmware images.

The audience is narrow on purpose. Someone editing a config file or fixing a corrupted header will find the interface heavier than they need. Someone mapping a proprietary container format, a firmware image or an undocumented binary will find the extra machinery is the point. The README also notes large file support at 1TB and above, which signals the intended scale: disk images and dumps, not text files.

How the editor is put together: documents, ranges and plugins

The repository layout shows the architecture more clearly than the README does. There is a src/ directory for the application, an include/ directory alongside it, and a separate plugins/ directory. wxWidgets and wxLua appear as vendored top-level entries, and wxFreeChart sits next to them, which tells you the UI, the scripting layer and the charting used for bitmap visualisation are all part of the same build tree rather than optional add-ons fetched at configure time.

The Makefile confirms the dependency model. It defines a pkg-select-ab helper that picks the first of two package names present in the pkg-config database and errors if neither exists, and a config-test-flag helper that compiles a small probe program to decide whether extra link flags are needed. That is a build system written to survive distribution differences rather than to assume one Linux. It also explains why the README points at separate Makefile variants for MSVC, macOS, Windows and AppImage packaging instead of a single portable build file.

The data model implied by the feature list is offset-based and range-based. Annotations attach to ranges of bytes, virtual address mappings translate between file offsets and runtime addresses, and binary templates generate those annotations from a description of the format. Scripting through Lua reaches the same objects, which is why the manual maintains a separate API reference. If you have used 010 Editor, the template concept will be familiar; REHex implements it with its own template language rather than an existing one.

Installing REHex from a distribution repository

The README directs most users to the Releases page, which carries standalone packages for Windows and macOS plus installable packages for popular Linux distributions. The same packages are built for Git commits, so an unreleased build is available if you look for the tick. If you would rather use a package repository, the README gives per-distribution instructions.

On Debian, the first step is fetching the maintainer's APT signing key into the keyrings directory:

sudo wget -O /etc/apt/keyrings/solemnwarning-archive-keyring.gpg \
    https://solemnwarning.github.io/solemnwarning-archive-keyring.gpg

You then add two lines to /etc/apt/sources.list, one for binaries and one for sources, both signed by that key and both pointing at repos.solemnwarning.net/debian/ with a CODENAME placeholder. The README notes that CODENAME must be replaced with the version you are running, giving trixie or bookworm as examples. Ubuntu follows the same shape against repos.solemnwarning.net/ubuntu/, with arch=amd64 in the source line and noble or resolute as the examples. Ubuntu users also need the universe repository enabled for some dependencies.

After the sources are in place, the install is the ordinary two commands:

sudo apt-get update
sudo apt-get install rehex

Fedora and CentOS go through a COPR instead. Fedora is two commands, enabling the repository and installing:

sudo dnf copr enable solemnwarning/rehex
sudo dnf install rehex

CentOS needs epel-release first. openSUSE adds an OBS repository named editors, refreshes, and installs rehex with zypper. FreeBSD is a single pkg install rehex. Gentoo users go through the pentoo overlay: install eselect-repository with the git USE flag, enable pentoo, sync with emaint, then emerge app-editors/rehex. Building from source is not covered in the README; it points at COMPILING.md, and the Makefile variants in the repository root show that the build is per-platform rather than one portable recipe.

Where REHex stops being the right tool

The README does not document rollback, and it does not describe an undo model. For an editor whose whole purpose is writing bytes into files, that silence is worth taking seriously. If you are modifying a disk image or a firmware blob, keep your own copy before you start, because the documentation gives you no stated guarantee about how far back you can step.

The platform list is desktop only: Windows, Linux, macOS and BSD. There is no browser build and no mobile target in the README. If your workflow is opening a file on a phone or in a tab, this is the wrong project, and no amount of feature depth compensates.

The scripting and template features also carry a learning cost that the README does not advertise. Lua scripting links to a separate API reference, and binary templates are described as similar to 010 Editor, which means the template language is its own thing to learn. For a single one-off edit, that cost is pure overhead. REHex pays off when you will open the same format repeatedly and want the annotations to persist as a reusable description rather than as notes in your head.

Finally, the licensing constrains redistribution. GPL-2.0 is stated in the repository, and the Makefile header carries the standard GPL version 2 notice. If you intend to ship REHex inside a proprietary product, or link its code into one, that is a conversation for your own legal review, not something the README resolves.

REHex compared with ImHex and HexWalk

The two names that come up when people search around this project are ImHex and HexWalk, and the difference is mostly about where the pattern language lives.

ImHex is built around its own pattern language for describing file formats, and it has grown a plugin ecosystem and a web version. REHex takes the 010 Editor template idea instead, and its scripting surface is Lua rather than a purpose-built pattern language. If your team already writes 010 Editor templates, the mental transfer to REHex is shorter than learning a new pattern syntax. If you want a browser-accessible editor, ImHex has one and REHex does not.

HexWalk is a smaller, more direct hex editor. It does not carry the disassembly, virtual address mapping or template machinery that REHex does, which makes it lighter to install and quicker to open for a simple inspection. The trade is that anything requiring structured annotation of a format has to be done by hand.

The honest framing is that REHex sits between them: heavier than a plain hex editor, less of a platform than ImHex has become. Whether that middle position suits you depends on whether you want disassembly and templates in one window without adopting a larger ecosystem.

Maintenance, releases and the cost of keeping up

The repository is not archived, and the last push was on 2026-07-23. The release history shows 0.64.0 on 2026-04-04, 0.63.4 on 2025-11-23 and 0.63.3 on 2025-09-09. That is a project that ships on a roughly seasonal cadence rather than continuously, with patch releases between feature releases.

The upgrade cost depends on how you install it. If you use the Debian or Ubuntu repository described in the README, upgrades arrive through apt-get update and apt-get install rehex, and the CODENAME placeholder in your sources.list is the thing that breaks when you move to a new distribution release. Fedora and CentOS users track the COPR; openSUSE users track the editors OBS repository; FreeBSD users get whatever the ports tree carries. Distribution packages lag the Releases page, so a bug fixed in a recent version may take a while to reach you.

Building from source is the option with the highest ongoing cost, because the Makefile variants are split by platform and the build probes for dependencies through pkg-config. That is fine for a one-time build and tedious if you intend to track master. The GPL-2.0 licence is the other long-term consideration: it governs what you can do with modified versions you distribute, and the repository states it plainly in LICENSE.txt and in the Makefile header.

Editorial conclusion

Adopt REHex if you already know what a byte offset means and you want disassembly, templates and scripting in the same window as the hex dump. Skip it if you need a one-off byte patch on a phone or a browser tab, since the README lists desktop platforms only. Before committing, check the manual for the scripting API and confirm your distribution is covered by the packages listed in the README.

Frequently asked questions

Official sources

1. License: GPL-2.0
2. Project website
3. README
4. Releases
5. solemnwarning/rehex on GitHub