Binary Cracking and Byte Patching With IDA Pro

This rare dissertation is committed to demonstrating the cracking and byte patching of a binary executable using IDA Pro with the intention of subverting various security constraints, as well as generating or producing the latest modified version (patched) of that specific binary. IDA Pro is typically utilized to analyze the disassembled code of a binary so that the internal mechanism could be comprehended and identify the inherent vulnerability in the source code.

This article has the following contents:

  • Binary Sample
  • Patching Configuration in IDA Pro
  • Binary Analysis
  • Binary Cracking and Patching with IDA Pro
  • Script Patching Substitute
  • Final Note

IDA Pro appears to have managed mystical potentials in the reverse engineer's minds by having the impression that merely opening a binary with IDA will reveal all the secrets of a target file. IDA Pro is intended to assist you in consideration of the behavior of a binary by offering us disassembled code. IDA Pro is in fact not designed to modify or patch the binary code to suit your needs like other tools such as OllyDbg and CFF Explorer. It is really only a static-analysis disassembler tool. It can only facilitate your attempts to locate software vulnerabilities, bugs and loopholes that are typically used by both White Hat and Black Hat professionals. Ultimately, it is up to your skills and how you apply them as to whether IDA makes your search for vulnerabilities easier.


This tutorial requires a thorough knowledge of Assembly Programming and Hex Code manipulation because patching a binary with IDA Pro especially deals with assembly opcode instructions. Besides that, the reverse engineer is supposed to operate the IDA Pro Software IDE features perfectly. This operation lists the following tools of trades as:

  • The Target Binary (C /C++ code)
  • IDA Pro Interactive Dissembler
  • IDA-Script File (*.idc files)
  • Assembly Language skills
  • ASCII Converter
Binary Sample

This article exposes the demonstration of byte patching over a typical C++ binary that essentially requires a user password to validate his identity and let him log into the system and such confidential information is only provided to the registered person indeed. There is of course no direct method to breach into this application without being authenticated except to reverse engineer or patch the critical bytes responsible for doing the validation. The following code will make the binary executable live as binaryCrack.exe:
  1. #include <stdio.h>  
  2. #include <stdlib.h>  
  3. #include <string.h>  
  4. #include <conio.h>  
  6. #define password "ajay"  
  8. int _tmain(int argc, _TCHAR* argv[])  
  9. {  
  10.   char pwd[100];  
  11.   printf("Please enter the password::\n\n");  
  12.   scanf("%s", pwd);  
  13.   if ( strcmp(pwd, password) == 0 )  
  14.   {  
  15.       printf("Congratulation!!\n\n");  
  16.       printf("Ready to login with: %s",password);  
  17.   }  
  18.   else  
  19.   {  
  20.       printf("Wrong password");  
  21.   }  
  22.   getch();  
  23.   return 0;  
  24. }  

We can use any compiler to execute the aforementioned binary source code that makes an executable as binaryCrack.exe and when we run that file, it will prompt to enter the password. If we enter the correct password as “ajay” then it shows the congratulation message otherwise issues the Wrong Password message as in the following. 


It is probable that we might not have a real password and in such circumstance, we can't proceed without this information. So the only option left is Reverse Engineering this binary and to manipulate the sensitive bytes to suit your needs as we shall see in the next sections.

Patching Configuration in IDA Pro

The patching or editing of assembly code features are normally invisible in the IDA Pro. You can double-check it from the Edit menu that there are no Patch program options. Thus, in order to see this option, open the idagui.cfg configuration file of IDA Pro located at the Drive: \Program Files\IDA PRO Advanced Edition\cfg folder and scroll down to the DISPLAY_PATCH_SUBMENU option that is typically set to NO. So, do the following changes and save this file.


After saving this file, re-launch the IDA PRO and the moment you change the submenu option in the configuration file, you will see that the Patch program option becomes visible in the Edit menu as in the following:


Now, load the target binary in to IDA Pro, it will ask to create a new database as usual, then select the PE file option as in the following figure. An important point to remember is, don't forget to uncheck the Make imports segment option because some useful date can be lost from the database if this option is enabled as in the following:


The target file will be loaded into the IDA Pro but we could still not modify the byte sequence of the binary file even if the Patch program option is enabled in the Edit menu earlier. So here, the role of the special IDA script files came into light as they are able to modify the byte like OllyDbg as well as write the changes into the executable to make the effect permanent.

The IDC script files can be downloaded from here. When downloaded, extract the files in a separate folder on the file system of your machine. There are a couple of scripts files that are provided, but mainly two script files are significant as in the following:


After loading the target binary into the IDA Pro, open the folder where the previous IDA script files are located and execute the pe_sections.idc file to extend new functionality into IDA Pro for such binary patching and writing. You can ensure the new specifications from the Segments (shift + F7) windows that certain new segments are automatically added to.


After successful completion of such those operations, we can modify as well as write the byte sequence into the binary file.

Binary Analysis

We have only the binary executable and so it is nearly impossible to understand the logic implementation without the source code. But we can disassemble the source code of any binary by employing IDA Pro because unless we are aware of the logic flow, we do not know how to subvert any security mechanism. Hence, let's analyze the proper logic flow path of the binary file.

Since we can consider the following image, IDA Pro disassembles the binary into raw assembly instruction sets. This program first, prompts the user to enter the password by displaying a string message then compares this value to a predefined value “ajay” that might be the real password. The comparison happens via the string class strcmp method and if the value is 0 then the entered value is correct otherwise incorrect.


If the value of the eax register is 1 then the execution is shifted towards the loc_411444 block by the jnz statement, where the “wrong password” message would be echoed to the screen as in the following:


And if the value of eax is 0 then the jump won't throw the execution anywhere. The program indicates to us that we have entered the correct password as in the following:


We can easily anticipate that the Jump instruction determines either the password is correct or incorrect. If the eax register has the value 1 then execution is diverted towards the “wrong password” box flow otherwise the “congratulation” message would be displayed. We are implying from the execution flow that everything depends on the jnz instruction. So, the reverse engineer would surely be interested in this instruction because manipulation of this instruction can produce different results.

Binary Cracking and Patching

As we have concluded from the analysis, the outcome of this binary application is regulated by the jnz short 1oc_411444 statements. The 1oc_411444 instruction belongs to the unmatched password displaying block and execution is directly jumpiing to this block as you can see in the Red arrow.


However, all we need to do is to change the corresponding jnz statement related bytes. So right-click on the current location of this statement and synchronize it with Hex Editor View in order to examine this statement byte sequence as in the following:


The hex view offers a 16 bytes of sequence in one line and each two bytes represent only one assembly instruction set such that the hex value 75 35 belongs to .text: 0041140D address location where the assembly code jnz short 10c_411444 is implemented as the following.


So we need to identify the correct bytes to a specific instruction so that we can modify it to suit our needs. The following figure shows the hex code that refers to which instruction as in the following:


Finally, we have concluded that hex code 35 is the key value that is directing the execution flow of the program. However, select the address location 0041140D into text view and go to the Edit menu, choose Patch program and select Patch Bytes there. It will show up the entire 16 hex bytes sequence like in the hex view as in the following:


In order to diffuse the effect of the jnz statement where the execution is shifting towards the 1oc_411444 block, we need to change its corresponding hex value 35 to 00 that typically fills no action in the memory as in the following.


The moment you change the 1oc_411444 instruction code to 00, it will also reflect in the assembly as in the following:


You can also notice the modification in the hex view as in the following:


One of the important changes to notice is that after making the value 00, this time no jump arrow is showing that was pointing to the execution that diverts to 1oc_411444 as in earlier.


Now open the graph view and see that the “congratulation” block is merged into the main code rather than being separated as in earlier before the editing of the hex value. The Blue arrow finally goes to the end of the statement block and the “wrong password” block is isolated or disconnected from the main operation. So even if we enter the wrong password value, the correct password block would always be executed because the jnz statement code is diffused to 00 and the 1oc_411444 block is disconnected as in the following:


Ok, we have done the byte editing, it is the time save the effect permanently into memory, but IDA Pro is not capable of writeing bytes of the binary file into memory. It can instead write altered bytes into a database. So for this purpose, an IDA special script file is used here. Go to File and select Script file and choose pe_write.idc that make the perpetual effects in the memory as in the following:


The moment you run the pe_write.idc file, you will see that bytes have been written to segments successfully and finally, IDA will prompt to re-save the binary file as in the following:

Sections Written out

Save the modified binary with the same name as binaryCrack.exe as in the following:

Binary Crack

Now, load the binaryCrack.exe and it will prompt to enter the password, merely enter a value and Bingo! The congratulation message along with the original password appears. We have successfully bypassed or subverted the password mechanism by patching some related critical bytes using IDA Pro.


Patching String Bytes

As we can observe in the binaryCrack.exe, a couple of strings messages are showing. We can access all these strings into place via the String window (shift + F12) and can directly reach to its assembly code merely by clicking the string.


It is not a good programming practice to show the sensitive strings like serial keys or passwords directly. Such information should be hidden because after patching (reverse engineering) the passwords assembly code, the hacker can easily understand that the password is “ajay” since it is showing after the “congratulation” message. So we can hide or rename the showing of the password on the screen by patching its corresponding bytes.

So, double-click over the “ajay” in the String windows and IDA would let us reach its assembly code where from we can modify its visibility as.


Thereafter open the Hex view and we can observe the “ajay” byte code sequence as 61 6A 61 79 00 as in the following:


Again open the Patch Bytes from the Patch program that resides in the Edit menu and replace all these bytes with 00 as in the following:


Now once again, run the pe_write.idc to make the changes perpetual in the binary file and the binaryCrack.exe. Enter any value as the password and observe that this time the real password is not showing.


Removing Segments

A question comes into mind of why should we display the string message after the “Congratulation” message when we subverted the password mechanism. We cannot allow execution of a specific assembly code by using IDA Pro. Here, we can easily determine that the code instruction after address location 00411411 is senseless to be display as in the following:


This time we are not patching the bytes, instead we are integrating in new assembly code so that any string message won't be displayed after the “Congratulation” message. Hence, go and patch the program and choose Assemble as in the following:


Now place a nop assembly instruction (that stands for no operation) and it decides that none of the code would be executed as in the following:


After this, you can see that a nop is placed after 0041132 locations as in the following:


Now, run pe_write.idc again and see that none of the code is executing after the message as in the following:


Script Patching Substitute

It is not necessary that we can only patch bytes using an IDA Script file that exports the current IDA's database into the EXE binary executable. Rather, we can choose another approach. First make changes in the byte or hex code just by editing them and produce a new DIF file as test.dif. Now open the test.dif file and it shows the original hex code and patched code as in the following:

Later compile the following C program using any editor (I suggest usig GCC in the Linux platform) as:


  1. #include <stdio.h>  
  3. int main(int argc, char **argv) {  
  4.    char line[256];  
  5.    FILE *patch = stdin;  
  6.    FILE *input = NULL;  
  7.    unsigned int offset;  
  8.    int orig;  
  9.    int newval;  
  11.    int i;  
  13.    for (i = 1; i < argc; i += 2) {  
  14.       if (!strcmp(argv[i], "-p")) {  
  15.          if ((i + 1) < argc) {  
  16.             FILE *f = fopen(argv[i+1], "r");  
  17.             if (f) {  
  18.                patch = f;  
  19.             }  
  20.             else {  
  21.                fprintf(stderr, "Failed to open patch file %s\n", argv[i+1]);  
  22.                exit(0);  
  23.             }  
  24.          }  
  25.       }  
  26.       else if (!strcmp(argv[i], "-i")) {  
  27.          if ((i + 1) < argc) {  
  28.             fprintf(stderr, "Opening %s\n", argv[i+1]);  
  29.             input = fopen(argv[i+1], "rb+");  
  30.             if (input == NULL) {  
  31.                fprintf(stderr, "Failed to open input file %s\n", argv[i+1]);  
  32.                exit(0);  
  33.             }  
  34.          }  
  35.       }  
  36.       else {  
  37.          fprintf(stderr, "usage:\n\t%s [-i <binary>] [-p <dif file>]\n", argv[0]);  
  38.          fprintf(stderr, "\t%s [-p <dif file>]\n", argv[0]);  
  39.          fprintf(stderr, "\t%s [-i <binary>] < <dif file>\n", argv[0]);  
  40.          fprintf(stderr, "\t%s < <dif file>\n", argv[0]);  
  41.          exit(0);  
  42.       }  
  43.    }  
  45.    if (patch == stdin) {  
  46.       fprintf(stderr, "Reading patch data from stdin.\n");  
  47.    }  
  48.    fgets(line, sizeof(line), patch); /* eat dif file intro line */  
  49.    fgets(line, sizeof(line), patch); /* eat blank line */  
  51.    if (input == NULL) {  
  52.       fprintf(stderr, "Inferring input file name from patch file data.\n");  
  53.        fscanf(patch, "%256s", line);  
  54.       input = fopen(line, "rb+");  
  55.       if (input == NULL) {  
  56.          fprintf(stderr, "Failed to open input file %s\n", line);  
  57.          exit(0);  
  58.       }  
  59.    }  
  60.    else { /* don't need input file name, but need to skip it in dif file */  
  61.        fgets(line, sizeof(line), patch);  
  62.     }  
  64.    while (fscanf(patch, "%x: %x %x", &offset, &orig, &newval) == 3) {  
  65.       fseek(input, offset, SEEK_SET);  
  66.       if (fgetc(input) == orig) {  
  67.           fseek(input, offset, SEEK_SET);  
  68.           fputc(newval, input);  
  69.       }  
  70.       else {  
  71.          //original bytes don't match expected?  
  72.       }  
  73.    }  
  74.    fclose(input);  
  75.    if (patch != stdin) {  
  76.       fclose(patch);  
  77.    }  
  78. }  
After compiling this code successfully, execute the following command in a command prompt that requires the DIF file and the new patched file name as in the following:

ida_patcher.exe -i PatchedApp.exe -p binaryCrackPatched.dif

This approach also fulfills the same objective and produces a patched binary as defined earlier in the papers.

Final Note

So, we have learned one of the amazing tactics of patching the binary and producing a new executable file using IDA Pro, for which crackers used to struggle because as of the IDA limitation that it can only disassemble the binary code to analyze the vulnerabilities or bugs in the code. We can temporarily divert the instruction code by modifying the ZF register during debugging just by placing the breakpoint but can't patch or modify the bytes sequence into the memory directly to produce a new binary executable because IDA Pro makes changes in the database, not in the binary executable. This paper taught us how to see the hidden features of the Patch program in the IDA Pro IDE. We have also come across string patching and a new way to modify bytes by producing a DIF file that is later passed as an argument to a custom C patch code.

Similar Articles