You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some Linux systems, users can employ prelink (https://linux.die.net/man/8/prelink) to try to speed up startup time. I haven't dug too much into prelink's code (https://github.com/jwilk-mirrors/prelink) but surely it changes relocation entries in such a way that CLE cannot handle when loading a binary. The basic idea of prelink is to assign hard coded base addresses to shared objects so the final addresses of symbols will be known and advance and statically written in the relocation segments of ELF objects that use them.
In my view, a fix for this requires 2 things:
Some logic to figure out whether a relocation entry has been tampered with by prelink or not - this is because you won't find offset values in these symbols, but actual absolute addresses; so this line (https://github.com/angr/cle/blob/master/cle/backends/elf/metaelf.py#L38) will be wrong and you need to use realaddr instead of the from-lva-to-rva calculation.
Defer the PLT loading to after all objects have been loaded - this is because prelinked symbols will have addresses outside the address space of current object, so if you try to access these addresses (e.g. via self.memory.load at the line I mentioned above) you'll crash because there's no backer satisfying the target address. In fact, you may have to use self.loader.memory.load instead. One idea for implementing this deferring is to remove the call to _load_plt() from the ELF constructor (https://github.com/angr/cle/blob/master/cle/backends/elf/elf.py#L121) and move it to loader instead, after all objects have been mapped (e.g. circa https://github.com/angr/cle/blob/master/cle/loader.py#L682).
The text was updated successfully, but these errors were encountered:
so! this is a lot. I don't think I can get to this myself, so I'm just going to slap the good old help-wanted sticker on this and see if anyone thinks they're up for it.
I don't think the PLT resolution is quite as critically broken in the presence of prelinks as you're thinking - the PLT walking code shouldn't ever try to jump out of the main binary; the last block it looks at should be the PLT stub itself, and should check for a reference to the relevant GOT slot. Prelinking does not change these properties of the PLT.
In some Linux systems, users can employ prelink (https://linux.die.net/man/8/prelink) to try to speed up startup time. I haven't dug too much into prelink's code (https://github.com/jwilk-mirrors/prelink) but surely it changes relocation entries in such a way that CLE cannot handle when loading a binary. The basic idea of prelink is to assign hard coded base addresses to shared objects so the final addresses of symbols will be known and advance and statically written in the relocation segments of ELF objects that use them.
In my view, a fix for this requires 2 things:
Some logic to figure out whether a relocation entry has been tampered with by prelink or not - this is because you won't find offset values in these symbols, but actual absolute addresses; so this line (https://github.com/angr/cle/blob/master/cle/backends/elf/metaelf.py#L38) will be wrong and you need to use realaddr instead of the from-lva-to-rva calculation.
Defer the PLT loading to after all objects have been loaded - this is because prelinked symbols will have addresses outside the address space of current object, so if you try to access these addresses (e.g. via self.memory.load at the line I mentioned above) you'll crash because there's no backer satisfying the target address. In fact, you may have to use self.loader.memory.load instead. One idea for implementing this deferring is to remove the call to _load_plt() from the ELF constructor (https://github.com/angr/cle/blob/master/cle/backends/elf/elf.py#L121) and move it to loader instead, after all objects have been mapped (e.g. circa https://github.com/angr/cle/blob/master/cle/loader.py#L682).
The text was updated successfully, but these errors were encountered: