args
Solving another ret2win, with a twist.
Now that we've spent some time going over binaries in extreme detail, I am going to omit some of the initial details of the disassembly and focus more on the newer concepts. This binary is strikingly similar to the ret2win.
Checking Security
$ checksec args
[*] '/home/joybuzzer/Documents/vunrotc/public/01-ret2win/args/src/args'
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX disabled
PIE: No PIE (0x8048000)
RWX: Has RWX segmentsAll the security features are still disabled.
Disassembly
Checking the functions list:
gef➤ info functions
All defined functions:
Non-debugging symbols:
0x08049000 _init
0x08049040 __libc_start_main@plt
0x08049050 fflush@plt
0x08049060 gets@plt
0x08049070 puts@plt
0x08049080 system@plt
0x08049090 _start
0x080490d0 _dl_relocate_static_pie
0x080490e0 __x86.get_pc_thunk.bx
0x080490f0 deregister_tm_clones
0x08049130 register_tm_clones
0x08049170 __do_global_dtors_aux
0x080491a0 frame_dummy
0x080491a6 win
0x080491ef read_in
0x0804923c main
0x08049254 __x86.get_pc_thunk.ax
0x08049258 _finiIf we check read_in() and main(), we'll see that the two methods are identical. Let's check win().
The most glaring part of this function is the call to cmp, a comparison function. cmp is used in assembly to manage if statements.
The first instruction is
cmp, which takes in the two values to compare. This returns a value of0if the two values are equal,1if the first value is greater than the second, and-1if the first value is less than the second.The next instruction is a "jump if" instruction. These are used in tandem with
cmpto decide where we go. In this case, the program decides to jump if equal (je).jetakes an address: where in the function you want to jump to.
Let's check out the two routes:
If the first value (
DWORD PTR [rbp+0x8]) is equal to0xdeadbeef, then we move towin+48. If we followwin+48, we see that this reachessystem.If
DWORD PTR [rbp+0x8]is not equal, it will continue instructions. However, there is ajmpcall, which is going to jump towin+68, which skips thesystemcall.
What is DWORD PTR [rbp+0x8]? Let's think about it in terms of the stack. The stack frame is going to be located at rbp. After rbp is going to be the return pointer, as we saw in our stack frame from earlier:
That means that at rbp+0x8 holds the last thing pushed to the stack before the win() function was called. This is the (first) parameter that's passed to the function. Subsequent items on the stack would serve as the following parameters.
This tells us that we need to pass the parameter 0xdeadbeef to the win() function. Since this is 32-bit, let's just pass it right after the return pointer!
We pass cmp through p32() for two reasons: (1) we need it to be little-endian, and (2) we need it to be the entire parameter size.
Running this yields doesn't work!
What went wrong? If we do some digging, we'll find that You lose! gets printed whenever we don't match the correct argument:
(If you're struggling to find this for yourself, attach a gdb instance to your exploit and then step through it until you reach the puts call.)
What is happening? Checking the stack frame at the time of the cmp call shows us:
We're off by one chunk? Why is that? Since we're jumping to win() by changing the value of the return pointer, rather than going there via call win, a return pointer is never pushed on the stack. However, since the code doesn't expect us to do this, it treats the stack as if there still is one.
In our code, 0xdeadbeef is actually serving as the return pointer for win(). If you continue execution, you'll notice you end up at this address:
This is an easy fix. All we need to do is allocate space for a return pointer in our payload. Since it doesn't matter to us what it is, because we'll have already gotten our data by the time it's ever reached, we can just use 0x0:
(You could use something like main ensuring that the program doesn't crash, but it's unnecessary.)
Running this works!
Running this on the remote server will get your flag!
Last updated
Was this helpful?