search
IronForgeCyberHow-To: Radare2How-To: GDB

args

Solving another ret2win, with a twist.

file-archive
3KB
args.zip
archive
arrow-up-right-from-squareOpen

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.

hashtag
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 segments

All the security features are still disabled.

hashtag
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  _fini

If 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 of 0 if the two values are equal, 1 if the first value is greater than the second, and -1 if the first value is less than the second.

  • The next instruction is a "jump if" instruction. These are used in tandem with cmp to decide where we go. In this case, the program decides to jump if equal (je). je takes 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 to 0xdeadbeef, then we move to win+48. If we follow win+48, we see that this reaches system.

  • If DWORD PTR [rbp+0x8] is not equal, it will continue instructions. However, there is a jmp call, which is going to jump to win+68, which skips the system call.

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.

circle-exclamation

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!

Previouswin64Next0x2: shellcodes

Last updated