Reverse Engineering

Software Reverse Engineering is a process of

recovering the design, requirement specifications, and
functions of a product from an analysis of its code. It
builds a program database and generates information
from this. This article focuses on discussing reverse
engineering in detail.
What is Reverse Engineering?
Reverse engineering can extract design information
from source code, but the abstraction level, the
completeness of the documentation, the degree to
which tools and a human analyst work together, and
the directionality of the process are highly variable.
Objective of Reverse Engineering:
1. Reducing Costs: Reverse engineering can help
cut costs in product development by finding
replacements or cost-effective alternatives for
systems or components.
2. Analysis of Security: Reverse engineering is
used in cybersecurity to examine exploits,
vulnerabilities, and malware. This helps in
understanding of threat mechanisms and the
development of practical defenses by security
experts.
3. Integration and Customization: Through the
process of reverse engineering, developers can
incorporate or modify hardware or software
components into pre-existing systems to
improve their operation or tailor them to meet
particular needs.
4. Recovering Lost Source Code: Reverse
engineering can be used to recover the source
code of a software application that has been lost
or is inaccessible or at the very least, to produce
a higher-level representation of it.
5. Fixing bugs and maintenance: Reverse
engineering can help find and repair flaws or
provide updates for systems for which the
original source code is either unavailable or
inadequately documented.
Reverse Engineering Goals:
1. Cope with Complexity: Reverse engineering is a
common tool used to understand and control
system complexity. It gives engineers the ability
to analyze complex systems and reveal details
about their architecture, relationships and
design patterns.
2. Recover lost information: Reverse engineering
seeks to retrieve as much information as
possible in situations where source code or
documentation are lost or unavailable.
Rebuilding source code, analyzing data
structures and retrieving design details are a
few examples of this.
3. Detect side effects: Understanding a system or
component’s behavior requires analyzing its side
effects. Unintended implications, dependencies,
and interactions that might not be obvious from
the system’s documentation or original source
code can be found with the use of reverse
engineering.
4. Synthesis higher abstraction: Abstracting low-
level features in order to build higher-level
representations is a common practice in reverse
engineering. This abstraction makes
communication and analysis easier by
facilitating a greater understanding of the
system’s functionality.
 5. Facilitate Reuse: Reverse engineering can be
used to find reusable parts or modules in
systems that already exist. By understanding
the functionality and architecture of a system,
developers can extract and repurpose
components for use in other projects, improving
efficiency and decreasing development time.
Steps of Software Reverse Engineering:
1. Collection Information: This step focuses on
collecting all possible information (i.e., source
design documents, etc.) about the software.
2. Examining the Information: The information
collected in step-1 is studied so as to get
familiar with the system.
3. Extracting the Structure: This step concerns
identifying program structure in the form of a
structure chart where each node corresponds to
some routine.
4. Recording the Functionality: During this step
processing details of each module of the
structure, charts are recorded using structured
language like decision table, etc.
5. Recording Data Flow: From the information
extracted in step-3 and step-4, a set of data
flow diagrams is derived to show the flow of
data among the processes.
6. Recording Control Flow: The high-level control
structure of the software is recorded.
 7. Review Extracted Design: The design document
extracted is reviewed several times to ensure
consistency and correctness. It also ensures that
the design represents the program.
8. Generate Documentation: Finally, in this step,
the complete documentation including SRS,
design document, history, overview, etc. is
recorded for future use.

Software Configuration Management

When we develop software, the product (software) undergoes
many changes in their maintenance phase; we need to handle
these changes effectively.

The elements that comprise all information produced as a part

of the software process are collectively called a software
configuration.

As software development progresses, the number of Software

Configuration elements (SCI's) grow rapidly.

These are handled and controlled by SCM. This is where we require

software configuration management.

A configuration of the product refers not only to the product's constituent

but also to a particular version of the component.

Therefore, SCM is the discipline which

o dentify change
o Monitor and control change
o Ensure the proper implementation of change made to the item.
o Auditing and reporting on the change made.
Configuration Management (CM) is a technic of identifying, organizing,
and controlling modification to software being built by a programming
team.

The objective is to maximize productivity by minimizing mistakes

(errors).

CM is used to essential due to the inventory management, library

management, and updation management of the items essential for the
project.

SCM Process
It uses the tools which keep that the necessary change has been
implemented adequately to the appropriate component. The SCM process
defines a number of tasks:

o Identification of objects in the software configuration

o Version Control
o Change Control
o Configuration Audit
o Status Reporting
Risk Management
A software project can be concerned with a large variety of risks. In order to be adept
to systematically identify the significant risks which might affect a software project, it
is essential to classify risks into different classes. The project manager can then check
which risks from each class are relevant to the project.

There are three main classifications of risks which can affect a software project:

1. Project risks
2. Technical risks
3. Business risks

1. Project risks: Project risks concern differ forms of budgetary, schedule, personnel,
resource, and customer-related problems. A vital project risk is schedule slippage.
Since the software is intangible, it is very tough to monitor and control a software
project. It is very tough to control something which cannot be identified. For any
manufacturing program, such as the manufacturing of cars, the plan executive can
recognize the product taking shape.
2. Technical risks: Technical risks concern potential method, implementation,
interfacing, testing, and maintenance issue. It also consists of an ambiguous
specification, incomplete specification, changing specification, technical uncertainty,
and technical obsolescence. Most technical risks appear due to the development
team's insufficient knowledge about the project.

3. Business risks: This type of risks contain risks of building an excellent product that
no one need, losing budgetary or personnel commitments, etc.

Other risk categories

1. 1. Known risks: Those risks that can be uncovered after careful assessment of
the project program, the business and technical environment in which the plan
is being developed, and more reliable data sources (e.g., unrealistic delivery
date)
2. 2. Predictable risks: Those risks that are hypothesized from previous project
experience (e.g., past turnover)
3. 3. Unpredictable risks: Those risks that can and do occur, but are extremely
tough to identify in advance.

Risk Management Activities

Risk management consists of three main activities, as shown in fig: