Reko decompiler reads program binaries, decompiles them, infers data types, and emits structured C source code. Designed with a pluggable architecture, it currently has:
- support for 68k, ARM, MIPS, PowerPC, Risc-V, Sparc, x86, Z80 processors and many more
- support for EXE, Elf, AmigaOS Hunk executable formats and many more
- support for MS-DOS, Win32, U*ix, AmigaOS , C64, ZX-81
Reko decompiler comes with a GUI and a command-line interface.
Visit https://github.com/uxmal/reko for the GIT repository.
Features
- decompiler
License
GNU General Public License version 2.0 (GPLv2)Follow Decompiler
You Might Also Like
Boost application security and continuity with SKUDONET ADC, our Open Source Load Balancer, that maximizes IT infrastructure flexibility. Additionally, save up to $470 K per incident with AI and SKUDONET solutions, further enhancing your organization’s risk management and cost-efficiency strategies.
Rate This Project
Login To Rate This Project
User Reviews
-
keeps complaining about "missing" .NET libs even after these have just been installed from th suggested Microsoft page.. cannot even be started.. very disappointingReply from Decompiler
-
For 0.7.1.0 on Windows 10 Was curious about decompiling an old device from the late 1990's... M68K with 512KB ROM code compiled from C and quite likely in a VxWork OS, dumped from EEPROM to a binary file of the same size. The Scanner function works well for recursively finding procedures as absolute and relative addressed calls. However, after performing that step, I ultimately had better results with this raw binary format searching for procedures throughout the ROM with good accuracy with the pattern matching for 4E 56 00 00 as the beginning of the procedures, followed by searches for the link instruction: 4E 56 FF, 4E 56 FE, 4E 56 FD, 4E 56 FC, 4E 56 FB, and finally 4E 56 FA. This found 95% of all executable code in the entire 512KB space. Next came strings. The string search is rudimentary and I did not find any difference between UTF-8 and the 16 bit BE and LE selections. In any case I was searching for UTF-8 zero-terminated "C" style strings. The procedure here was to search for 25 character or more strings first, then 20 character, 10 character, 6 character, and finally 3 character (tedious). Many zero terminated strings were completely missed, so I'm guessing this is a work in progress. The rest of the strings I marked manually as "sz" type, which was tedious but oddly satisfying. Marking Types: this version of Decompiler seems to not support any other type than character. If I try any other type, the types are saved to the .dcproject file, but the Serializer complains when the .dcproject is read back into Decompiler: unsupported type (or some other error like that), and the Globals list is truncated at the first occurrence of the error. I'm hoping the 0.8.0.0 or later version is due for a release here soon. I see there is some recent work done on it. The GUI is clunky, and crashes easily, but once I found the pitfalls, I could avoid them and avoid crashes. SAVE often, make frequent backups of the .dcproject file, be prepared to manually edit the .dcproject file if you Mark any type other than char or zero terminated char string. Keyboard shortcuts to often used commands would be nice, such as: Mark Type, because mouse-clicking dropdown menus repeatedly is painful. Great project! We need these tools to help preserve old proprietary technology as time marches on.
-
Constant updates, awesome support.
-
Decompiler works fine.