CSCI 5828

Introduction

Reverse engineering is the process of generating new information about software such as synthesizing abstractions and producing different views. Reverse software engineering encompasses a wide array of tasks related to understanding and modifying software systems. There are many definitions of reverse engineering with regards to software systems depending upon what aspect of software reverse engineering is being focused on, here are a few.

To begin with we will see how the courts have defined reverse engineering. The U.S. supreme court says "reverse engineering is a fair and honest means of starting with the known product and working backwards to derive the process which aided in its development or manufacture"[1]. Additionally a U.S. District court in 1989 defined it as "the process of starting with a finished product and working backwards to analyze how the product operates or how it was made".[1]

"The process of deriving abstract formal specifications from the source code of a legacy system, where these specifications can be used to forward engineer a new implementation of that system"[4] This definition focuses on the process of getting higher level information of the software system from the source code of the system.

"Reverse engineering is the process by which information is extracted from executable machine code and converted into source language code for further processing or duplication"[8]. The definition focuses on the process of recovering source code from object code.

In general, "Software reverse engineering is the process of analyzing the components and component interrelationships of a software system in order to describe that system at a level of abstraction above that of the original system"[12].

It is absolutely critical to be able to reverse engineer software systems to a certain degree to be able to maintain them, this in my opinion is the most important application of reverse engineering because without it we would not be able to reengineer legacy systems or to migrate them to advanced architectures. The other applications of reverse engineering is to repair a malfunctioning software (fix software bugs), to produce similar software to run on a different system and also to produce competing software by creating "new" software by reverse engineering software from a different company, this might not be legal in some cases. Software hackers also use reverse engineering to circumvent certain software security features, though this is not an important application of reverse engineering it makes the study of reverse software engineering important to study how susceptible a software system is to unauthorized access.

In the following sections I will focus on migration of legacy system. I will try to address why legacy systems are valuable and what are the challenges faced in migration or reengineering of legacy systems. I will also try to look at various approaches to upgrading legacy systems.

I will also dedicate a section to the legal aspects involved in software reverse engineering and the impact of copyright on the development of cutting-edge reverse engineering technology.

I will have a section which will explain the tools that are useful in reverse software engineering. I will look at commercially available tools as well as tools that have been proposed by researchers. Most of the commercially available tools available are very useful but can perform a very limited task on the other hand there are more ambitious and integrated tools that are being worked on by researchers, I will try to cover both. I will try to look at tools that help in understanding legacy code to tools like decompilers and disassemblers that will give source code from object code. I will also look at techniques that can help to discover the architectural design of the software system through reverse engineering.

I will try to cover and explain various approaches to reverse software engineering like domain analysis verses code analysis and formal approach for deriving abstract functional specifications from low-level as-built specifications.

I will then present my conclusions from the literature survey as to why this important aspect of software engineering is overlooked so often in software engineering literature.