The colloquial use of "reverse engineering" and the formal one are somewhat different. Crackers speak of "reversing" a program, when they are talking about a quick, focused exploration of an executable program, not the in-depth analysis (usually starting with source code) that is traditional reverse engineering.

Here is a diagram of the most traditional form of reverse engineering, architecture abstraction. It was for a long time featured on the ReEngineering page, and comes originally from E. J. Byrne (A Conceptual Foundation for Software Re-Engineering, ICSM 1992, pp. 226-235):

byrne.gif

I have my own diagram for the position of decompilation within traditional reverse engineering:

Overview of decompilation and reverse engineering

As you can see, decopilation stops where architecture abstraction starts (with the implementation, i.e. the source code). Decompilation is certainly reverse engineering, since it is increasing the level of abstraction. It's just that it starts lower and ends lower than most reverse engineering. If a decompiler was used to recover old machine code into a new system, then decompilation would be part of this reengineering; the horseshoe would be a bit taller (at least on one side; usually compilation is not considered part of forward engineering, since it is a totally automatic step).

-- MikeVanEmmerik

Revision: r1.7 - 27 Sep 2005 - 22:20 - MikeVanEmmerik
Transform > DeCompilation > DecompilationAndReverseEngineering
Copyright © 1999-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback