Ghidra: Extendable ElfProgramBuilder and ghidra.app.util.bin.format.elf classes

[astrelsky]

Is your feature request related to a problem? Please describe.
Making loaders for custom elf files is a headache. So much of the elf parsing behavior isn't changeable mainly due to ElfProgramBuilder having package visibility and almost all of it's methods being private. Most of the classes within ghidra.app.util.bin.format.elf also suffer from this.

Describe the solution you'd like
Make ElfProgramBuilder visible and it's methods have protected visibility so the behavior may be changed. The ELF handling classes should be refactored to be extendible so that they may be adapted to handle special cases.

Describe alternatives you've considered
Copy/paste everything. Use reflection to set/invoke private fields/methods.

Additional context
For example I have an elf which reports its ElfDynamicTable vaddr as 0. This causes it to not be loaded so a ton of information is being discarded. I could use reflection to create and set the ElfDynamicTable in the ElfHeader in an ElfLoader implementation but then I would still need to do everything by hand since ElfProgramBuilder.loadElf has package visibility.

A perfect example would be the prior situation with the handling of android relocations (ElfDynamicType.DT_ANDROID_REL, and ElfDynamicType.DT_ANDROID_RELASZ for the dynamic relocation tables.) The changes required should have been trivial to implement without having to directly modify ElfHeader.

[clienthax]

Similar problems with custom relocation table types.

[astrelsky]

Similar problems with custom relocation table types.

You can extend the existing RelocationHandler for the processor if one exists. You'll need to add the ExtensionPointProperties annotation to the class with a priority higher than the existing handler. When overridingrelocate if you don't need to handle a specific one you can just invoke super.relocate. The problem occurs more with the ElfRelocationContext classes such as the MIPS_ElfRelocationContext which is a private static class. If the context it needed then you are sol.

[clienthax]

Similar problems with custom relocation table types.

You can extend the existing RelocationHandler for the processor if one exists. You'll need to add the ExtensionPointProperties annotation to the class with a priority higher than the existing handler. When overridingrelocate if you don't need to handle a specific one you can just invoke super.relocate. The problem occurs more with the ElfRelocationContext classes such as the MIPS_ElfRelocationContext which is a private static class. If the context it needed then you are sol.

I think the issue was that the relocation handler was never called due to the Id being different to a standard elf (PS3), and that check was hardcoded, would need to double check as that was a while ago

[astrelsky]

Similar problems with custom relocation table types.

You can extend the existing RelocationHandler for the processor if one exists. You'll need to add the ExtensionPointProperties annotation to the class with a priority higher than the existing handler. When overridingrelocate if you don't need to handle a specific one you can just invoke super.relocate. The problem occurs more with the ElfRelocationContext classes such as the MIPS_ElfRelocationContext which is a private static class. If the context it needed then you are sol.

I think the issue was that the relocation handler was never called due to the Id being different to a standard elf (PS3), and that check was hardcoded, would need to double check as that was a while ago

If the ElfDynamicType for the relocation table address is not DT_RELA, DT_REL, DT_ANDROID_REL, DT_ANDROID_RELA, DT_PLTREL or DT_JMPREL the relocation table will not be found.

Regarding the information here it most likely won't.

I have a semi working loader for the elf files for orbis os but with the amount of gross reflection and copy/paste I likely won't make it public. At the moment the only realistic option is to do it from scratch.

[astrelsky]

@ghidra1 you may see in the following files what is currently necessary to add support for customized elf files without completely reinventing the wheel. Not doing it this way open the door to more issues such as with the DWARFAnalyzer as the ElfHeader is directly created somewhere during analysis.

https://github.com/astrelsky/GhidraOrbis/tree/master/src/main/java/ghidra/app/util/bin/format/elf
https://github.com/astrelsky/GhidraOrbis/blob/master/src/main/java/orbis/elf/OrbisElfHeader.java
https://github.com/astrelsky/GhidraOrbis/blob/master/src/main/java/orbis/elf/OrbisElfProgramBuilder.java

If I need to put the ghidra copyright header in OrbisElfHeader.java and OrbisElfProgramBuilder.java due to the amount of code copied from ElfHeader and ElfProgramBuilder please let me know.