First Vulnerability Analysis

Just getting started, I analyzed the first vulnerability program under the guidance of the brave and wretched k _ k. Today I wrote down the process from scratch. The vulnerability program is.

Download the Exploit Code (Code generated by cracking a file) and the Vulnerable App (vulnerability program) to the local machine. The vulnerability Program is an executable program and is an installation file, after the installation is successful, it is a player program MyMP3. The Code for generating a cracked file is a Python script. To use it to generate a cracked file, first install Python. After installing Python, double-click Exploit Code, at this time, a command window will pop out to prompt you whether the cracked file is generated successfully. The generated cracked file name is exploit. m3u.

After completing the above preparations, you can start the analysis. I use windbg as a dynamic analysis tool.

1. First open the MyMP3 program, then open windbg, and then Attach the MyMP3 process. (Press F6 in windbg, which is the shortcut key for Attach progress ). At this time, the debugger and the source program only have one operation (okay, this is nonsense)

2. enter the command g in the windbg command line (that is, run the program to be debugged). In this case, drag the cracked file into the MyMp3 window and find that the debugger is triggered, this indicates that the player has triggered an exception. Check the prompt content of the debugger:

 

The last line 5D091399 ?? ???, 5d0091399 is the content in the eip (that is, the memory address of the command to be executed ). But how are all the contents in this address ?? Instead of a valid command, it indicates that the eip of the program has been maliciously modified. If you are familiar with the stack frame structure (if you are not familiar with it, there is also a reprinted article in my log. The content in it is not completely accurate, but it can still be clearly understood in function calls, how stack frames work ),

The problem is the address returned from the table. In this case, let's check the stack content (these are all made by kmeank, I learned ), the command to view the memory content is d (windbg Press F1 and enter d in the index, a series of d will appear below, I usually use dd and dc (not general, in the windbg command Window input dd esp, view the contents of the current stack top, and then dd esp-50, this time found that the stack began to appear continuous 41414141414141. continue dd esp-100, esp-200,-300,-400, continuous 41 No at dd esp-450.

At this time, kmeank said that when such data appears in the stack, it is obviously abnormal. It is very likely that the data is constructed by humans (at this time, you can open the break mentioned at the beginning of the article.

Decompress the file to generate a file. use NotePad to open it ,)

Check the first line buffer = "\ 41" * 1024, Which is why so many 41 are found in the stack just now, the Exploit Code constructs 1024 41 to fill the function's stack space (that is, Stack Overflow ).

At this time, kmeank said, although the function cannot return to its previous function, but this function itself will certainly call other functions, as long as it calls other functions, next to its stack frame is the stack of the function that it finally calls. In this case, let's take a look at what is followed by so many 41414141.

 

 

 

Pay attention to the stack growth direction from high address to low address. From the perspective of 41414141, 00000000 01b8a000001b99fe8 should be ebx esi and edi. Continue to see ffffffff 0012e3bc. (Why, because this is obviously not the return address. 0012e3bc is within the range of the stack where the function fails, and it cannot be the return address.) The next step is 0050a1d4, which is probably a return address. Verify it. At this time, I learned a command u family (learn it in windbg F1). Let's take a look at the u address, which is to disassemble the binary content in the address. For example

 

U is the downward disassembly, and ub is the upward. However, the results of the u command disassembly are not necessarily accurate, because when the address you selected is incorrect, the disassembly is incorrect. The best disassembly is done by ida.

Next, let's learn a command! Address, which is used to view memory properties. Check the Memory attribute of 0050a1d4. (At this time, your windbg may prompt that you didn't use the correct symbols. You can search for the post about setting the symbol path of windbg on the Internet to set it ).
Let's take a look at what the different values of the memory properties mean, as well as in my logs.

The fullpath in the last line is the executable file to which the command belongs. Then we use IDA to analyze the executable file.

 

Next I will use ida to look at the program disassembly (I used to commit 2 here, And I dragged the desktop shortcut to ida directly, so I was scolded ..... Find mymp3.exe in the installation directory ). After opening, the disassembly is complete. Press the "g" key and enter 0050a1d4. ida will jump to the Code pointed to 0050a1d4. Does it feel like a flow chart.

It looks good to split a large program into many small functions after ida disassembly.

To analyze the function that overflows.

The assembly code in the analysis, pay attention to the content of edi and esi (I used windbg to follow it for a long time at the beginning, you can use dc to view the ASCII code of the address. Use windbg to set a breakpoint at the entrance of the overflow function .... I did not finish the tm step for one morning, and then changed it to g. The Set breakpoint was triggered continuously. after about ten times, the overflow occurred, this overflow function may be a tool function used to read files. (Here we will learn a command, bp address, "dc edi ;. echo; g "this command is equivalent to the above operations. The command is nb. The command is productivity. If you are interested, you can search for the windbg conditional command)

If you have experience with the code, you can see what the function is. rep movsd copies strings in double words, contains the words to be copied in ecx, and esi is the source address, edi is the target address. Note lea edx, [esp + 40Ch + Str] mov edi. The destination address of edx is the address of the str variable (found to be the character string with overflow ). Overflow occurs, that is, if the copied bytes exceed the allowed upper limit, the ecx becomes faulty.

Or ecx, 0 FFFFFFFFh
Xor eax, eax
Repne scasb
Not ecx

This combination is to find the length of the string pointed to by edi, and the result is stored in ecx.
Use windbg to trace and find the call in case of overflow, the ecx value is changed to 400 h (at this time, edi points to the carefully constructed 1024-byte 41 in the vulnerability exploitation Program ),

Why h? In assembly code, the space allocated by overflow functions is H bytes.

 

Ida only learned a little bit. According to Mr. kmeank, ida is the best Disassembly tool in the universe. It seems that it is still necessary to continue, but it is indeed very nb. The call between various functions in a large program is very annoying. The disassembly of release software is not so standard yet .... Depends on a little bit