leak64
PIE again, 64-bit edition.
Last updated
Was this helpful?
PIE again, 64-bit edition.
Last updated
Was this helpful?
This binary is remarkably similar to the last one, with two major differences:
We can't forget about the movaps fault; we need a way to mitigate this.
Addresses are 64-bit but are formatted very similarly.
Since this is the same binary as the last one, just compiled in 64-bit, we will skip most of the static analysis.
First, we need to find a leakable address on the stack. We'll use gdb to do this because, in 64-bit, it's often a high-valued offset.
We like the 8th value on the stack because it matches the format of the instructions nearby. If we check where it is:
This is our return pointer to main()! We can choose to leak this value and then overwrite it later. Our offset for the format string is going to be 13.
Uh, why?
In 64-bit, there are 6 registers. The first is reserved for the format string so we don't count that one. This makes our offset 8+6-1=13.
Now we have what we need. We can leak the address of main() + 18 and then overwrite the return pointer with the address of win().
We also need a way to beat the movaps instruction. Because PIE is enabled, we can't hardcode gadgets. This means we have to find what function they're in, their offset, and then use that for our gadget. In this case, we can pull any ret, I tend to use deregister_tm_clones() because I know it's not problematic. We find our ret instruction:
We can use this to build our payload:
Then, we send the payload off and get the flag! Here is the full exploit: