How to Reverse Engineer?
In this article, we are going to talk about RCE, also known as reverse code engineering. Reverse code
engineering is the process where the code and function of a program is modified, or may you prefer:
reengineered without the original source code. For example, if a software programmer has created a program with a bug, does not release a fix, then an experienced end user can reverse engineer the application and fix the bug for everyone using the program. Sounds helpful doesn’t it?
That’s because we only touched the tip of the iceberg; the road of reverse engineering is a long one and the end leads to somewhere dark and illegal. Why you wonder? Because, by that logic, computer users can modify the code of any program, alter licensing features of a commercial product and remove critical features to their own liking. For example, a software such as Photoshop that requires you to buy a serial key to register and use it, can be reverse engineered to either extract a valid key or just to remove the whole serial system altogether. This is illegal and these people who reverse engineer applications illegally, known as crackers or hackers, have encountered legal issues since the first software was released. Teams also dedicate themselves to this activity, but to this present day, most have been arrested or have ‘voluntarily shutdown’.
So how exactly does one reverse engineer? What tool do you need to do so? Read on because we are getting there!
Reverse Engineering
Reverse engineering has drawn a lot of attention to itself in the past few years, especially when hacked programs are released to the general public, and spread across websites that dedicate themselves to distributing them. Though it is mainly used for sinister purposes, reverse engineering can also be used for good, such as removing bugs, fixing crashes and so on. The next paragraph will give you the brief on how programs (EXE files) are created.
The process of making a program is quite straight forward. First you need a programming language
with a compiler. Many that are available include C, C++, Python, Delphi, etc. The programmer uses
this programming language to make a source file containing all the editable code for his/her program.
When the programmer has finished coding his application and plans to distribute it, he/she will have
to compile the code to an EXE file.
The source code, the human readable and understandable file that is created by the programmer himself is firstly compiled in to an object file with readable symbols, meaning that it is still understandable by a normal human.
The compiler then transforms the object file in to an executable, the format which all of your windows programs is compiled in, rendering the binary code symbol-less, in other words: unreadable.
The source code of a simple ‘Hello World’ application
For example, if you make a simple application in C++, you need to write a source file first, something
like ‘MyApp.c’. When you are done, you want to make an executable file out of your code, so you compile it. During the compilation, the file ‘MyApp.c’ is translated into object and then binary code, making it extremely hard to humanly interpret and almost impossible to uncompile or decompile back to the original file; ‘MyApp.c.’
Programmers rely on this idea for security of their application. The harder it is to decompile their application and reverse the actions of a compiler, the more secure their code. However, when there’s a way in, you can be sure that there is one out.
Editing Code AKA Debugging
Although the compiled code is unreadable, there are, however, programs that can translate it into a semireadable state. These programs are called debuggers. Debuggers are programs that read those binary codes that the program has been compiled to and convert them into easier to understand terms. Those terms make up an extremely low level programming language known as Assembly. If you thought learning C++ was a headache then wait till you try out assembly. Though complex as it may be, assembly code is what all applications are written in when compiled. It is extremely low level meaning. It takes approximately 10 lines of assembly to compensate for one line of C++. For that reason, assembly code is not a preferred language among software developers.
Now knowing the connection between your program, assembly and the debugger, we can move on to the next topic: the debugging.
Debugging is the process of removing bugs or errors from a program
A debugger, is a program that does what its name implies, it removes bugs. To do that, it allows users to edit the assembly of a program, changing its structure and function. For example, if I had an annoying bug where a program always counts 0s as 1s, I can create a fix myself with a debugger by simply loading my program and then editing the section of assembly where the program confuses 0s with 1s. Then I can release the fix online for all the users of that program.
Assembly Code
Before you can debug anything, you need a fair bit of knowledge on assembly, not enough to code programs, but enough to understand how programs are coded in assembly. You can access this great tutorial here: http://www.cs.virginia.edu/~evans/cs216/guides/x86.html.
Tools of the Trade
OK, so you know a bit of assembly and you have a program to reverse engineer, let’s get a debugger.
Nowadays, there are a lot of debuggers available so choosing the right one can be confusing.
Below is the list of debuggers that work for any Windows application. Those include:
• OllyDbg
• SoftIce
• Microsoft Visual Studio Debugger
• AQTime
• GDB
• AQT
In addition, there are over a hundred different debuggers, all made for different platforms and languages. But since we are debugging under Windows, this is not relevant. You can, though, simply Wikipedia the word ‘Debugger’ to find a long list of debuggers.
Reverse Engineering Example
In this demonstration we will use a free and widely used debugger: OllyDbg. You can get it from their official website: http://www.ollydbg.de/.
After downloading the debugger, unzip and open it. Load your application that you want to debug by
clicking ‘Open’ on the main toolbar.
In this demonstration, we will debug a superficial program that simulates the licensing features in a real program. Let’s call it HackMe.EXE. Basically HackME.EXE asks for a serial key and name and returns the message ‘Valid Key’ if the key and name match, and ‘Invalid Key’ if they do not. Your purpose is to either find a valid serial key or a way to bypass this process and skip to the point where you can enter any key, and get a ‘Valid Key’ message.
This is a classic example of RCE and to attack such a problem is fairly easy if you have the right tools. OllyDbg is an excellent choice as it works for all Windows compiled executables, and has a lot of useful functions, such as setting breakpoints, finding string references, etc. Because of that, we will use OllyDbg as our debugger in our demonstration.
Step 1
Open the program ‘HackME.EXE’ in OllyDbg by clicking ‘Open’ and choosing the file.
Step 2
Right click on the window where you see a lot of assembly code, and then select ‘Find All Referenced Strings.”
Step 3
You should be taken to a window where all the strings in the HackMe.EXE is listed. We want to see all its trings because we know for a fact that the messages ‘Valid Key’ and ‘Invalid Key’ is embedded somewhere in the application. If we can find its location, the corresponding code that generates these messages will also be there.
Step 4
Search. Search through all the strings listed until you find the text ‘Invalid Key’. You should find it, if not, then you will have to read the section defensive mechanisms.
Step 5
Double click on the text ‘Invalid Key.’ It should take you to the disassembly where the actual text is located.
Step 6
Now here’s the tricky part. Look at the assembly above where the text is located. If you have done your homework and researched a bit on assembly you will know what to look for. If you don’t, then I will briefly fill you in. In order to determine if the key is valid or not the program needs to actually compare the key and name. This is where we, as REers, do our thing. In windows assembly, the commands JZ, JNZ stand for operators that compare values and if they are true then they will jump to a section of the code.
Because the program we are debugging is comparing your name and serial key, we needed to find the section of the assembly that shows the ‘Invalid Key’ message, as done so in steps 1 to 5. Now that we have located this section, we are going to search for the JNZ or JZ operator replace it with themselves. For example if the program uses JZ to evaluate whether the key is valid or not, we replace it with JNZ and vice versa.
With that being said, look up from the point where you found the text ‘Invalid Key’ search for the commands JZ and JNZ; you only need to find one of them as there is only one anyway.
When you find the command, double click on it on the debugger to edit and do the following:
• If the command is JZ then change it to JNZ
• If the command is JNZ change it to JZ
Now run the program again by clicking ‘Run’ on the toolbar.
Step 7
Enter any serial number and name and you should get the message ‘Valid Key.’
Defensive Mechanisms
Reverse engineering a small and unprotected application is extremely easy, but applications today are
complex and protected as software piracy is extremely popular.
Since the uprise of reverse engineering, software companies have used packers to encrypt or scramble their code, giving crackers a hard time when they attempt to debug it.
For example, a program that is encrypted and scrambled would be impossible to debug unless the hacker can retrieve the original executable. This process seems secure right? Wrong. For every executable packer out there, there is always an unpacker. A hacker can simply search up the packer and then download the unpacker from illegal software piracy websites. The scrambled executable can then be unscrambled and debugged. If you are a software developer, your best bet is to find an uncommon executable packer to secure your files.
The windows executable format is more vulnerable to debugging and modification than Mac or Linux binaries
Just packers and encrypts are not enough and all software companies know that. That’s why they employ more advanced and complex defensive techniques against cracking with some of them making you think ‘Who will go to such lengths just to protect a file?’
Advanced Defensive Mechanisms
Long Serial Key: Many companies use a serial which is several KB long of arithmetical transforms, to drive anyone trying to crack it insane. This makes a keygenerator almost impossible – Also, brute force attacks are blocked very efficiently.
Encryption is used in most commercial applications
Encrypted Data: A program using text which is encrypted until runtime has a pretty good chance of throwing amateur hackers off. Developers often use their own encryption algorithms to encrypt their strings internally. When the program is run, then string is then decrypted, confusing the hacker.
Example: Imagine a hacker tries to use the function ‘Find All Referenced Text Strings’ as mentioned in our tutorial above. If the strings for the application are encrypted internally then the hacker will only find a few lines of messed up, non-sense characters.
Traps. A method I’m not sure about, but I have heard some apps are using it to trap crackers and hackers:
Do a CRC check on your EXE. If it is modified then don’t show the typical error message, but wait a day and then notify the user using some cryptic error code. When they contact you with the error code, you know that it is due to the crack.
Frequent updates: Developers often release frequent updates that make the current version of the app stop working until the user installs the update for it. This lets the developers modify their “anti-cracking” routines frequently and renders the cracks released for the previous versions completely useless.
“Destructive” code: A bit farfetched, but sometimes developers put destructive routines in their programs in case their internal checking routines detect that the app was cracked. They delete system files on the user’s system or mess up the Windows Registry, let the program create buggy results (obviously buggy or just noticeable after careful checks) or simply pop up warnings that “a certain patch” leads to “damage to the system files” or “contains a virus.” While this might be a good way to “shock” sensible novice crackers, I truly don’t believe this is a good (or even effective) method to protect your work as it may violate the laws of certain countries and create a bad reputation for the application.
Decompilation
Besides disassembling a program, reverse engineering can be accomplished by decompilation, a process aimed to retrieve the source code of a compiled file. A decompiler is the name given to a computer program that performs, as far as possible, the reverse operation to that of a compiler. That is, it translates a file containing information at a relatively low level of abstraction (usually designed to be computer readable rather than human readable) into a form having a higher level of abstraction (usually designed to be human readable). The decompiler does not reconstruct the original source code, and its output is far less intelligible to a human than original source code. Most programs designed in high level programming languages or are based on an interpreter can be decompiled. Such languages include Delphi, Visual Basic, Java and so on.
VB Decompiler, one of the most popular decompilers out there today
To further clarify the meaning of decompilation, consider a program you wrote in Visual Basic or as many prefer, VB. You compile it and transform your source files in to a windows executable. However as VB compiles to a high level, interpreted code, as opposed to C++’s native code, it can be easily dissembled. A hacker can simply use a program such as VB Decompiler or VB Reformer and obtain almost every single source file you wrote.
Though it seems that any windows program is vulnerable to modification and tampering, as long as you compile that program with a native language such as C++ or C, your app should be relatively safe from decompilation.
Reverse Engineering Online
Today, there are teams dedicated to REing software, forums dedicated to teaching users the process and websites dedicated to spreading the reverse engineered app. A simple search on Google on something like ‘How to crack’ or ‘How to hack’ will lead you to over a million tutorials on the subject. There are teams, such as CORE which stands for “Challenge Of Reverse Engineering”, there are unnamed websites that allow hackers to upload their work, but why. Why does one reverse engineer?
The answer is simple. It is because software isn’t free. In the world of commercial software, you have
to buy a license to use it. You have to subscribe by paying a certain amount every month to use it. You have to register your software to use it.
It would be fine if software were like cars. They can’t be copied or pasted. They can’t be uploaded on
to software piracy dedicated websites. That can’t be loaded into debuggers. There is only one car for
every person.
However, that’s software’s weak point. Software can be modified, debugged, copied and distributed.
Software isn’t real, it’s virtual, and hackers recognized this as early as when the first version of Windows was released.
Reverse engineering software eliminates the requirement of users purchasing a valid license, and in return saves them time and money. Though illegal as it may be, it is human nature to find the cheapest and easiest way to obtain something they want.
Reverse Engineering in History
A famous example of reverse-engineering involves San Jose-based Phoenix Technologies Ltd., which in the mid-1980s wanted to produce a BIOS for PCs that would be compatible with the IBM PC’s proprietary BIOS. (A BIOS is a program stored in firmware that’s run when a PC starts up).
To protect against charges of having simply (and illegally) copied IBM’s BIOS, Phoenix reverse-engineered it in a way that was smart but indirect. First, a team of engineers studied the IBM BIOS – about 8KB of code – and described everything it did as completely as possible without using or referencing any actual code. Then Phoenix brought in a second team of programmers who had no prior knowledge of the IBM BIOS and had never seen its code. Working only from the first team’s functional specifications, the second team wrote a new BIOS that operated as specified.
The resulting Phoenix BIOS was different from the IBM code, but for all intents and purposes, it operated identically. Using the clean-room approach, even if some sections of code did happen to be identical, there was no copyright infringement. Phoenix began selling its BIOS to companies that then used it to create the first IBM-compatible PCs.
In this article, we are going to talk about RCE, also known as reverse code engineering. Reverse code
engineering is the process where the code and function of a program is modified, or may you prefer:
reengineered without the original source code. For example, if a software programmer has created a program with a bug, does not release a fix, then an experienced end user can reverse engineer the application and fix the bug for everyone using the program. Sounds helpful doesn’t it?
That’s because we only touched the tip of the iceberg; the road of reverse engineering is a long one and the end leads to somewhere dark and illegal. Why you wonder? Because, by that logic, computer users can modify the code of any program, alter licensing features of a commercial product and remove critical features to their own liking. For example, a software such as Photoshop that requires you to buy a serial key to register and use it, can be reverse engineered to either extract a valid key or just to remove the whole serial system altogether. This is illegal and these people who reverse engineer applications illegally, known as crackers or hackers, have encountered legal issues since the first software was released. Teams also dedicate themselves to this activity, but to this present day, most have been arrested or have ‘voluntarily shutdown’.
So how exactly does one reverse engineer? What tool do you need to do so? Read on because we are getting there!
Reverse Engineering
Reverse engineering has drawn a lot of attention to itself in the past few years, especially when hacked programs are released to the general public, and spread across websites that dedicate themselves to distributing them. Though it is mainly used for sinister purposes, reverse engineering can also be used for good, such as removing bugs, fixing crashes and so on. The next paragraph will give you the brief on how programs (EXE files) are created.
The process of making a program is quite straight forward. First you need a programming language
with a compiler. Many that are available include C, C++, Python, Delphi, etc. The programmer uses
this programming language to make a source file containing all the editable code for his/her program.
When the programmer has finished coding his application and plans to distribute it, he/she will have
to compile the code to an EXE file.
The source code, the human readable and understandable file that is created by the programmer himself is firstly compiled in to an object file with readable symbols, meaning that it is still understandable by a normal human.
The compiler then transforms the object file in to an executable, the format which all of your windows programs is compiled in, rendering the binary code symbol-less, in other words: unreadable.
The source code of a simple ‘Hello World’ application
For example, if you make a simple application in C++, you need to write a source file first, something
like ‘MyApp.c’. When you are done, you want to make an executable file out of your code, so you compile it. During the compilation, the file ‘MyApp.c’ is translated into object and then binary code, making it extremely hard to humanly interpret and almost impossible to uncompile or decompile back to the original file; ‘MyApp.c.’
Programmers rely on this idea for security of their application. The harder it is to decompile their application and reverse the actions of a compiler, the more secure their code. However, when there’s a way in, you can be sure that there is one out.
Editing Code AKA Debugging
Although the compiled code is unreadable, there are, however, programs that can translate it into a semireadable state. These programs are called debuggers. Debuggers are programs that read those binary codes that the program has been compiled to and convert them into easier to understand terms. Those terms make up an extremely low level programming language known as Assembly. If you thought learning C++ was a headache then wait till you try out assembly. Though complex as it may be, assembly code is what all applications are written in when compiled. It is extremely low level meaning. It takes approximately 10 lines of assembly to compensate for one line of C++. For that reason, assembly code is not a preferred language among software developers.
Now knowing the connection between your program, assembly and the debugger, we can move on to the next topic: the debugging.
Debugging is the process of removing bugs or errors from a program
A debugger, is a program that does what its name implies, it removes bugs. To do that, it allows users to edit the assembly of a program, changing its structure and function. For example, if I had an annoying bug where a program always counts 0s as 1s, I can create a fix myself with a debugger by simply loading my program and then editing the section of assembly where the program confuses 0s with 1s. Then I can release the fix online for all the users of that program.
Assembly Code
Before you can debug anything, you need a fair bit of knowledge on assembly, not enough to code programs, but enough to understand how programs are coded in assembly. You can access this great tutorial here: http://www.cs.virginia.edu/~evans/cs216/guides/x86.html.
Tools of the Trade
OK, so you know a bit of assembly and you have a program to reverse engineer, let’s get a debugger.
Nowadays, there are a lot of debuggers available so choosing the right one can be confusing.
Below is the list of debuggers that work for any Windows application. Those include:
• OllyDbg
• SoftIce
• Microsoft Visual Studio Debugger
• AQTime
• GDB
• AQT
In addition, there are over a hundred different debuggers, all made for different platforms and languages. But since we are debugging under Windows, this is not relevant. You can, though, simply Wikipedia the word ‘Debugger’ to find a long list of debuggers.
Reverse Engineering Example
In this demonstration we will use a free and widely used debugger: OllyDbg. You can get it from their official website: http://www.ollydbg.de/.
After downloading the debugger, unzip and open it. Load your application that you want to debug by
clicking ‘Open’ on the main toolbar.
In this demonstration, we will debug a superficial program that simulates the licensing features in a real program. Let’s call it HackMe.EXE. Basically HackME.EXE asks for a serial key and name and returns the message ‘Valid Key’ if the key and name match, and ‘Invalid Key’ if they do not. Your purpose is to either find a valid serial key or a way to bypass this process and skip to the point where you can enter any key, and get a ‘Valid Key’ message.
This is a classic example of RCE and to attack such a problem is fairly easy if you have the right tools. OllyDbg is an excellent choice as it works for all Windows compiled executables, and has a lot of useful functions, such as setting breakpoints, finding string references, etc. Because of that, we will use OllyDbg as our debugger in our demonstration.
Step 1
Open the program ‘HackME.EXE’ in OllyDbg by clicking ‘Open’ and choosing the file.
Step 2
Right click on the window where you see a lot of assembly code, and then select ‘Find All Referenced Strings.”
Step 3
You should be taken to a window where all the strings in the HackMe.EXE is listed. We want to see all its trings because we know for a fact that the messages ‘Valid Key’ and ‘Invalid Key’ is embedded somewhere in the application. If we can find its location, the corresponding code that generates these messages will also be there.
Step 4
Search. Search through all the strings listed until you find the text ‘Invalid Key’. You should find it, if not, then you will have to read the section defensive mechanisms.
Step 5
Double click on the text ‘Invalid Key.’ It should take you to the disassembly where the actual text is located.
Step 6
Now here’s the tricky part. Look at the assembly above where the text is located. If you have done your homework and researched a bit on assembly you will know what to look for. If you don’t, then I will briefly fill you in. In order to determine if the key is valid or not the program needs to actually compare the key and name. This is where we, as REers, do our thing. In windows assembly, the commands JZ, JNZ stand for operators that compare values and if they are true then they will jump to a section of the code.
Because the program we are debugging is comparing your name and serial key, we needed to find the section of the assembly that shows the ‘Invalid Key’ message, as done so in steps 1 to 5. Now that we have located this section, we are going to search for the JNZ or JZ operator replace it with themselves. For example if the program uses JZ to evaluate whether the key is valid or not, we replace it with JNZ and vice versa.
With that being said, look up from the point where you found the text ‘Invalid Key’ search for the commands JZ and JNZ; you only need to find one of them as there is only one anyway.
When you find the command, double click on it on the debugger to edit and do the following:
• If the command is JZ then change it to JNZ
• If the command is JNZ change it to JZ
Now run the program again by clicking ‘Run’ on the toolbar.
Step 7
Enter any serial number and name and you should get the message ‘Valid Key.’
Defensive Mechanisms
Reverse engineering a small and unprotected application is extremely easy, but applications today are
complex and protected as software piracy is extremely popular.
Since the uprise of reverse engineering, software companies have used packers to encrypt or scramble their code, giving crackers a hard time when they attempt to debug it.
For example, a program that is encrypted and scrambled would be impossible to debug unless the hacker can retrieve the original executable. This process seems secure right? Wrong. For every executable packer out there, there is always an unpacker. A hacker can simply search up the packer and then download the unpacker from illegal software piracy websites. The scrambled executable can then be unscrambled and debugged. If you are a software developer, your best bet is to find an uncommon executable packer to secure your files.
The windows executable format is more vulnerable to debugging and modification than Mac or Linux binaries
Just packers and encrypts are not enough and all software companies know that. That’s why they employ more advanced and complex defensive techniques against cracking with some of them making you think ‘Who will go to such lengths just to protect a file?’
Advanced Defensive Mechanisms
Long Serial Key: Many companies use a serial which is several KB long of arithmetical transforms, to drive anyone trying to crack it insane. This makes a keygenerator almost impossible – Also, brute force attacks are blocked very efficiently.
Encryption is used in most commercial applications
Encrypted Data: A program using text which is encrypted until runtime has a pretty good chance of throwing amateur hackers off. Developers often use their own encryption algorithms to encrypt their strings internally. When the program is run, then string is then decrypted, confusing the hacker.
Example: Imagine a hacker tries to use the function ‘Find All Referenced Text Strings’ as mentioned in our tutorial above. If the strings for the application are encrypted internally then the hacker will only find a few lines of messed up, non-sense characters.
Traps. A method I’m not sure about, but I have heard some apps are using it to trap crackers and hackers:
Do a CRC check on your EXE. If it is modified then don’t show the typical error message, but wait a day and then notify the user using some cryptic error code. When they contact you with the error code, you know that it is due to the crack.
Frequent updates: Developers often release frequent updates that make the current version of the app stop working until the user installs the update for it. This lets the developers modify their “anti-cracking” routines frequently and renders the cracks released for the previous versions completely useless.
“Destructive” code: A bit farfetched, but sometimes developers put destructive routines in their programs in case their internal checking routines detect that the app was cracked. They delete system files on the user’s system or mess up the Windows Registry, let the program create buggy results (obviously buggy or just noticeable after careful checks) or simply pop up warnings that “a certain patch” leads to “damage to the system files” or “contains a virus.” While this might be a good way to “shock” sensible novice crackers, I truly don’t believe this is a good (or even effective) method to protect your work as it may violate the laws of certain countries and create a bad reputation for the application.
Decompilation
Besides disassembling a program, reverse engineering can be accomplished by decompilation, a process aimed to retrieve the source code of a compiled file. A decompiler is the name given to a computer program that performs, as far as possible, the reverse operation to that of a compiler. That is, it translates a file containing information at a relatively low level of abstraction (usually designed to be computer readable rather than human readable) into a form having a higher level of abstraction (usually designed to be human readable). The decompiler does not reconstruct the original source code, and its output is far less intelligible to a human than original source code. Most programs designed in high level programming languages or are based on an interpreter can be decompiled. Such languages include Delphi, Visual Basic, Java and so on.
VB Decompiler, one of the most popular decompilers out there today
To further clarify the meaning of decompilation, consider a program you wrote in Visual Basic or as many prefer, VB. You compile it and transform your source files in to a windows executable. However as VB compiles to a high level, interpreted code, as opposed to C++’s native code, it can be easily dissembled. A hacker can simply use a program such as VB Decompiler or VB Reformer and obtain almost every single source file you wrote.
Though it seems that any windows program is vulnerable to modification and tampering, as long as you compile that program with a native language such as C++ or C, your app should be relatively safe from decompilation.
Reverse Engineering Online
Today, there are teams dedicated to REing software, forums dedicated to teaching users the process and websites dedicated to spreading the reverse engineered app. A simple search on Google on something like ‘How to crack’ or ‘How to hack’ will lead you to over a million tutorials on the subject. There are teams, such as CORE which stands for “Challenge Of Reverse Engineering”, there are unnamed websites that allow hackers to upload their work, but why. Why does one reverse engineer?
The answer is simple. It is because software isn’t free. In the world of commercial software, you have
to buy a license to use it. You have to subscribe by paying a certain amount every month to use it. You have to register your software to use it.
It would be fine if software were like cars. They can’t be copied or pasted. They can’t be uploaded on
to software piracy dedicated websites. That can’t be loaded into debuggers. There is only one car for
every person.
However, that’s software’s weak point. Software can be modified, debugged, copied and distributed.
Software isn’t real, it’s virtual, and hackers recognized this as early as when the first version of Windows was released.
Reverse engineering software eliminates the requirement of users purchasing a valid license, and in return saves them time and money. Though illegal as it may be, it is human nature to find the cheapest and easiest way to obtain something they want.
Reverse Engineering in History
A famous example of reverse-engineering involves San Jose-based Phoenix Technologies Ltd., which in the mid-1980s wanted to produce a BIOS for PCs that would be compatible with the IBM PC’s proprietary BIOS. (A BIOS is a program stored in firmware that’s run when a PC starts up).
To protect against charges of having simply (and illegally) copied IBM’s BIOS, Phoenix reverse-engineered it in a way that was smart but indirect. First, a team of engineers studied the IBM BIOS – about 8KB of code – and described everything it did as completely as possible without using or referencing any actual code. Then Phoenix brought in a second team of programmers who had no prior knowledge of the IBM BIOS and had never seen its code. Working only from the first team’s functional specifications, the second team wrote a new BIOS that operated as specified.
The resulting Phoenix BIOS was different from the IBM code, but for all intents and purposes, it operated identically. Using the clean-room approach, even if some sections of code did happen to be identical, there was no copyright infringement. Phoenix began selling its BIOS to companies that then used it to create the first IBM-compatible PCs.