REDasm for Cross-Platform Binary Analysis and Legacy Formats
The Open Source Disassembler
At a glance
- What is it?
- REDasm is a C++ disassembler and binary analysis tool with a C17 core, Qt6 GUI, runtime-loaded plugins, and support for modern and legacy executables. It fits reverse engineers and preservation projects that need interactive analysis with persistent project data.
- Who is it for?
- REDasm fits reverse engineers, ROM and software-preservation specialists, and developers who need a native GUI with project persistence. It is less suitable for teams requiring official packages on macOS, FreeBSD, or Haiku, or users who need only a small command-line decoder.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly C++, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
REDasm's analysis boundary
REDasm targets the point where a binary needs to be inspected beyond file headers or raw bytes. The README describes support for multiple CPU architectures and executable formats, with a particular emphasis on DOS, Win16, OS/2, console, and legacy software. That scope makes it relevant to hobbyists working with ROMs and older executables, as well as professional reverse engineers examining PE and ELF files.
The project is not limited to producing assembly text. Its documented analysis surface includes an interactive listing, function-level control flow graphs, cross-references, string detection, automatic function recovery, typed data, symbols, imports, exports, segments, and an integrated hex view. Projects can be saved and loaded so renames, comments, types, and other analysis results remain available in a later session. Patching and export of analysis data are also documented.
That feature set places REDasm closer to a workbench than a single-purpose decoder. It is useful when the goal is to move from an unfamiliar binary toward named functions, identified data, navigation between code and references, or a preserved record of an analysis. It does not make every listed format or architecture equally mature. The README assigns different status levels to loaders, processors, and analyzers, so those levels should be checked before selecting it for a specific archive or product family.
Core, plugins, and the Qt6 analysis surface
REDasm is split across several repositories, including a native core and a desktop GUI. According to the design principles, the core is written in C17 and does not depend on a virtual machine, runtime, or interpreter. The GUI is written with Qt6 and is described as sitting above the core API. This separation provides the analysis engine with a public C API while keeping interactive features together with the engine rather than treating them as a separate application layer.
Extensions are runtime-loaded shared libraries. The README specifically says that adding a CPU architecture or file format does not require changing the core. That arrangement keeps format and processor support modular, but an adoption decision should include the availability and maturity of the relevant plugin. A format listed as functional or experimental is not equivalent to a production-ready loader.
The analysis model includes RDIL, a minimal architecture-neutral intermediate language used for analysis and lifting. The README does not describe the full RDIL grammar or the complete set of analysis passes. Developers who intend to extend the engine should consult the core repository and API documentation rather than assume that RDIL is a complete public interchange format. The repository layout contains `src/`, `cmake/`, `res/`, and top-level CMake files. The README directs source builds to a separate workspace repository.
Platform and format coverage to verify
Windows 10+ with Visual Studio 2022 and Linux on Ubuntu 24.04 or Debian 13 are the project's S-level platforms. The README says these are actively developed and tested, with official prebuilt binaries. Windows builds are portable and do not require installation. Linux builds are distributed as AppImage files and are described as running on reasonably recent distributions.
FreeBSD 15.1 and macOS have CI coverage for compilation and the full automated test suite, but they do not have official binaries and have not received manual GUI testing according to the platform table. Haiku R1/beta6 has only compile verification because the automated `tier0` suite hangs indefinitely, with the root cause unidentified. This is a specific operational limitation for anyone packaging REDasm on Haiku. The README also says that other platforms require contributed changes.
Format maturity varies. PE, PE+, ELF, and ELF64 are S-level. NE, LE, LX, and PSX EXE are A-level. MZ, PSX BIOS, XBE, ZX Spectrum formats, and NES are B-level. NES support is limited to iNES with mapper 0, also known as NROM. Processor support is strongest for x86 and x86_64, followed by MIPS, ARM and Thumb, and ARM64. Z80 and MOS6502 are functional at B level. These distinctions are more useful for adoption than the broad statement that REDasm supports many formats.
Downloading and completing a first analysis
The README does not provide an install command or a command-line quick start. It directs users to the Releases page for pre-built binaries. Linux users are offered an AppImage, while Windows users are offered a portable build. Nightly builds are also produced from `master` and are GPG signed, but the README warns that they track development closely and may be unstable.
A first session can begin by downloading the appropriate release artifact, launching the REDasm application, opening a supported executable, and inspecting the initial disassembly listing. The README does not document the exact menu sequence or command-line flags, so a verified UI procedure cannot go beyond that workflow. After opening the file, the documented panels can be used to inspect segments, imports, exports, symbols, strings, and problems. Renaming, comments, typed data, cross-reference navigation, graph inspection, and project save/load are available from the analysis interface.
For source users, this repository does not provide local build commands. The README says that the separate workspace repository fetches and builds all component repositories together, and that requirements, build steps, and version pinning are documented in the workspace README. A reproducible source build should follow that document rather than treating `CMakeLists.txt` as a complete setup guide.
Analysis features with direct engineering consequences
The listing is interactive, which means an analyst can alter the representation while inspecting the binary instead of waiting for a final text export. Renaming and comments preserve human interpretation. Typed data, including structs, unions, enums, and typedefs, can be applied directly in the listing, so type information can remain attached to the addresses under examination.
The control flow graph operates at function granularity and is synchronized with the listing. This is narrower than a whole-program graph, but it keeps the view tied to the functions being analyzed. Cross-references cover code and data and include navigable history, which helps an analyst move from a suspected reference back to its source and return to the prior location. String detection handles ASCII, UTF-16, and Latin-1 wide strings. The integrated hex view provides a way to compare the structured analysis with raw bytes.
Automatic function recovery should not be treated as proof that every function boundary is correct. The README does not state how conservative recovery is, how false positives are presented, or whether an analyst can distinguish inferred functions from confirmed ones. The `problems` panel is documented, but its categories are not. These omissions matter when the result is used for patching, preservation, or documentation.
Maintenance, licensing, and operational limits
The repository is not archived, and the last push was on 2026-10-14. Recent releases include `v4.0.0-beta3` on 2026-09-02, `v4.0.0-beta2` on 2026-08-05, and `v4.0.0-beta1` on 2026-06-23. The sequence shows recent development, but the current 4.0 release line is explicitly beta. Teams that require stable release packaging should account for that status.
REDasm is licensed under GPL-3.0. The README describes an open core and plugins under GPL, with a public C API. The repository's `LICENSE` file and component notices should be reviewed before distributing binaries or plugins, especially in products that combine them with other software.
A real alternative is a manual static-analysis workflow built around raw hex inspection and conventional text disassembly output. That approach may fit a one-off inspection with no need for names, types, graphs, or saved projects, but it does not provide REDasm's synchronized GUI, runtime plugins, or analysis persistence. Conversely, teams that require scripting across many binaries may need to inspect the public C API first, because the README does not document a complete CLI or automation interface.
Editorial conclusion
REDasm fits reverse engineers, ROM and software-preservation specialists, and developers who need a native GUI with project persistence. It is less suitable for teams requiring official packages on macOS, FreeBSD, or Haiku, or users who need only a small command-line decoder. Verify the required format and architecture status first, then confirm whether the workflow requires the C API or the Qt6 desktop application.
Frequently asked questions
How do I install REDasm on Windows or Linux?
The README directs users to the Releases page. Windows has a portable build that does not require installation, and Linux has an AppImage. The README does not provide a package-manager or command-line installation procedure.
Which executable formats does REDasm support?
REDasm documents PE, PE+, ELF, ELF64, NE, LE, LX, PSX EXE, MZ, PSX BIOS, XBE, ZX Spectrum, and NES formats. Their maturity differs, and NES support is limited to iNES mapper 0.
Can REDasm save reverse-engineering changes between sessions?
Yes. The documented project save/load feature is intended to preserve analysis results, including renames, comments, and related work, so an analysis does not have to be recreated from the original binary each time.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/redasm-dev-redasm)Was this useful?