I cannot understand the ret_address in classic overflow module

[halfluke]

Hi,

I've just started the course and I'm really grateful to have found such a step by step resource.

In the the classic buffer overflow section, I'm not sure I understand why you put:
ret_address = 0xffffd5f0 + 28 + 4
in both examples.
I calculated the correct ret_address for my machine and it works fine but I had to remove
"+ 28 + 4" : the 28 bytes junk is added later and the 4 bytes is the ret address itself

ret_address = 0xffffd5b0
shellcode = ("\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b" +
             "\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd" +
             "\x80\xe8\xdc\xff\xff\xff/bin/sh")
payload = "A"*28 + p32(ret_address)
padding_len = 100 - len(payload) - len(shellcode)
payload += "\x90" * padding_len + shellcode

Thank you

[sashs]

Hey,

where does your ret address point to?
@nnamon tooks the address of the buffer and adds the offset of 28 +4 for the return address, what is 32 or 0x20.
It seems that you did not take the address of the buffer, but the address of the payload.

|                                          |
|                                          |
|------------------------------------------| -       -  <---- This is the address in the tutorial
|                                          | |       |
|                                          | |       |
|                                          | |       |
|                                          | |       |
|                  buffer                  | |   28  |
|                                          | |       |
|                                          | |       |  
|                                          | |       |
|                                          | |       |
|------------------------------------------| -       |
|                return address            | |    4  |
|------------------------------------------| -       -  <----   I think you took this address
|                                          | 
|                                          | 
|               shellcode                  | 
|                                          | 
|                                          | 
|                                          | 
|                                          | 
|------------------------------------------| 
|                                          |

[halfluke]

I admit I'm a bit confused because in the tutorial the example before the final exploit with shellcode says:
"0xffffd5f0 is the start of buffer the user input is read into. A good place to jump to would be (0xffffd5f0 + 28 + 4). This lets us put our shellcode right after the return address. To begin with, we can test out strategy by filling that space with 'int 3' instructions (0xcc)."
The address is different in the final exploit, but it keeps the same +28 + 4 structure.
But yes, I took directly the address of the payload (starting with NOPs) for my ret_address, I find it more intuitive.

[sashs]

The stack address relies on different things like environment variables, kernel, etc. You can test it by add another environment variable and you will see that your buffer address is different. Therefore, choosing an stack-address is not the best case.
I recommend to choose an address to an instruction (jmp esp) instead of the buffer address. After the return esp points to the position where the nops are located. By putting an address to the instruction jmp esp the CPU will jmp to the nops. In order to find such an address you can use ropper.

ropper -f <the binary> --jmp esp

However, since the binary is very small you should compile it statically as described in the rop section of this tutorial.

[halfluke]

I understood the different choice of ret_address and I was able to replicate the tutorial example.
For what concerns a jmp esp, ropper cannot find any in this binary.
Did you mean that in order to find a jmp esp I need first compile the binary statically?

[sashs]

Yes, I meant that, otherwise the binary is too small.

Another possibility is to use a library that is used by the application, e.g. libc.so. But this is a little bit more work, therefore, I recommend compiling it statically.