Burnout Beta v0.40 PAL ELF Analysis Issues with SP12 Release about ghidra-emotionengine-reloaded

[chaoticgd]

It looks like it's trying to apply relocations to a linked ELF file for some reason.

[abelbriggs1]

Might be a regression due to #50, looking now

[abelbriggs1]

So this seems to be a strange case - this is an executable ELF which is fully linked, but also includes a full relocation table. Since it's fully linked, it already has its relocations applied.

When many MIPS relocations are calculated, the target field of the instruction to be modified is often used as an offset or "addend" which is added to the relocation value. But since the relocation has already been applied in our case, the addend is the relocation itself! For an explicit example, applying a R_MIPS_26 relocation to an already relocated jal instruction will effectively double the target address value. That effect is causing the Ghidra analyzer to completely explode, because it's forced to create functions that don't exist.

Now, why is this only happening after #50? I believe it's because we weren't handling addends correctly according to the MIPS ABI. So applying the relocation to the relocated target would produce the same value.

Thankfully, in your case, I think you can just tell Ghidra to not perform symbol relocation/patching:

I tested this with your binary and it seems to analyze perfectly. Can you try this out?

[escape209]

Yes, it works as expected with Perform Symbol Relocations unchecked.