Ghidra: Add support for Android's packed relocation format

[brggs]

Is your feature request related to a problem? Please describe.

Android native binaries often have their dynamic relocation sections packed in order to minimize file size. This process is handled by LLVM, as can be seen in these diffs for the packer and unpacker.

These relocations are identified by a custom ELF section header type value, which Ghidra currently ignores. As such, the relocations are not applied to these binaries when opened in Ghidra.

Examples of files before and after packing can be found here.

Describe the solution you'd like

Update the ELF parsing code to support the Android packed format. I believe this would involve making changes to the following classes:

• ElfHeader: Update parseSectionBasedRelocationTable() to recognize the custom section header type values.
• ElfRelocationTable: Add a new method createAndroidElfRelocationTable() to read and unpack the Android format relocations, and to populate the ElfRelocation entries.
• ElfRelocation: Currently this class is populated directly from the input data buffer. This is not possible when reading the Android packed format, as groups of relocations must be unpacked together. As such, it will be necessary to instantiate and populate this class using values which have already been read. A new createElfRelocation() method with parameters for offset, info and addend would be necessary.

These changes would result in a populated list of ElfRelocations, which will then be applied correctly in the usual way.

[brggs]

I've made an initial attempt at the implementation, which can be seen in this branch. However, I wanted to check my understanding and confirm I'm taking the right approach before going any further.

[astrelsky]

I've made an initial attempt at the implementation, which can be seen in this branch. However, I wanted to check my understanding and confirm I'm taking the right approach before going any further.

Just a heads up, you might want to fix that link. Clicking on it opens up a new pull request as a request to the nsa/ghidra repo from your brggs/ghidra android patch repo.

[brggs]

I've made an initial attempt at the implementation, which can be seen in this branch. However, I wanted to check my understanding and confirm I'm taking the right approach before going any further.

Just a heads up, you might want to fix that link. Clicking on it opens up a new pull request as a request to the nsa/ghidra repo from your brggs/ghidra android patch repo.

Thanks, fixed it. Didn't realise that's what the "expand=1" query string was doing!

[brggs]

Updated the links to the implementation of the packer/unpacker, as this is now in LLVM rather than in the Android repositories.

[ghidra1]

The AndroidPackedRelocationTableDataType implementation violates the DataType pattern which disallows the use of custom constructors which can prevent proper re-construction when opening an existing program file. A Dynamic datatype must be able to obtain any required data from the supplied memory buffer and optional data type instance length.

The ElfRelocationTable.getDataType.getDataType use was not designed with Dynamic datatypes in mind. Unfortunately, the StructConverter.toDataType interface does not work well for this situation. I suggest just returning a byte array for the relocation table until we can improve the datatype mechanism.

If you would like to submit a pull request I can pull in your changes and refactor the datatype mechanism. I can than wire-in the use of your AndroidPackedRelocationTableDataType, although it will need to driven by the datatype instance length and not the constructor as you have it.

[ghidra1]

Changes have been merged (NOTE: push to Github may be delayed until after the weekend)