Self-Referential GOT Overwrite (Target Depends on Corrupted Slot)
- •
What it is
- •
A GOT redirect can recurse if the destination function calls through the same corrupted slot. Whether useful work occurs depends on where that internal call appears.
- •
- •
How it works
- •
A Out-of-Bounds Array Access (Index Manipulation)-style or similar write primitive retargets a GOT entry (e.g.
puts@got) to point at awin()-style function instead of the real library function. - •
The program's own next call to that library function (e.g. its closing
puts("Goodbye!")) redirects intowin()as intended. - •
If
win()calls through the corrupted slot before doing useful work, it recursively re-enters itself first. - •
puts("Goodbye!") -> [corrupted GOT entry] -> win() | win()'s own puts("You win!") | -> [same corrupted GOT entry] -> win() (again) | ... (repeats) - •
A recursive call before the flag-read logic can prevent that logic from running at all. A later recursive call may instead repeat output after useful work.
- •
- •
When to use it
- •
Examples
- •
puts@got → win, followed bywincallingputs, redirects back intowin. Inspect all such calls before choosing a safe entry point.
- •
- •
pwntools
- •
target = win + verified_entry_offset # Verify the skipped prologue and all later calls through the same GOT slot.
- •
- •
Debugging
- •
disas win # Check every call through the corrupted GOT slot.
- •
- •
Cards
- •
Why can overwriting the "right" GOT slot with the "right" target address still fail to cleanly reach the intended payload?
- •
If the target function itself calls the same library function whose GOT entry was corrupted, its own call recurses back into itself via the same corrupted slot before reaching its real logic.
- •
- •
How is this resolved without choosing a different GOT slot or a different target function?
- •
A verified entry after the problematic call may help, but check any skipped prologue and all later calls through that slot. It is not automatically safe.
- •
- •