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:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/ArmPlatformPkg.fdf
>
> [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
> FV = FVMAIN_SEC
>
> 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
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/BaseTools/Source/C/GenFv/GenFvInternalLib.c.
>
>
> The FV layout is completely defined in the UEFI Platform Initialization
> (PI) Specification 1.2.1 @ http://www.uefi.org/specs/
>
> 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:
> https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ArmPlatformPkg/Scripts/Ds5/firmware_volume.py
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
http://en.wikibooks.org/wiki/QEMU/Monitor#x
--
Brian
--------------------------------------------------------------------
"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!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel
