RetDec: a retargetable machine-code decompiler that turns binaries into C

What RetDec is for, and who actually needs it

RetDec is a decompiler: it takes a compiled binary and tries to give you back something that looks like source. The README describes it as "a retargetable machine-code decompiler based on LLVM", and the word retargetable is doing the real work. The project is not tied to one architecture, one operating system or one file format. It accepts ELF, PE, Mach-O, COFF, AR archives, Intel HEX and raw machine code, and it covers 32-bit Intel x86, ARM, MIPS, PIC32 and PowerPC alongside 64-bit x86-64 and ARM64.

That breadth is the reason to pick it over a narrower tool. If your work involves the same firmware family every day, a single-architecture decompiler is fine. If you are handed an unknown blob and you do not yet know whether it is a MIPS router image or a stripped Windows PE, a tool that tries to identify the format and architecture before decompiling saves you a separate triage step. RetDec also detects compilers and packers, removes statically linked library code by signature, extracts DWARF and PDB debug information when present, reconstructs C++ class hierarchies from RTTI and vtables, and demangles symbols from GCC, MSVC and Borland binaries.

The audience is therefore narrow but real: reverse engineers doing malware triage, firmware analysts, and developers who want decompilation as a step inside a larger automated pipeline rather than as an interactive session. The output languages matter here. RetDec emits C and a Python-like language, plus call graphs, control-flow graphs and statistics. That makes it a component you can wire into a script, not just a window you stare at.

How RetDec gets from a binary to readable C

The pipeline is visible in the feature list rather than in a single architecture diagram. Loading and instruction decoding come first, then compiler and packer detection, then signature-based removal of statically linked library code. That last step is the one that changes the output most: a statically linked binary contains a large amount of library code that is not the interesting part, and stripping it by signature keeps the decompiled listing focused on the code the author actually wrote.

From there the project reconstructs instruction idioms, which is the layer where patterns like a hand-rolled loop or a bit-twiddling sequence get folded back into something closer to the original expression. Debug information from DWARF or PDB is extracted and used when available, which improves function and type recovery. C++ binaries get additional treatment: RTTI and vtables are used to detect and reconstruct class hierarchies, and symbols are demangled for GCC, MSVC and Borland mangling schemes.

The final stage reconstructs functions, types and high-level constructs and emits them in C or the Python-like language. An integrated disassembler and the graph and statistics generators sit alongside that output, so you can look at the low-level view when the high-level view is wrong. LLVM is the stated foundation, which is consistent with a project that needs an instruction-level intermediate representation before it can lift anything to a higher level. What the README does not describe is the internal pass ordering or how the decompiler decides between competing reconstructions. If you need to understand why a particular construct came out the way it did, the wiki is described as "in progress", so expect to read the source instead.

Installing RetDec and decompiling your first binary

The README gives two routes. The first is to download and unpack a pre-built stable or bleeding-edge package from the releases page, then follow the instructions in the retdec/share/retdec/README.md file inside the unpacked package. The second is to build from source. The README states that an installed version requires approximately 5 to 6 GB of free disk space, which is worth checking before you start.

On Linux, macOS and FreeBSD the entry point is the same binary. To decompile a file named test.exe:

$RETDEC_INSTALL_DIR/bin/retdec-decompiler test.exe

On Windows the executable carries an .exe suffix:

$RETDEC_INSTALL_DIR\bin\retdec-decompiler.exe test.exe

The README notes that Windows also needs the Microsoft Visual C++ Redistributable for Visual Studio 2017 installed first. UPX and Graphviz are listed as optional dependencies: UPX enables the UPX unpacker in the preprocessing stage, and Graphviz is what you need if you want call or control-flow graphs generated. Install both with your distribution's package manager on Linux, or from the linked installers on Windows. To see the full option set, run the decompiler with --help.

If you would rather not build the toolchain yourself, the repository ships a Dockerfile that builds RetDec on ubuntu:focal and produces an image with /retdec-install/bin already on PATH. The build stage installs build-essential, cmake, git, python3, doxygen, graphviz, upx, openssl, libssl-dev, zlib1g-dev, autoconf, automake, pkg-config, m4, libtool and python-is-python3, clones the repository, and runs cmake with -DCMAKE_BUILD_TYPE=Release before make install. The runtime stage keeps only openssl, graphviz, upx and python3. Expect a long first build; the Dockerfile compiles the whole project from source.

If you want to call RetDec from your own CMake project, the installed package exports a CMake config. After find_package, link against the retdec:: namespace:

find_package(retdec 5.0 REQUIRED
   COMPONENTS
      <component>
)
target_link_libraries(your-project
   PUBLIC
      retdec::<component>
)

If RetDec is not in a standard location, either append its install directory to CMAKE_PREFIX_PATH or point retdec_DIR at ${RETDEC_INSTALL_DIR}/share/retdec/cmake. The README points to the Repository Overview wiki page for the list of components and to the retdec-build-system-tests repository for working examples.

Limited maintenance mode is the constraint that matters most

The README opens with a warning that the project is in limited maintenance mode due to a lack of resources, and it spells out what that means in operational terms. Pull requests are welcomed and reviewed with priority if possible without delays. Issues are reacted on with delays up to one quarter, and they are not actively solved unless they relate to basic project maintenance. Basic maintenance continues; only a very limited development is carried on.

Read that as a support contract you do not have. If you file a bug about a mis-decompiled function in an unusual binary, the reasonable expectation from the README is a response measured in months, and possibly no fix at all unless it affects basic maintenance. The release history reinforces the point: the newest release listed is v5.0 from 2022-12-08, preceded by v4.0 in 2020 and v3.3 in 2019. The repository's last push was on 2026-05-26, so the code is not frozen, but releases are rare and the project itself describes development as very limited.

There is a second, quieter limitation in the documentation. The wiki is labelled "in progress", and the README does not document rollback, does not describe how to report a decompilation failure in a way that gets triaged, and does not give a compatibility matrix for which LLVM or CMake versions pair with which release. For a tool you plan to run inside an automated pipeline, the missing piece is a documented contract about output stability across versions. The README does not promise one.

Where RetDec is the wrong tool

RetDec is a batch decompiler. Nothing in the README describes an interactive interface. There is no GUI mentioned, no debugger integration, and no live editing of the reconstructed output. If your workflow is to set breakpoints, rename variables as you go, and follow a call graph by clicking through it, RetDec will feel like the wrong shape entirely: you get files, graphs and statistics, then you go elsewhere to work with them.

It is also the wrong tool when you need current bug fixes. The README's own warning about issue delays up to one quarter is a direct statement that the project will not keep pace with a fast-moving analysis target. If you are decompiling newly compiled malware that takes advantage of a recent compiler behaviour, a project in limited maintenance mode is a poor bet for a fix on your schedule.

The 5 to 6 GB disk requirement is a real cost in containerised or ephemeral environments, and it applies to an installed version, not to the download. Finally, decompiler output is not source. The README lists reconstruction of functions, types and high-level constructs as a feature, and that is exactly what it is: a reconstruction. Treating the emitted C as the original program will mislead you, particularly for optimised or packed binaries where the preprocessing stage had to undo work the compiler or packer did.

RetDec against Ghidra and IDA

The two names that come up most when people compare decompilers are Ghidra and IDA, and the difference is not quality but shape. Ghidra is an interactive reverse-engineering suite with a decompiler inside it. IDA is a commercial disassembler with decompiler add-ons. RetDec is a command-line decompiler that emits C or a Python-like language and can be linked into other software through its CMake components.

That difference decides most adoption questions. If you want to sit with a binary for an afternoon, renaming functions and following cross-references, an interactive suite is the better fit and RetDec's file-based output will slow you down. If you want to decompile a thousand samples unattended, or embed decompilation in a service, an interactive GUI is the wrong building block and RetDec's retdec-decompiler binary plus its library components are the more natural choice.

Architecture coverage is a second axis. RetDec explicitly lists 32-bit Intel x86, ARM, MIPS, PIC32 and PowerPC, and 64-bit x86-64 and ARM64. If your target is outside that list, the comparison is settled before it starts. The README also notes that FreeBSD support is experimental and that there are no pre-built FreeBSD ports packages, so on that platform you build from source. Weigh the maintenance warning too: a project that states issues are answered with delays up to one quarter is a different proposition from one with an active commercial or foundation-backed release train, regardless of which decompiler produces nicer output on your sample.

Licence, dependencies and what an upgrade costs

RetDec is MIT licensed, which is permissive and imposes few obligations on how you redistribute or embed it. The repository also carries LICENSE-PELIB and LICENSE-THIRD-PARTY files at the top level, so the MIT licence on the project as a whole is not the entire picture: the bundled dependencies have their own terms, and if you ship RetDec inside a product, the third-party file is the one to read. This is a description of what the repository contains, not legal advice; your own counsel should review the third-party terms against your distribution model.

The upgrade cost is unusual and worth stating plainly. The release cadence is slow, so upgrades are infrequent events rather than a monthly chore. But the gap between v4.0 in 2020 and v5.0 in 2022 means each upgrade crosses a lot of accumulated change, and the README does not publish a compatibility matrix tying releases to specific LLVM, CMake or compiler versions. If you consume RetDec as a library rather than as a binary, the CMake package version is explicit in the find_package call, and the README's example pins 5.0. That pin is your only documented stability handle. The README does not document a rollback procedure, so plan to keep the previous install directory intact rather than expecting a supported downgrade path.

Editorial conclusion

Adopt RetDec if you need a scriptable command-line decompiler that covers x86, x86-64, ARM, ARM64, MIPS, PIC32 and PowerPC from one binary, and if you can live with a project whose README states it is in limited maintenance mode, where issues are answered with delays up to one quarter. Do not adopt it if you need a maintained GUI, prompt bug fixes, or a tool with a published release cadence: the newest release listed is v5.0 from 2022-12-08. Before committing, verify three things yourself: that a pre-built package for your platform exists on the releases page, that you have 5 to 6 GB of free disk for an installed copy, and that the output for your specific binary is readable enough to work from, since no decompiler output is a drop-in replacement for source.

Frequently asked questions

Official sources

1. avast/retdec on GitHub
2. License: MIT
3. Project website
4. README
5. Releases