| 5 min read
Table of contents
Just by curiosity, a child today may take a device and disassemble it. Possibly wondering what elements are inside and how they come together to work. Something similar can be done by an adult in a workshop. But for example, with the intention of repairing an engine that for some unknown reason has stopped working. We can also mention the woman who, in her workplace, has the mission of deconstructing the program that others had worked on before. Just in order to renew and improve some of its performance features.
Photo by Kelly Sikkema on Unsplash.
All of them have applied what is known as reverse engineering, which is constituted as a process of deconstruction. It is a matter of reversing the steps of development, in order to analyze and obtain knowledge of anything engineered and elaborated by human beings. That thing can be a chemical substance, a machine, a software code or another type of object. This process seeks to reveal and determine its innermost details, components and their relationships. It is intended to discover how the object in question was designed and produced.
Here are some of the reasons why reverse engineering is employed:
-
Information on a product. Documentation may have been lost, is inaccessible, or simply never existed, and there is no contact with the producer.
-
Analysis of a product. Knowing how it works, what components it has, defining costs, and identifying possible copyright violations.
-
An update or correction of the product functioning.
-
Security auditing or assessment of the product.
-
Creation of duplicates of the product without a license.
-
Competition issue. Understanding what competitors do and what characterizes their products.
-
Simple curiosity and learning purposes about the structure of the product.
We can apply reverse engineering within information technology (IT), either for software or hardware. In this case we focus on software reverse engineering (SRE), which, as it is understood, applies to the analysis of software, the discovery of its general properties, and the identification of its components, functions and relationships. This is often done in the absence of its source code or relevant documentation, claiming its repair or improvement. This process emerged from software maintenance and support, largely from malware analysis.
We can separate SRE into two phases: The first one can be seen as a large-scale observation to determine the general structure, and sometimes areas of special interest, of the software under analysis. This phase implies the use of various tools and several services of the operating system. These tools and services enable the acquisition of information, tracking inputs and outputs, inspecting executables, among other things. The second phase is deeper, and more oriented to code fragments to understand them in their structure and functionality.
Tools
Photo taken from Exploratorium.
According to the above information, SRE depends considerably on the use of tools, many of which were not designed directly for this purpose.
Before continuing, it is wise at this point to make a parenthesis. And, for those of us who are not used to the subject, briefly explain the software languages on two general levels.
The lower level is generally made up of binary code (ones and zeros) or hexadecimal code. This executable representation of software, what the CPU reads, is known as machine language or also as byte code.
On the same level of languages, being a different form of representation of the same thing, are the assembly languages. These are easier for humans to understand, because they map or represent specific bit patterns, machine instructions, using useful mnemonics (short but memorable character sequences).
The upper level covers even more understandable languages, possessing keywords and constructs that developers use as building blocks in their programs. This is where, for example, COBOL, Java and C are situated.
Now, in relation to the tools, one of the main ones in SRE is the disassembler, which develops a process contrary to an assembler, and which will be different depending on the platform on which it is used. The disassembler translates machine language (input) to assembly language (output) for the entire program or parts of it.
As an expansion of the disassembler’s work, and in some reversing tasks as the only necessary tool, appears the debugger. With this, over the disassembled code, we can establish breakpoints —and check the current state of the program within them— in locations of interest, go through the code running line by line in its analysis, and even make edits at run time. That is, unlike the disassembler, the debugger does not work in static program code but allows us to observe the behavior of the program as it runs. And to a flow suitable for human perception, with pauses in execution as required.
Thus, after the action of the disassembler, it is expected to translate the assembly language into a high-level language, easier to read and understand. This would be more appropriate for subsequent modification of the program in question. However, this task is complex.
Lastly, let us address the decompiler, which is the opposite of a compiler. This tool tries to recreate the original source code, in high-level language, through the analysis of the binary code or sometimes the assembly language. Nevertheless, the information obtained is complex to understand. High-level concepts like classes, arrays, sets, and lists may not be easily recreated. And comments and variable names may have been completely lost (omitted during compilation), even the name of the high-level language used.
Still, the decompiler is valuable and useful because it reveals all the basic information about the operation of the program. The decompiler retrieves high-level language of the program from the machine code, while the disassembler stays in the assembly language instructions reconstruction.
SRE for security
SRE can be useful for modifying software structures, altering code, adding or removing commands and changing functions, thus affecting their logical flow. From the security area, the SRE provides techniques for hacking, whether it is malicious or ethical. In other words, it is useful to do damage or to generate protection and prevent it.
On the positive side, SRE has made it possible to detect flaws and vulnerabilities in, for example, encryption algorithms. Also, to analyze the behavior and properties of malware in test systems or already infected foreign systems (hence the development of antivirus software). Furthermore, it has enabled to prevent piracy of programs and the information contained in them, thus protecting digital rights.
On the negative side, through SRE criminals find vulnerabilities in systems, and well… they take advantage of them.
Ethical hacking is what we do within Fluid Attacks, with our security experts, and with the permission of the client organizations. Thus, in their applications and other systems, we discover security weaknesses and encourage their remediation. Therefore, we protect our clients from future attacks by cybercriminals. Our hackers, in their ethical stance, and making use of reverse engineering and manual penetration testing, must simulate the behavior of malicious hackers, and thus understand their intentions and plans for the attacks. All this in order to suggest the implementation of appropriate preventive measures.
Contact us, and learn more about our service!
Table of contents
Share
Recommended blog posts
You might be interested in the following related posts.
