REC - Reverse Engineering Compiler (disponibile anche in italiano)

---

REC is a portable reverse engineering compiler, or decompiler.

It reads an executable file, and attempts to produce a C-like representation of the code and data used to build the executable file.

It is portable because it has been designed to read files produced for many different targets, and it has been compiled on several host systems.

Features
Download page
Examples
User's Manual
User's Guide
HTTP Server Setup

These are some of REC's features:

• Multitarget : REC can decompile 386, 68k, PowerPC and MIPS R3000 programs.

 
• Multiformat : REC recognizes the following file formats:
• ELF (System V Rel. 4, e.g. Linux, Solaris etc.)
• COFF (System V Rel. 3.x, e.g. SCO)
• PE (Win32 .EXE and .DLL for Microsoft Windows 95 and NT)
• AOUT (BSD derivatives, e.g. SunOS 4.x)
• Playstation PS-X (MIPS target only)
• Raw binary data (via .cmd files)

 
• Multihost : REC is available for Linux 3.0 (i386), Windows 95 and SunOS 4.1.4.

 
• Supports high-level symbolic information in COFF, ELF+STAB, AOUT+STAB.

 
• Scalable user interaction: from totally batch mode to full-screen browser-like interactive mode.

 
• HTTP server mode allows using an HTML browser as user interface

REC sources are not in the public domain.

Although REC can read Win32 executable (aka PE) files produced by Visual C++ or Visual Basic 5, there are limitations on the output produced. REC will try to use whatever information is present in the .EXE symbol table. If the .EXE file was compiled without debugging information, if a program data base file (.PDB) or Codeview (C7) format was used, or if the optimization option of the compiler was enabled, the output produced will not be very good. Moreover, Visual Basic 5 executable files are a mix of Subroutine code and Form data. It is almost impossible for REC to determine which is which. The only option is to use a .cmd file and manually specify which area is code and which area is data.

In practice, only C executable files produce meaningful decompiled output.

Eventually I will implement a .PDB or Codeview symbolic information parser and a Window's resource decompiler. Until then, the only chance to get high-quality symbolic output is to decompile Linux executables that were compiled with the -g option, or to provide additional symbolic information via the 'symbol:' and 'types:' directives of a REC command file.

Several other decompilers are available from various sources. Look at my reverse engineering page for a list.

Rather surprisingly, the internal architecture of a decompiler is very similar to that of a compiler. High-quality literature exists for both.
The decompilation page has links and documentation related to decompilers in general.

Cristina Cifuentes' Reverse Compilation Techniques PhD thesis describes in details the theory and implementation of the dcc decompiler for 8086 DOS programs.

The optimization page describes some of the techniques used by compilers to optimize machine level code. Decompiling optimized is more difficult because the decompiler must "de-optimize" the input file.

The Wotsit page has links to the specifications of object file formats like COFF and ELF.

Other fundamental books I used during the development are:

• "Compilers - Principles, Techniques and Tools", Aho, Sethi, Ullman, 1986 Addison-Wesley Publishing Co.  ISBN 0-201-10088-6.
• "Advanced Compiler Design & Implementation", Steven Muchnick, 1997 Morgan Kaufmann Publishers, ISBN 1-55860-320-4.
• "How debuggers work - Algorithms, Data Structures, and Architecture", Jonathan Rosemberg, 1996 John Wiley and Sons, ISBN 0-471-14966-7.

The disassemblers used in REC were taken from various sources. The file copyrite in the distribution has a list of credits for each of the disassemblers used in REC. The rest of the code was written by myself during the last 9 years. I will continue to improve REC in my spare time, but I cannot guarantee that I can fix bugs or add new features, processors, or hosts.

There is a lot of discussion on the legality of decompilation. Decompiler tools have been available for a variety of platforms for a long time. Decompilers, along with other tools like debuggers, binary editors, disassemblers etc. should only be used when the owner of a program has the legal right to reverse engineer the program.

It has been established by the US and other countries courts that it is legal to use decompilers under the fair use clause of copyright law.

To find out when it is legal to use a decompiler, you should read the text of the following cases:

• Sega Enterprises LTD v. Accolade, Inc.
• Atari Games Corp. v. Nintendo of America, Inc.

Also read a discussion on the legality of using an emulator to run a binary program on a different host.

Backer Street Software does not support the use of reverse engineering tools for illegal purposes.

Copyright © 1997 - 2000 Backer Street Software - All rights reserved.

History:
 

19 Sep. 2000	Version 1.6: Added support for SPARC.
16 Mar. 1999	Version 1.5d: Restored detection of switch(). Added support for big-endian MIPS.
6 Mar. 1999	Version 1.5: Support for import/export info in Win95 files; replaced GNU disassemblers with freeware source; fixed many crashes
22 Nov. 1998	Version 1.4a: Fixed endless loop when decompiling Win95 files; added Windows prototype files
15 Nov. 1998	Version 1.4: Added browser capability in interactive mode, and HTML page generation
30 Jul. 1998	Version 1.3b: Maintenance: fixed crashes and various problems in 68k.
15 Feb. 1998	Version 1.3: Added Motorola 68000 and PowerPC targets.
7 Dec. 1997	Version 1.2: fixed PC's user interface. Now we can load 16 bits DOS executables. More bug fixes.
26 Oct. 1997	Version 1.1: multi-target support (386 + R3000), loading of ELF and PE files, several bugs fixed.
6 Oct. 1997	Ported to Windows in console mode (recr4kpc.zip) and to SunOS (recr4ks4.tar.gz)
20 Sep. 1997	Created to make recr4kl.zip available.