What are the Stages of Reverse Engineering?
In this Blog article, Reverse Engineering Service experts Mako GmbH provides an in-depth analysis of the various stages of Reverse Engineering for computer hardware and software.
First you need to understand what Reverse Engineering (RE) is. RE is taking apart an object to see how it works in order to duplicate or enhance the object. The practice, taken from older industries, is now frequently used on computer hardware and software. You can reverse engineer by constructing models that describe the existing software and the presumed intent. This process of reverse engineering has three main stages as described below:
In implementation recovery, you prepare an initial model that forms the basis for reverse engineering. Because the initial model will serve as a reference, it should purely reflect the implementation and have no inferences.
The first task is to browse existing documentation and learn about an application. The resulting context clarifies the developer’s intent and makes it easier to communicate with application experts. You should finish this task in a few hours. What you learn is incidental to the actual reverse engineering, but it is important because it helps you notice more as you proceed.
The next step is to enter the database structure into a modeling tool by typing or automation. Few tools can read the system tables of an RDBMS and seed a model. If you use these tools, you should at least skim the database structure to get a feel for the development style.
During design recovery, you undo the mechanics of the database and perform only straightforward tasks. You should postpone conjecture and interpretation until the analysis-recovery stage. Typically, you can perform design recovery autonomously, without help from application experts. Three main issues are generally resolved at this stage.
Identity: Most often, unique indexes will be defined for the candidate keys of the entity types. Otherwise, look for unique combinations of data; such data can suggest, but do not prove, a candidate key. You can also infer candidate keys by considering names and conventions of style. A suspected foreign key may imply a corresponding candidate key.
Foreign keys: Foreign key (references from one table to another) determination is usually the most tough aspect of design recovery. Matching names and data types can suggest foreign keys. Some DBMSs, such as RDBMSs, let developers declare foreign keys and their referent, but most legacy applications do not use this capability.
Queries: When queries are available, you can use them to refine your understanding of identity and foreign keys.
The final product of design recovery still reflects the DBMS paradigm and may include optimizations and errors. In practice, the model will seldom be complete. Portions of the structure may be confusing.
The final phase is analysis recovery interpret the model, refine it, and make it more abstract. It is primarily during this phase that you should consult with available application experts. Four main tasks are involved in Analysis recovery.
Clarification: Remove any remaining artifacts of design. For example, an analysis model need not include file and database access keys; they are merely design decisions and contain no essential information.
Redundancy: Normally remove derived data that optimize the database design or that were included for misguided reasons. You may need to examine data before determining that a data structure is a duplicate.
Errors: Eliminate any remaining database errors. I include this step during analysis recovery because you must thoroughly understand the database before concluding that the developer erred. In the earlier stages, an apparent error could instead have been a reasonable practice or the result of incompletely understanding the database.
Model integration: Multiple information sources can lead to multiple models. For example, it is common to have a reverse-engineered model from study of the structure and data. A forward-engineered model might be prepared from a user manual. The final analysis model must fuse any separate models.