Password discovery and patching by disassembling: Explained 2023

In this article we will learn about Password discovery and patching by disassembling.

What is Password discovery and patching by disassembling?

Hiding an application’s source code to hide it from malicious hands is not the ultimate way to protect it from reverse engineering. Although many lay developers consider this approach to be the best, modern reverse engineering techniques are becoming more sophisticated every day to recognize sensitive information such as library functions, local variables, stack arguments, data types, and much more. Additionally, it may be that in the future, reverse engineers may be able to generate code similar to that of high-level languages.

Therefore, this article illustrates how to subvert some verification mechanisms, such as extracting vital information stored in a binary file during source encoding, by analyzing the generated hex code of the target executable itself. However, the approach we will discuss would not be effective for the type of binaries whose source code is either obfuscated or wrapped.

This article breaks the authentication restriction of a binary file by parsing the extracted hex code of the target binary file. So a researcher must be familiar with the hex encoding analysis of an executable file and also be aware of various sophisticated tools like Dumpbin, IDA pro, PE Editor, Win-Hex etc. which will be very helpful in disassembly. Finally, an intermediate level of understanding of the semantics of the symbolic instruction language would be very beneficial in extracting important information from the target.

• Dumpbin.exe
• Show editor
• Target binary star

In this section, we will write the target binary itself, since we will only execute the target using a custom-built VC++ executable, instead of executing on licensed software, since our intention is neither to reverse engineer an attack nor to support breaking any software protection mechanism. . Therefore, the following source code will be compiled into a console-based executable that will first ask for the correct security key in the form of a password to continue into the system. The user strictly provides only three attempts to enter the correct access key, otherwise the system will exclude him.

Listing 1:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

#include <stdio.h> #include <string.h>#define SIZE 100 #define PASSWORD ********int main () {int count=0; char buff [SIZE]=” “; char passwd[ ]=PASSWORD;printf (“nWelcome to Console!!n[You may have only 3 unsuccessful login attempts!]n”); for (;;) { printf (“Attempt =%d”,count+1); printf (“nEnter the Password:”);fgets (&buff [0], SIZE,stdin); if (strcmp(&buff[0] , &passwd[0])) { printf (“Invalid Password: Try Againn”); } else { break; } if (++count>2) { printf (“nAccess Denied”); return -1; } } printf (“Congratulations!!: Valid Credentialsn”); }

However, we have hidden the correct password key in the source code to give the impression in real time that we have broken the software protection restrictions, where even the author or the audience of this article does not know the password. In fact, mentioning the source of the target binary is redundant in this scenario since we are learning one of the subversion mechanisms where we don’t have access to the source code. Even so, the source code may be useful for those viewers who are not experienced enough in developing their own application to apply the tactics described in this article.

After compiling this source code using any compiler like VC++.NET or Borland C++ etc., the final console-based executable is generated as follows, where it first requires a password to access the functions. However, I have provided the source code of this binary, but forget everything here, it is offered only for the convenience of researchers. Imagine that the user only gets the last executable, and when he tries to run this console application without having the actual access key, he would end up not being able to proceed as follows;

Figure 1: Password entry and trial in Target Binary

Suppose for whatever reason you do not own the actual source code of this application and unfortunately you have lost the access key. How would you then utilize the features of this app when critical data is at risk and your business is at a standstill without an access key? In this critical situation, a real savior can be the Dumpbin.exe utility, which is able to “decompose” a binary file into a hex code, so that key information can be obtained by analyzing the hex code in case the source code is not obfuscated. .

Analysis of binary hex code

I’m not claiming 100% efficiency or accuracy of this approach here, but let’s assume that the referenced password is stored somewhere in the program and not encrypted in some subtle way. Unfortunately, it can be found just by looking at the binary code. By checking all text strings, especially those that look like a password, we quickly find the desired password and easily “open” the application to the next level.

Also Read:Certified Ethical Hacker study resources 2023

Analyzing binary hexadecimal code by dumping its contents is an important initial step in reverse engineering, as understanding the internal contents of the target executable is advantageous in terms of gaining insight into what the program does and what other components it interacts with. There are many executable dumping tools available, such as the DUMPBIN.EXE utility, which is a great command-line tool – it can dump all kinds of valuable evidence about the binary, imports and exports, section information, code disassembly. and many more – you name it, DUMPBIN can probably do it. Overall, it allows you to explore the contents of a Microsoft PE/COFF file.

Command 1: Dumpbin.exe

C:>dumpbin.exe Microsoft (R) COFF/PE Dumper Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. usage: DUMPBIN [options] [files]

Note

In this way, we examine or attempt to extract significant information from the target binary using various basic DUMPBIN options.

Dependency on external lib
DUMPBIN comes with VC++ in Microsoft Visual Studio and combines features of Microsoft development tools including LIB, LINK and EXEHDR. Thus, DUMPBIN can analyze a suspect binary file and offer key information about the file’s format and structure, embedded symbolic information, as well as library files required by the program. To identify the dependencies of an unknown binary, query the target file with DUMPIN using the “/DEPENDENTS” option like;

dumpbin /dependents PwdAnalysis.exe

Command 2: Binary Dependents

Microsoft (R) COFF/PE Dumper Version 10.00.30319.01 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file PwdAnalysis.exe File Type: EXECUTABLE IMAGE Image has the following dependencies: MSVCR100D.dll KERNEL32.dll

Binary header information

The DUMPBIN /headers option displays only the header information pertains to COFF header files and section header files. Here’s the headers detail for the PwdAnalysis executable file as:

> dumpbin /headers PwdAnalysis.exe

Command 3: Binary headers

FILE HEADER VALUES 14C machine (x86) 7 number of sections 54BE4E57 time date stamp Tue Jan 20 18:17:19 2015 0 file pointer to symbol table 0 number of symbols E0 size of optional header 102 characteristics Executable 32 bit word machine OPTIONAL HEADER VALUES 10B magic # (PE32) 10.00 linker version 3600 size of code 3C00 size of initialized data 0 size of uninitialized data 11113 entry point (00411113) @ILT+270(_mainCRTStartup) 1000 base of code 1000 base of data 400000 image base (00400000 to 0041BFFF) 1000 section alignment 200 file alignment 5.01 operating system version 0.00 image version 5.01 subsystem version 0 Win32 version 1C000 size of image 400 size of headers 0 checksum 3 subsystem (Windows CUI) 8140 DLL characteristics Dynamic base NX compatible Terminal Server Aware …

Code segments enumeration

The DUMPBIN /summary option enumerates all the code segments information employed in the binary. However, some of them are generated by default.

> Debug>dumpbin /summary PwdAnalysis.exe

Command 4: Code segments detail

Dump of file PwdAnalysis.exe File Type: EXECUTABLE IMAGE Summary 1000 .data 1000 .idata 2000 .rdata 1000 .reloc 1000 .rsrc 4000 .text 10000 .textbss

It’s totally up to the hacker’s or researcher’s intellect which section they pick up to analyze, since these segments contains very helpful data. The PwdAnalysis.exe file contains 7 underlying code segments. Each one contains significant data and has distinguishable importance as;

Segments	Description
.text	It contains the executable instruction codes and is shared among every process running the same binary.
.bss	It holds un-initialized global and static variables. The size that BSS will require at runtime is recorded in the object file, but the BSS doesn’t take up any actual space in the object file.
.data	It usually has READ/WRITE permissions, contains the initialized global and static variables and their values.
.reloc	It keeps information required for relocating the image while loading.
rdata	It contains constants and string literals.

Disassembling binary code

The DUMPBIN /disasm command-line option produces a disassembled dump of the object file in a symbolic language syntax similar to IDA pro. The /disasm option is used to examine compiled programs and can be used when analyzing “pseudocompiled” code. If you look closely at the exploded code, you can easily find the execution flow and also identify a few stored string values ​​like;

> dumpbin /DISASM PwdAnalysis.exe

Command 5: Disassembled code of Binary

Password disclosing by examining raw data

A binary usually contains basic string reference values ​​which help a lot to figure out the execution flow and also help in cracking. Assume a reference password stored in the raw data section, so get information about the raw data section using /SECTION:.rdata along with /RAWDATA:BYTES as follows;

> dumpbin /RAWDATA:BYTES /SECTION:.rdata PwdAnalysis.exe > analysis

Figure 2: Analysis file dump in Hex Editor

Here in the aforesaid figure, we have successfully identified significant pass key information from raw data as ‘kmaraj’ in hex code form too.

Obtaining precise information

Although dumpbin.exe with the /All option produces substantial output, the problem with this approach is that the EXE file contains all routines from the standard language library that the linker has combined into the application. Therefore, this extra information makes the job tedious by creating a tremendous amount of confusion when parsing the compiler output. Fortunately, you can drop all the unnecessary information – run DUMPBIN on object (OBJ) files rather than executable files. Here is the output of DUMPBIN with the /All option when you specify *.obj as a command line parameter:

dumpbin /All PassAuth.obj > parse

The following result shows only the base string values ​​contained in the binary with their memory address.

Figure 3: Significant information in OBJ

Furthermore, we can easily detect the original access key along with other necessary information by modifying the hexadecimal values ​​of the corresponding memory segments like;

Figure 4: Password in the OBJ

Adding custom code segments
We can get in the way of the disassembler a bit by not showing the underlying string references in the raw data section, since that section is usually the main concern. Instead, you can add your own code segments and place important information there. Here we create our own .Secure code to protect password information that is displayed in raw bytes like;

Listing 2:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#include <stdio.h> #include <string.h>#define SIZE 100 #define PASSWORD ********* #pragma data_seg (“.Secure”)char passwd[ ]=PASSWORD;#pragma data_seg () #pragma comment(linker, “/SECTION:.Secure,RWS”)int main () { int count=0; char buff [SIZE]=” “; … }

But wait!!!!!! Don’t jump to conclusions so early. You can still get such information. First, make sure you list the sections in the file by viewing them via DUMPBIN. Here, as you can see in the results, another .Secure code segment is created. Maybe it contains something interesting.

Figure 6: The .Secure code segment

Now pay attention to the .Secure section. Specify this in the /Section option in DUMPBIN when displaying bytes of raw data as;

dumpbin /RAWDATA:BYTES /SECTION:.Secure PwdAnalysis.exe

Bingo!! Here is the password! And we thought we had it covered. It is certainly possible to put confidential data in the uninitialized data section (.bss), the service RTL section (.rdata), or even the code section (.text). Because usually not everyone will look there for vital information and such an allocation will not disrupt the operation of the program.

Figure 7: Password in the .Secure block

If the password could have been written in Unicode somewhere in the source code, or it was ciphered through any cryptic algorithm, the search would be somewhat more complicated, since not all such utilities support this encoding. But it’d be rather native to hope that this obstacle will stop a hacker for long. So, we have obtained the password only by means of DUMPBIN utility. On behalf of this value, you can enter into the application’s next level as following;

Figure 8: Output

D:tempPwdAnalysisDebug>PwdAnalysis.exe Welcome to Console!! [You may have only 3 unsuccessful login attempts!] Attempt=1 Enter the Password:kmaraj Congratulations!!: Valid Credentials

Patching binary

As in the previous section, we found the password by examining the raw bytes looking for stored essential string reference values ​​in the .Secure code section. But how tiring it is to enter the password every time you start the program! What if the program accepted any password, or there was no need to enter any password.

Let’s take another look at the .Secure data section where the password is stored. We just need to figure out the location of the password in memory. Its address will be stored by a pointer.

Figure 9: Getting the password offset

Here, we can easily conclude that the password is located at the 0x419000, so the pointer to it also must be equal to 0x419000. Let’s search the disassembled code at 0x419000 using text editor, you found something interesting as;

Figure 10: Reference of 0x419000 methods

Note

Next, focus to understand the goal of the 0x04110A5 function. It’s apparent that this function checks the password.

Figure 11: 0x04110A5 method

Further, the TEST EAX, EAX instruction checks if value returned by the function equals zero. If it does, the following JZ instruction jumps to line 0x041149B which led us to the “Invalid password” string as;

Figure 12: TEST instruction

We are almost there. There are two approaches to foil the password protection. Either we replace TEST EAX, EAX with XOR EAX, EAX instruction, and then EAX register will always contain zero, you will surely enter to next level in the program, no matter what password is entered. So, in the HIEW, go to 0x041147E, press F3 for edit, then hit ENTER and change the instruction TEST to XOR. After that, don’t forget to save the changes by F9 key.

Figure 13: TEST to XOR

Or, if we replace the JZ instruction with JNE, the program will reject the real password as invalid, and all incorrect passwords will be accepted as valid.

Figure 14: JZ instruction

Here again, go to 0x41149C, press F3 for edit, and then hit ENTER and change the instruction JZ to JNE. After that, don’t forget to save the changes with F9.

Figure 15: JZ to JNE

Finally, restart the program and enter anything as a password and see the result. The password protection has fallen as following;

Figure 16: Patched EXE

Conclusion

This article provided a detailed overview of binary disassembly using DUMPBIN and demonstrated its various basic switches such as /DISASM, /Summary, etc., which are very beneficial in generating crucial information. However, there is an overwhelming tactic to circumvent and decompile the native binary code, especially with IDA Pro, WinDbg, SoftICE, etc. However, this article very simply describes the process of obtaining password information if somewhere in the source string the code is in an unencrypted form.

Finally, by analyzing the code instruction with HIEW that contains the associated code with the corresponding password, we permanently removed the password protection restriction. After that, it doesn’t matter what passkey the user enters.

Sources

• Book Reference: Identifying Malicious Code through Reverse Engineering
• C-programming 
• Book chapter: Practical Reverse Engineering
• Book chapter: write_great_code_volume_2