Navigate Site: | Home | Blog | Forum | Samples | Downloads | About Us | Links | Documentation
About Decompiler Tech
The genesis of the technology here at DeTech was when the founder, Jeremy Smith, reverse-engineered Commodore 64 games in the early 90's.
The first 'decompiler' was when he looked at Infocom Z-machine assembly code in 1998 and realised you could show it more neatly than assembler code.
He chose to decompile VB6 in 2003 and had many clients up to about 2005.
But the technology is worth more than just VB6 usage, so in August 2015, Jeremy resurrected it, building up the Lisp code from the ground up, and eventually backporting VB6 so it can decompile that - again - with all these new features.
The new features range from using 'goto's in cases where there is no alternative, some improvements in the variable types, making sure bad things don't happen with flow control, and so on.
To summarise: The purpose of the decompiler is to automate 99.5% of all the work, and leave the remaining 1/2 percent to a human. This not only saves people time, it also makes reverse engineering big programs much easier.
A compiler is a program that takes a text file and converts it into (usually) some kind of executable file. In the Windows world this is normally a .EXE or .DLL file.
A decompiler does the reverse, taking an executable program (.exe or .dll) and producing a text file (.c, .bas, etc).
There are a number of ways a decompiler can be useful. Probably the most common case is the company (or even an individual) that has an executable program, but over the years has lost the original source code. And if they then need to modify the program, they can’t. But a decompiler can produce source code for them that they can then use to upgrade their program, either with a complete re-compile, or just help finding what needs changing to do what they desire.
Various programming enthusiasts have also shown interest in decompiling in general. They seem intrigued by what’s involved in “turning a sow’s ear into a silk purse”. See here
The suite consists of 2 programs:
This software tool takes in a binary, be it 6502 or x86 or Visual Basic, scans the binary, and outputs all functions it can find as (textual) assembly code files.
The reason RevDasm outputs text, is because the decompiler takes text as its input. There are no binary inputs. If you want to decompile a program, and it's encrypted or protected, it's up to you to decrypt it before the assembly code goes into RevEngE.
6502 code is very easy to follow as there are only a few instructions.
x86 code is non-trivial to follow because the instructions vary in length enormously. The code to find the length of a line of x86 code is 80 lines of Lisp (OpLen.lisp).