Re: [edk2] Disassemble UEFI FV

Subject: Re: [edk2] Disassemble UEFI FV

From: "Brian J. Johnson" <>


Date: 2012-11-27 19:07:43

On 11/27/2012 10:44 AM, Andrew Fish wrote:
> The edk2 build system produces a command line tool called VolInfo that
> dumps FVs. It does not disassemble code, but it will show you the layout.
> The FD layout is defined in the platforms .FDF file. Look in the [FD.*]
> sections. So for example:
> [FD.Sec_ArmPlatform_EFI]
> BaseAddress   = 0xEC000000|gArmTokenSpaceGuid.PcdSecureFdBaseAddress  #The base address of the Secure FLASH Device.
> Size          = 0x00010000|gArmTokenSpaceGuid.PcdSecureFdSize         #The size in bytes of the Secure FLASH Device
> ErasePolarity = 1
> BlockSize     = 0x00001000
> NumBlocks     = 0x10
> 0x00000000|0x00010000
> gArmTokenSpaceGuid.PcdSecureFvBaseAddress|gArmTokenSpaceGuid.PcdSecureFvSize
> So FVMAIN_SEC is relocated to 0xEC000000. This relocation is done when
> the build calls GenFv. The FV header starts with a zero vector (16-bytes
> of zero), on ARM these values are patched with a branch to the entry
> point of the SEC Core. See UpdateArmResetVectorIfNeeded() in
> The FV layout is completely defined in the UEFI Platform Initialization
> (PI) Specification 1.2.1 @
> Disassembly is usually done via a JTAG debugger (I assume you don't have
> one) or by using a debugger. So if you have gdb you can use the VolInfo
> + info in the .FDF file to calculate the offset of the Sec PE/COFF
> image. You can then load the binary into the debugger and disassemble.
> There are two things to look out for:
> 1) A Section in a FV File contains a section header, so make sure you
> are using the start of the PE/COFF image, and not the section header in
> front of the PE/COFF image
> 2) In general all images in edk2 are linked a zero. If the build tools
> produce an ELF or Mach-O file and convert it to PE/COFF then the image
> is linked at the size of the PE/COFF header. This is due to the PE/COFF
> header getting loaded into memory when the image is loaded, but the ELF
> or Mach-O headers do not get copied into memory. So for example you
> often have to add 0x240 to the load address to get symbols to work
> correctly. Think load address + link address.
> Given the start of the FV will be a branch to the SEC PE/COFF image
> entry point you should be able verify you are doing the math correctly.
> It may be possible to write a debugger script that loads the FD into
> memory, and then you can disassemble it with the given offsets. In gdb
> you may be able to use `restore Sec_ArmPlatform_EFI.fd 0xEC000000
> 0xEC00FFFF`.  Don't forget to set the processor architecture in the
> debugger, and you may have to use 0 vs. the real address depending on
> what is legal virtual address space for an application on your build
> platform.
> For the ARM debugger there seems to be scripts to crack FVs:

Objdump can probably do it as well, if you can tell it the exact file 
offsets to use.  Qemu's monitor should be able to do it as well ("xp /i" 
instruction) if you can load your BIOS under qemu.  See



    "When nothing is sure, everything is possible."
                                            -- Margaret Drabble

Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
edk2-devel mailing list