Fix shared object start address without program header

[hongyu-dev]

This PR is for issue: #6723

Symbols before fix:

Symbols after fix:

Memory map before fix:

Memory map after fix:

The code before fix didn't include the situation for shared object file without program header case and section start address got overwritten by segmentStart which start with value 0.

Current fix creates segments based on sections start address.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[fuzyll]

I am not sure what changes this needs, but I can't imagine this looks the way it's supposed to.

The Raw view shows a whole bunch of data that I assume is code:

But, the ELF view shows a bunch of bare symbols that map to 0's:

@negasora: Since you provided the original binary, are you able to give us any additional context on how you would like this to look after it's been loaded? I can't imagine we're supposed to have 0 functions and no actual code, given how the Raw view looks, but willing to change my mind if this is somehow expected.

EDIT: I think the problem is that, while we've adjusted where the segments should be loaded, we are not also adjusting where we're looking for functions in this case? Like, the offset in the file needs to be adjusted back for the amount we're 'off' due to loading at a later spot?

[hongyu-dev]

I was very surprised with this binary too. .text section type is NOBITS that's why its all 0s in those functions.

My guess is this is CTF challenge that intentionally used malformed binary the .text section was marked as NOBITS instead of PROGBITS. This caused objdump -d shows no disassembly while readelf -S reveals section structure. The actual code is embedded in the binary but hidden.

binaryninja-api/view/elf/elfview.cpp

Line 675 in 768f7c7

size_t size = m_elfSections[i].type == ELF_SHT_NOBITS ? 0 : m_elfSections[i].size;

[fuzyll]

With @negasora's help, I've tracked down where this came from, and it's an intentionally 'anonymized' binary from an Enterprise customer. Working with them to see if we can get something that will let us confirm this is fixed or to see if they would be willing to run a test build with these changes to confirm things load properly for them.

Sorry for the longer wait to get this merged, but this is on 'my' plate for the time being.

[fuzyll]

Also, I confirmed that the sample, as given to us, is also messed up under objdump.