Property handle ELFs when first region isn't executable code

[eteran]

I've noticed that on my system, some binaries have the first page be a read-only region which precedes the actual code segment. For example:

7faa21322000-7faa21344000 r--p 00000000 103:04 4719011                   /lib64/libc-2.28.so
7faa21344000-7faa2149d000 r-xp 00022000 103:04 4719011                   /lib64/libc-2.28.so
7faa2149d000-7faa214e6000 r--p 0017b000 103:04 4719011                   /lib64/libc-2.28.so
7faa214e6000-7faa214e7000 ---p 001c4000 103:04 4719011                   /lib64/libc-2.28.so
7faa214e7000-7faa214eb000 r--p 001c4000 103:04 4719011                   /lib64/libc-2.28.so
7faa214eb000-7faa214ed000 rw-p 001c8000 103:04 4719011                   /lib64/libc-2.28.so

There is some code in edb that has assumed that the first region of a module would be the executable region. I have fixed this in a few important spots, but a complete review needs to be done.

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[merces]

Hi Evan. Just out of curiosity, do you know why? These regions should be mapped from the first PT_LOAD segment in the ELF file, right?

Thanks.

[sraboy]

They are mapped from the first PT_LOAD, sorted by the p_vaddr entry, so the order in memory is up to the arch & toolchain.

[eteran]

Fortunately, edb isn't doing the actual loading. The loader is just doing what it's supposed to do, so, the ordering is definitely correct. I am guessing that it's as simple as newer linkers putting things like the ELF header and such in a non-executable segment.

So, this isn't a major issue for edb, the important things still "work", but for example, the code to calculate the entry point of libraries in the analysis plugin isn't always correct because it makes some assumptions. Not a big deal, but should be fixed.