Reko: a GPL-2.0 binary decompiler with a C# engine and multiple front ends

What Reko decompiles, and who the tool is actually for

Reko is a decompiler for machine code binaries, written in C# and released under the GNU General Public License. The README describes it as a general purpose decompiler and states the ambition of supporting decompilation of various processor architectures and executable file formats with minimal user intervention. The topic list on the repository names aarch64, arm, m68k, risc-v, x86 and x86-64, so the intended audience is people who work across architectures rather than specialists in one instruction set.

The people who get value here are reverse engineers, security researchers and developers who have lost source for their own shipped binaries. The README is explicit about the legal boundary: many software licenses prohibit decompilation or other reverse engineering of machine code binaries, and it asks that you use the decompiler only if you have legal rights to decompile the binary, for instance if the binary is your own. That sentence does more work than any feature list. It tells you this is a tool for owners and authorised analysts, not a general purpose cracking aid.

A second audience is tooling builders. Because the project is split into front ends, a core engine and back ends, the engine can be driven from a project file as well as from a raw executable. If you want to feed extra information into decompilation, the project file is the seam the README points at.

Front ends, engine and back ends: the architecture the README describes

The README divides the project into front ends, a core decompiler engine and back ends. Front ends accept input in one of two forms: individual executable files, or decompiler project files. Project files carry optional additional information about a binary that helps the decompilation process or formats the output. The engine then analyses the input binary.

The repository layout supports that description. The solution folder Drivers holds the executables that act as user interfaces. WindowsDecompiler is the Windows Forms GUI client. CmdLine is the command line driver. AvaloniaShell is the cross-platform Avalonia GUI, and the README labels it still under construction, so the cross-platform story is real but unfinished.

Two other details matter for anyone planning to embed or extend Reko. The build depends on a NativeProxy project that uses CMake, and Visual Studio can try to rebuild it depending on what you do. The README also notes an issue in certain Visual Studio versions where the IDE hangs on Running Background Tasks; the workaround is to right click the NativeProxy project in Solution Explorer and choose Unload Project. That problem does not occur when building from the command line, which is a quiet argument for the command line path.

Installing Reko and running a first decompile

The README lists one prerequisite: .NET 9.0, with a link to the Microsoft download page. After that you either download binaries from the integration build server, download an official release, or build from source.

Official releases are published every few months on GitHub and SourceForge, so the simplest path for a non-developer is to take an installer from the releases page and run it on the target machine. If you would rather build, clone the repository and use the .NET 9.0 SDK with the solution file Reko-decompiler.slnx. The README gives this command line build, which you run from the repository root:

dotnet msbuild -p:Platform={platform} -p:Configuration={config} -v:m -t:build_solution -m ./src/BuildTargets/BuildTargets.csproj

Replace {config} with Debug or Release, and {platform} with x64, x86 or ARM64. The build process copies all the necessary files into a single directory, so you do not need an installer to get a working set of binaries. WiX is only used for MSI packaging, and the README says you can safely ignore WiX warnings and errors if you are not building an installer.

Once built, the drivers live under the Drivers solution folder. WindowsDecompiler is the Windows Forms GUI, CmdLine is the command line driver, and AvaloniaShell is the cross-platform GUI that the README describes as still under construction. For a first run, pick the driver that matches your platform and load a binary you own. The README's own screenshots show a byte map view and a decompiled structure view of a loaded ARM binary executable, which is a fair picture of what the GUI presents: memory layout on one side, reconstructed code on the other.

The GUI is not finished, and that is the main practical limitation

The strongest limitation is stated in the README itself: the cross-platform Avalonia GUI is under development, and the Drivers description repeats that AvaloniaShell is still under construction. If you are on Linux or macOS and you want a graphical workflow, the documented graphical option is the Windows Forms client, which is Windows only. The remaining cross-platform path is the command line driver.

That shapes who should consider Reko at all. A team that needs a polished, uniform GUI across operating systems is going to spend its time on the wrong problem. A team that can live with a command line driver, or with Windows for the GUI, is working with what actually exists.

Support expectations are the second constraint, and the README is unusually direct about it. It says Reko is built by volunteers on their spare time and asks you to adjust your response-time expectations accordingly. Issues and Reko-related questions go to the GitHub issue tracker, with a Discord chatroom as the other channel. There is no commercial support tier described anywhere in the README.

A third limitation is legal rather than technical. The README's warning about licences that prohibit decompilation is not boilerplate. If you do not hold the rights to the binary, the tool being open source does not change your position.

How Reko differs from Ghidra and other decompiler toolchains

The obvious comparison is Ghidra, which is also a multi-architecture decompiler with a GUI, and which is commonly reached for when someone wants a free reverse engineering suite. The difference in approach is packaging and language. Ghidra is a Java application distributed as a ready-to-run release. Reko is a C# project whose documented install path starts with installing .NET 9.0, and whose documented build path is a dotnet msbuild invocation against BuildTargets.csproj. If your environment already standardises on .NET, Reko sits inside it; if it standardises on the JVM, Ghidra does.

The second difference is the project file. Reko accepts either an executable or a decompiler project file, and the project file carries optional extra information that helps decompilation or formats output. That is a different centre of gravity from tools that treat a binary as the only input. It suggests a workflow where you build up per-binary knowledge over repeated sessions rather than starting cold each time.

A third difference is scope discipline. The README points at a supported binaries wiki page for the complete list of architectures and formats, and it does not claim universal coverage. Treat that wiki page as the deciding document. If your target is not on it, the comparison with any other decompiler is moot.

Licence, build cost and what upgrading looks like

Reko is under the GNU General Public License, and the repository carries COPYING and COPYING.rtf at the top level alongside the README, so the licence text ships with the source. The README states the project is freely available under the GPL. If you plan to redistribute Reko or a modified version, read the licence text rather than a summary; this article is not legal advice, and the obligations that attach to a GPL-2.0 binary are a question for your own counsel.

The maintenance picture from the repository is straightforward. The last push was on 2026-09-11, and the most recent release is version 0.12.4 from 2026-07-29, preceded by version 0.12.3 on 2026-06-16 and version 0.12.2 on 2025-12-18. The README's own description of release cadence is that official releases are published every few months, which matches those dates. The repository is not archived.

Upgrade cost is mostly a .NET version question. The README requires .NET 9.0 for both running and building, and the build command takes a platform and a configuration. If you build your own binaries, an upgrade means pulling the new source and rebuilding with the same command. If you rely on the integration build server output, you are taking whatever the GitHub Actions workflow produced. The README does not document a rollback procedure, so keep the previous build directory if you need to go back.

Editorial conclusion

Reko fits engineers who are comfortable with .NET 9.0, want a decompiler they can build from source and extend, and work on binaries they have the legal right to reverse engineer. It is a poor fit if you need a finished cross-platform GUI or a one-command install. Before adopting it, check the supported binaries wiki page against your target architecture and file format, then build the solution once with dotnet msbuild to confirm your toolchain works.

Frequently asked questions

Official sources

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