Software patching is a mechanism to modify its binary code by identifying the buggy segments through disassembling the code. Let’s ponder over the following executable execution in which simply some string is being asked to enter by the user that later echo-backed on the screen. There is nothing rocket science is being observed in prima fascia until now!!!! Just a very straightforward code execution.
However, there is a hack emerging, as a smart hacker could easily sense something vulnerable or penetration might be possible in this program, in the case of the developer would not have been validated the user input. Suppose the user enter exceeding character intentionally to observe or modify the default behavior of the program. Let’s do some overdoing now by entering some raw value as following. Although, the program displayed back the entered string but something strange happening. The program issued a buffer overflow error alert and terminated eventually (The depicting of buffer overflow error is beyond the scope of this article and reader is supposed to have a comprehensive understanding before going through this paper). This is the proof of abnormal program behavior which is not supposed to ensue.
It has been identified so far that the above executable has buffer overflow vulnerability. Since, we do not have the source code of this binary, only executable instead. Otherwise, we can fix the bug in seconds. Anyway, there are well-known reverse engineering tools procured to disassemble the binary code of an executable to analysis the code. In this paper, IDA Pro and Ollydbg employed to accomplish the stipulated task. Hence, open the vulnerable executable in the IDA Pro disassembler, and we shall come across the binary opcode of this exe file. Here, you got the reason behind emerging this bug the assembly codes that, the scanf function does not check the size of string (%s) as following
We have identified the responsible segment to be fixed, as you know the functions in C programming like scanf can check the size of strings. Just we need to put an integer in front of the format character (e.g., %10s) but the question what integer value we have to put to fix this error as it also has to be acknowledged with a defined size of array in the program where the entered value will be stored. No problem, open this vulnerable executable in Ollydbg tool, we can easily found the size array (which is 16). Moreover, ollydbg is displaying the offset instruction where %s is located as following;
So, %15s fix instead of %s is the solution to this error to be occurring. To do so, go to highlighted line and press CTRL+G to directly reach at the offset 0040401B as following:
After reaching to that offset, here, we will have to modify the instruction AND EAX 590A0073 where hex code 25 73 is designated to %s as following;
For better understanding, open the respective hex code of the selected line at 0040401B offset in hex editor which need to be altered as following:
To, patch the concern hex values in the binary code, press space button at offset 0040401B and put the hex code for %15s as;
Before putting opcode for %15s in the binary, it needs to be converted first into hex value opcode form. To streamline such conversion, use the Binary converter as following;
So, we have to write 31:35:73 (%15s) instead of 590A073 but in inverse form as 7333531 because hex code always executes Last in First Out.
Finally, right click at the offset 0040401B and perform “copy to executable” operation from the Edit menu to permanently save the changes as:
After that, a new window will be opened, while closing it, it will ask a question for saving or not. After saving it with a new name open the new version with ollydbg again because the job is still pending to be done. Further, notice that we have successfully patched %15s as in the following image. A successful patching is considered when the program not only fixed a bug but also produce the desired result as stipulated by the developer. Here, however, the program is fixed to buffer overflow bug, but it is not behaving in desired manner (not displaying the entered string). The new byte we have added, in fact, encroached some existing bytes that result in derailed the normal flow of execution. Go deep to offset 0040401E by CTRL+G which will be executed next as:
Here, we can conclude that JNB SHORT 00404020 instruction jumping is wrong. Instead, it ought to at printf method which will be designated to display the entered string. However, the printf method is located at 0040402D offset as following:
OK, press space button at 0040401E again and put the following modified opcode as following;
Again, right click at the offset 0040401E and perform “copy to executable” operation from the Edit menu to permanently save the changes to a new name. Now, open the patched executable and entered any raw value beyond the limit 16 and observe the result as following:
Even if, entering around 60 characters, there is no buffer overflow error emerged at this time as well as program is not terminated and produce the desired result. Congratulation! You have successfully patched the executable even without its source code. Bug resided in a software exploited by hackers for various reasons fulfillments. It does not matter to either vulnerabilities left in a software intentionally or unintentionally. In this article, we have learned, how to fix any buggy software using sophisticated reverse engineering tactics without even having their source code and protect our system from hacker to penetrate.
