Open zznop opened 3 years ago
Thanks for reporting this. Do you have an example binary which reproduces this issue?
Unfortunately, I don't have a binary that I can share at the moment. When I have the time, I'll look through online firmware samples or try to build a module from edk2 and report back.
I think the issue only effects x86 PE32's, not x86-64. A position-independent x86-64 PE32 loads fine in my testing. Unfortunately, the only firmware samples I can find online only contain 32-bit UEFI modules.
If a UEFI PE32 module is built position-independent, Ghidra loads it at 0x10000. When it searches for global assignments, it finds the
SystemTable->BootServices
, which in almost every case is somewhere before0x10000
because it's based on the PE being loaded at0
. It then tries to apply a type before the base of the PE raising an exception that resembles the following:There is a simple workaround: upon loading the PE32 click the Memory Map and rebase the binary to 0x0. However, I think you can also address this in code by detecting if the PE32 is position-independent in
UEFIHelper.java
and rebase to 0x0 automatically, or add Ghidra's0x10000
default base address to resolve the correct location of global variables.