reko

Reko (Swedish: “decent, obliging”) is a C# project containing a decompiler for machine code binaries. This project is freely available under the GNU General Public License.

The project consists of front ends, the core decompiler engine, and back ends to help it achieve its goals. A command-line, a Windows GUI, and an ASP.NET front end exist at the time of writing. The decompiler engine receives inputs from the front ends in the form of either individual executable files or decompiler project files. Reko project files contain additional information about a binary file, helpful to the decompilation process or for formatting the output. The decompiler engine then proceeds to analyze the input binary.

Reko has the ambition of supporting decompilation of various processor architectures and executable file formats with minimal user intervention.

Reko consists of a central .NET assembly Reko.Decompiler.dll which contains the central core logic. Leaving aside the user interface for a moment, the Reko can at a glance be considered a pipeline. The first stage of the pipeline loads the executable we wish to decompile. Later stages perform different kinds of analyses, extracting information from the machine language where they can and aggregating it into structured information (such as Procedures and data types). The final stage is the output stage, where the source code is emitted into files.

A central tenet is that Reko is extensible: wherever possible, we strive to avoid hard-coding knowledge about specific platforms, processors, or file formats in the core decompiler. Instead, such special knowledge is farmed out in separate assemblies. Examples:

• Reko.Arch.X86.dll – provides support for disassembling Intel X86 binaries.
• Reko.ImageLoaders.MzExe.dll – understands how to load MS-DOS executable files and all related formats
• Reko.ImageLoaders.Elf.dll – understands the ELF executable file format.

The ImageMap data structure keeps track of the address space of a binary that Reko is analyzing. A binary, after being loaded into memory, consists of one or more ImageSegments, each of which has a starting address and size (or extent). Each image segment also has a reference to the MemoryArea that contains its bytes. You can think of the ImageSegments as functioning like “windows” onto a MemoryArea. Note that there one-to-many relation between MemoryAreas and ImageSegments. A typical PE or ELF executable will have logically distinct segments and memory areas:

+---------------+                     +---------------+--------------+

| .text section |                     | .data section | .bss section |

| 0x00401000    |                     | 0x00402000    | 0x00402800   |

+---------------+                     +---------------+--------------+

       ↓                                      ↓              ↓

+---------------+                     +------------------------------+

| Memory area 1 |                     | Memory area 2                |

| 0x00401000    |                     | 0x00402000                   |

+---------------+                     +------------------------------+

while an MS-DOS executable will typically be loaded into a single memory area, and all segments will refer to the same memory area

+----------------+     +----------------+       +----------------+

+ segment 0x0810 |     | segment 0x0CFA |       | segment 0x15AD |

+----------------+     +----------------+       +----------------+

        ↓                      ↓                        ↓

+----------------------------------------------------------------+

| Memory image                                                   |

| 0x0810:0000                                                    |

+----------------------------------------------------------------+

In addition to maintaining a map of all the segments, the ImageMap also maintains in its Items dictionary the locations of any identified items as Reko performs its analysis. Some executable image file formats contain information like the entry points or symbols identifying machine language procedures or data locations. Reko can use this information to populate the image map before starting its scanning phase. The scanning phase will discover more items and add them to the ImageMap. The user interface also allows the user to add items that Reko can’t discover itself.

Changelog v0.11.3

The largest new feature of this release is the support for disassembling, rewriting, and emulation of instructions of the AEON (or BEON, or R2) processor. It is the first architecture in Reko implemented with no manual — we’ve been unable to find the instruction set described in a publicly available resource. Instead, thanks to the hard work of @throwaway96, most of the instruction set has been reverse engineered. Many thanks for this great effort!

@smx-smx improved the stability of the build and eliminated redundant compilations of the build tools, resulting in a faster build overall.

Some other features added are:

• Introduced the notion of Unlikely instructions: instructions that while well-formed are unlikely to be present in a “normal” program. Reko can optionally be instructed to treat such unlikely instructions as invalid
• The user may also optionally instruct the Reko to treat protected/system instructions as invalid.
• Since the move to .NET 6, Reko’s custom 16-bit IEEE float implementation became redundant and was removed.
• The GUI client now supports multiple scanning heuristics.
• Support for user-defined segments was added.
• Improvements in handling of varargs procedures.
• Switch statements for MIPS, MIL-STD-1750A and Intel 8051 improved.

Download && Tutorial

Copyright (C) 2017 uxmal