Part I

Preface

In this lab, we only need to use IDA for reverse analysis. It requires everyone to have a certain foundation in reverse analysis. By statically analyzing and sorting out the program's execution flow, we can identify the buffer overflow issue.

Finding the Overflow Location

Load the lab file NETAPI32.DLL. We can directly jump to the position 0x7517FC68 to start the analysis by using the shortcut key "g", which is the sub_7517FC68 function. Of course, you can also use the F5 feature provided by IDA to convert the disassembled code into pseudo-code in the form of C-like language for analysis:

Untitled

However, I personally prefer to analyze the disassembled code, so the following analysis is based on the disassembly. In the IDA database file NETAPI32.idb provided to you, I have made comments on the key assembly statements to facilitate your understanding:

Untitled

At this point, let's pause for a moment and do two things. First, let's review the small knowledge points we have covered so far in our analysis. I have summarized them for you as follows. Please check them one by one:

  1. How to identify the number of local variables and parameters in the current function?
  2. How to check the size of the buffer space allocated in the current function?
  3. What result can be obtained by XORing itself?
  4. In which register is the return value of a function call usually stored?
  5. What is the comparison principle of cmp?
  6. What do jz, ja, etc. in jumps represent?
  7. What is the stack-pushing rule for function parameters?

If you can clarify all the above questions, it means that your fundamentals are still good. After all, these questions are frequently encountered in reverse analysis and must be clarified (they may also be involved in job interviews).

Next, we need to discuss that we have now analyzed the wcscpy() function at 0x7517FCA4, which will assign the content of arg_0, the first parameter of the function we are currently analyzing, to the local variable Destination. Now there is a question: the current function's buffer only allocates 0x414 bytes, but through the wcslen() function at 0x7517FC79, we know that it allows the length of arg_0 to be 0x411 bytes of wide characters. A wide character is 2 bytes, which means that the actual allowed length of arg_0 can reach 0x822 bytes, almost twice the buffer space of the current function. It seems to meet the conditions for buffer overflow exploitation. So, can we really make a move here?

To answer this question, we need to analyze whether there is a length limit on the parameter arg_0 before calling the wcscpy() function in the program. From the current function, we can see that the wcslen() function at 0x7517FC79 has already limited its length to 0x822, but this is far from enough. Therefore, we need to analyze whether there are any other limits on arg_0 before the current function is called. That is, to find out what happened before the current function was called.