Search code examples
compiler-constructionstatic-librariescompiler-optimizationstatic-linkingbinaries

Statically linked libraries: How to find out if code is in a contiguous area in the executable?


I read in this SO answer that

When you statically link a file into an executable, the contents of that file are included at link time. In other words, the contents of the file are physically inserted into the executable that you will run.

I was wondering if, in the general case, this code is in a contiguous area. I learned from another SO answer that this may not be always the case:

This assumption is probably true in simple cases, but in no way is guaranteed.

Say I have a stripped binary and no source code. Yet I know that the executable was build using a certain statically linked library.

  • Is it possible to find out if the code from a statically linked library is in a contiguous area in the executable? If it is impossible in the general case, are any there heuristics or indicators?
  • Why would the linker place the code of a library at different places in the executable? I guess these would be rare edge cases, right?

Solution

  • If you want to analyse the executable, you can use decompilation and code viewing tools. The people here might help you better with that: https://reverseengineering.stackexchange.com/

    As for why, it could be an optimization, mostly for executable size, to move this region around or split it up into conveniently sized holes. Another major reason would be to prevent jump to library attacks. Basically, execute protection on memory prevents an attacker writing arbitrary code to a data buffer and executing it. In response, crackers sometimes string attacks together out of library code, so the library positions are randomized. That's not what you're trying to do, right?