Possibly incorrect return address calculation

[dipanjan]

In this writeup,

def get_retn_addr():
    p = getp()
    payload = ''
    payload += 'AAAA%96$x'
    cipher = encode(megan35, payload)
    p.sendline(cipher)
    ret = p.recvall()
    ret = ret.replace('AAAA','')
    return u32(ret.decode('hex')[::-1])+0xc

Did you want to calculate the stack address holding the return address from main method? If so, it seems not to be stored as the 96-th argument of the printf call.

[aagallag]

Hi,

Thanks for taking the time to read my writeup. This actually isn't the return from main, but rather, the return from the function at 0x0804866B. And the 96th argument actually isn't the return address, it's just an arbitrary stack address that I used to calculate the offset from the desired return address (which is why I decode it as an integer and add 0xc to it). I'm not actually sure what the 96th argument is pointing to, I just looked for an address close to where the return address was stored.

Did I understand your question correctly?

If you are attempting to reproduce this exploit locally, ensure you are using the same version of libc as provided with the challenge, ASLR is disabled on your machine, and these values will need to be updated as I hardcoded them:

if not REMOTE:
    fmt += '%28667x%71$hn'
    fmt += '%6453x%72$hn'
    fmt += '%28325x%73$hn'
    fmt += '%18x%74$hn'

[dipanjan]

Hi,

Yes, you understood me correctly. If you are overwriting the return address of function 0x0804866B (decode), I don't see how's the exploit is even triggered. printf executes after the control already returns from decode. How will overwriting the return address of function 0x0804866B even impact the flow afterwards?

[aagallag]

Oh my mistake, yes, that actually is the address pointing to the return from main (or as I mentioned earlier, an address offset by 0xc).