system
) into the PLT. This then means the attacker can use the PLT function as if it was originally part of the binary, bypassing ASLR (if present) and requiring no libc leaks.libc
functions when they are first called using the PLT and GOT. During the relocation of a runtime symbol, RIP will jump to the PLT and attempt to resolve the symbol. During this process a "resolver" is called.[email protected]
. I'm using GDB with the pwndbg
plugin as it shows it a bit better.jmp
in the PLT to resolve it./bin/sh
) once resolved.JMPREL
segment (.rel.plt
) stores the Relocation Table, which maps each entry to a symbol.Elf32_Rel
:name
coresponds to our symbol name. The offset
is the GOT entry for our symbol. info
stores additional metadata.R_SYM
of gets
is 1
as 0x107 >> 8 = 1
.Elf32_Sym
struct:st_name
as this gives the offset in STRTAB of the symbol name. The other fields are not relevant to the exploit itself.STRTAB
offset of the symbol's string using the R_SYM
value we got from the JMPREL
, combined with SYMTAB
:SYMTAB + R_SYM * size (16)
, and it appears that the offset (the SYMTAB
st_name
variable) is 0x10
.STRTAB
, we get the symbol's name!reloc_offset
value and jump to the beginning of the .plt
section. A few instructions later, the dl-resolve()
function is called, with reloc_offset
being one of the arguments. It then uses this reloc_offset
to calculate the relocation and symtab entries.