UEFI BIOS File Device, Part One: UEFI Capsule and Intel Flash Image
The release of motherboards on Intel sixth series chipsets (P67 and its brothers) brought to the mass PC market a new BIOS version - UEFI . In this article we will talk about the device files UEFI Capsule and Intel Flash Image.
The structure of EFI Firmware Volume and patches that are useful in the household will be described in the second part.
As an example of a UEFI Capsule file, take the BIOS image for ASUS P8Z77-V version 2003.
This is a typical representative of the AMI Aptio4 UEFI family with several ASUS extensions that do not greatly affect its format. As an example, it is taken because it contains all the components of the UEFI Capsule file, which I would like to talk about today.
To work with this file in the first part of the article we will need:
Unpacking the archive, we get a file of 0x800800 bytes with the extension CAP.
This is a UEFI Capsule file, the format of which was described by AMI at one of the UEFI Plugfest conferences and looks like this:
Open the file with a hex editor and check it for compliance with this format, in our case the title looks like this:
The header size is really 0x0000001C, the total file size is really 0x00800800, the beginning of the FFS image is indeed at offset 0x800 - there is no doubt.
Immediately there is a temptation to understand thoroughly exactly how the FW Certificate and OEM Header blocks are arranged, but this is not necessary. We don’t have the ASUS private key yet, and without it it’s impossible to sign a modified file, even knowing the format of the FW Certificate block, and breaking into RSA2048 and SHA256 is a bad thing.
In fact, nobody keeps this format in secret, it is described by the WIN_CERTIFICATE structure, familiar to PE32 + experts, the description of which can be found, for example, here , but in our case it is all not important.
Not a single byte from this two-kilobyte header is included in the BIOS chip, and this header is used only to check the validity of the file before flashing with standard ASUS utilities. When flashing with a hardware programmer, as well as with low-level utilities like the Intel Flash Programming Tool or flashrom, you just need to delete this header.
Moreover, the microcontroller implementing the firmware using the UBF technology, although it checks for the presence of this header, but does not check the certificates and flushes the modified files no worse than the original ones.
Therefore, if UBF is not used for firmware, feel free to cut off the 0x800 byte of the header and save the resulting file with the ROM extension.
If there is no UEFI Capsule header in your BIOS file, then it is either quite old, for example for a P67 or Z68 board, or the manufacturer did not want to use it, despite Intel's insistent recommendations. Consider that the manufacturer has already deleted it for you and read on.
And then there may be several options.
If you have a desktop board on Intel, as in our example, the resulting file will consist of several regions: a descriptor, a GbE region with an Intel integrated network card, a ME region, and a BIOS region.
If you have a desktop board or laptop on AMD, then of all of the above, only the BIOS region remains.
If you have a laptop on Intel, then the BIOS file, which you can download from the manufacturer’s website and use for updating, most often contains an image of only the BIOS region and the EC firmware, usually stored in a separate flash chip. The file itself can be quite cleverly structured or encrypted, but it is stored in the BIOS chip in the same form as on desktop boards, so all experiments should be performed not with an update file, but with a dump of an existing BIOS, which can be removed using FPT .
')
AMD's can safely skip all the text below and read the second part of this article, and we continue to parse the resulting ROM file.
Intel talks about the structure of its BIOSes on the datasheet pages for the corresponding chipsets. For all chipsets, starting with the 6th series, this format has generally not changed, so you can safely take it from there. The file is divided into 3-5 regions:
The GbE regions (used with Intel's entry-level integrated network cards) and PDR (designed for OEM data, but I have never seen it used somewhere) are optional.
This region must be located in the first (of the two supported) flash microcircuits at zero address and is subdivided into 11 sections, the total size of which should not exceed 4 kilobytes. It is arranged like this:
The first 16 bytes are not used and are always 0xFF, followed by the signature 0x0FF0A55A, then the Descriptor Map section indicating the offset of the initial five sections and their size.
The Component section contains information about flash chips used: their number (1 or 2), density (from 512 KB to 16 MB), prohibited commands (such as chip erase, for example) and the frequencies of reading, fast reading and erasing / writing.
The Region section contains offsets and sizes of other regions.
The Master section contains settings for access to each of the three possible wizards (BIOS, ME, GbE) to five possible regions.
The PCH / PROC Straps sections contain configuration parameters for the processor and the north bridge.
The Upper Map section contains the offset and size of the VSCC table.
The VSCC table contains JEDEC identifiers and VSCC data of all flash chips supported by the Management Engine.
The OEM section can be filled by OEMs on your own, but I have not seen it once.
Let us now check the structure of the ROM file received by us for compliance with the above:
It is easy to see that the structure is quite consistent with itself, but it will not be easy to guess exactly what each byte of each section is responsible for.
Fortunately, Intel saved us from guessing by launching the FITC utility, which allows you to customize the descriptor (and not only it) and contains hints on each item that is available for editing. This utility is included in the kit for motherboard developers and is not intended for end users, but a link to it can always be found in forums dedicated to BIOS modification.
Open our ROM file in FITC 8.xx and all descriptor settings are in full view:
I highly recommend not to change anything, who do not know why he does it.
The most frequently changed settings here are the access settings to the regions (highlighted in green in the hex editor screenshot), which are of two kinds in the wild: the above-mentioned “everything is possible” and the standard Intel settings. Sometimes the openness of an entry in the IU region helps to cope with a violation of its working capacity, simply by overwriting it completely. On boards with standard settings, this is impossible without access to the ME, which is implemented differently on different boards and may require quite nontrivial manipulations (closing the legs of an audio chip during loading, for example).
The reverse side of openness - a malicious code can do anything with a descriptor and the rest of the contents of the BIOS chip. For some reason, it is not customary to talk about this, despite the fact that absolutely all ASUS motherboards on the P67 with BIOS versions 3xxx and all ASUS motherboards on the Z68 have an open descriptor. And no security, and with obscurity problems, what engineers thought - I do not know.
The second useful setting is the BIOS chip density, which has to be changed if the corrupted BIOS is restored to a board with a large chip using a workable board with a smaller chip.
Present only on motherboards with integrated Intel entry-level network cards, such as 82579.
The datasheet for this chip in section 10 contains a description of the NVM structure, which is stored in the GbE region as a whole.
The main setting that may be interesting to change is the MAC address, located at the very beginning of the region, in the first 6 bytes. If suddenly you need to change the hardware MAC of your integrated Intel card, and there is a GbE region on your board - you know what to do.
In our example, the GbE region is at offset 0x1000 from the beginning and contains the standard MAC for all NVM images released by Intel as an update - 88: 88: 88: 88: 87: 88: 88:
When flashing with standard tools, the GbE region is not updated at all, despite the presence of updated NVM in the BIOS update file, so Intel had to release a separate NVM Update utility when, as a result of an error in version 1.3, the card stopped working normally after installing Windows 8.
The region contains a bunch of other settings that you can read about in the above datasheet.
Here is the Management Engine Firmware and its settings. About ME, you can write endlessly, because there is nothing there. You can read the best description of the structure of this region and possible attack vectors on it in the report of Igor Skochinski at Breakpoint 2012 .
For those who have not left to read it - a brief squeeze:
Intel chipsets have an ARCompact microcontroller, powered by an ATX on-call line, with access to all devices, RAM, its own network stack, and running under the ThreadX RTOS. Here it provides all the advertised Intel technologies, such as Active Management, AntiTheft, Identity Protection, Rapid Start, Smart Connect, Protected Audio Video Path and so on and so forth. And with the help of the Dynamic Application Loader on it, you can even run Java applets.
Fortunately, with IU security, everything is more or less in order, and so far I have not heard about cases of successful implementation of malicious code, but the MK chipset, which executes unknown programs to no one but Intel, and has full access to RAM and networks are a cause for paranoia in people prone to it.
You can change the available ME settings using the same Intel FITC:
In our example, the ME region starts at offset 0x3000 and is 1.5 MB in size, which indicates a fee without the support of AMT .
A region consists of one or more EFI Firmware Volume, the structure of which I will write in the second part of this article.
In the same place, we will touch on the UEFI boot process and patches that are useful in some cases.
The region is intended to describe any platform-specific capabilities and should be used by OEMs as planned, but in fact I have never seen it.
I do not know in which hub should put this article. Maybe a UFO will create for us a UEFI hub?
I look forward to your comments and apologize for any errors, which I ask to report in a personal message.
Thank you for your attention and see you in the second part.
The structure of EFI Firmware Volume and patches that are useful in the household will be described in the second part.
UEFI Capsule
As an example of a UEFI Capsule file, take the BIOS image for ASUS P8Z77-V version 2003.
This is a typical representative of the AMI Aptio4 UEFI family with several ASUS extensions that do not greatly affect its format. As an example, it is taken because it contains all the components of the UEFI Capsule file, which I would like to talk about today.
To work with this file in the first part of the article we will need:
- Hex editor to your taste, I will use HxD
- Intel Flash Image Tool is the appropriate version, for 7-series chipsets it is version 8.xx
Unpacking the archive, we get a file of 0x800800 bytes with the extension CAP.
This is a UEFI Capsule file, the format of which was described by AMI at one of the UEFI Plugfest conferences and looks like this:
Open the file with a hex editor and check it for compliance with this format, in our case the title looks like this:
The header size is really 0x0000001C, the total file size is really 0x00800800, the beginning of the FFS image is indeed at offset 0x800 - there is no doubt.
Immediately there is a temptation to understand thoroughly exactly how the FW Certificate and OEM Header blocks are arranged, but this is not necessary. We don’t have the ASUS private key yet, and without it it’s impossible to sign a modified file, even knowing the format of the FW Certificate block, and breaking into RSA2048 and SHA256 is a bad thing.
In fact, nobody keeps this format in secret, it is described by the WIN_CERTIFICATE structure, familiar to PE32 + experts, the description of which can be found, for example, here , but in our case it is all not important.
Not a single byte from this two-kilobyte header is included in the BIOS chip, and this header is used only to check the validity of the file before flashing with standard ASUS utilities. When flashing with a hardware programmer, as well as with low-level utilities like the Intel Flash Programming Tool or flashrom, you just need to delete this header.
Moreover, the microcontroller implementing the firmware using the UBF technology, although it checks for the presence of this header, but does not check the certificates and flushes the modified files no worse than the original ones.
Therefore, if UBF is not used for firmware, feel free to cut off the 0x800 byte of the header and save the resulting file with the ROM extension.
If there is no UEFI Capsule header in your BIOS file, then it is either quite old, for example for a P67 or Z68 board, or the manufacturer did not want to use it, despite Intel's insistent recommendations. Consider that the manufacturer has already deleted it for you and read on.
And then there may be several options.
If you have a desktop board on Intel, as in our example, the resulting file will consist of several regions: a descriptor, a GbE region with an Intel integrated network card, a ME region, and a BIOS region.
If you have a desktop board or laptop on AMD, then of all of the above, only the BIOS region remains.
If you have a laptop on Intel, then the BIOS file, which you can download from the manufacturer’s website and use for updating, most often contains an image of only the BIOS region and the EC firmware, usually stored in a separate flash chip. The file itself can be quite cleverly structured or encrypted, but it is stored in the BIOS chip in the same form as on desktop boards, so all experiments should be performed not with an update file, but with a dump of an existing BIOS, which can be removed using FPT .
')
Intel Flash Image
AMD's can safely skip all the text below and read the second part of this article, and we continue to parse the resulting ROM file.
Intel talks about the structure of its BIOSes on the datasheet pages for the corresponding chipsets. For all chipsets, starting with the 6th series, this format has generally not changed, so you can safely take it from there. The file is divided into 3-5 regions:
The GbE regions (used with Intel's entry-level integrated network cards) and PDR (designed for OEM data, but I have never seen it used somewhere) are optional.
Descriptor
This region must be located in the first (of the two supported) flash microcircuits at zero address and is subdivided into 11 sections, the total size of which should not exceed 4 kilobytes. It is arranged like this:
The first 16 bytes are not used and are always 0xFF, followed by the signature 0x0FF0A55A, then the Descriptor Map section indicating the offset of the initial five sections and their size.
The Component section contains information about flash chips used: their number (1 or 2), density (from 512 KB to 16 MB), prohibited commands (such as chip erase, for example) and the frequencies of reading, fast reading and erasing / writing.
The Region section contains offsets and sizes of other regions.
The Master section contains settings for access to each of the three possible wizards (BIOS, ME, GbE) to five possible regions.
The PCH / PROC Straps sections contain configuration parameters for the processor and the north bridge.
The Upper Map section contains the offset and size of the VSCC table.
The VSCC table contains JEDEC identifiers and VSCC data of all flash chips supported by the Management Engine.
The OEM section can be filled by OEMs on your own, but I have not seen it once.
Let us now check the structure of the ROM file received by us for compliance with the above:
It is easy to see that the structure is quite consistent with itself, but it will not be easy to guess exactly what each byte of each section is responsible for.
Fortunately, Intel saved us from guessing by launching the FITC utility, which allows you to customize the descriptor (and not only it) and contains hints on each item that is available for editing. This utility is included in the kit for motherboard developers and is not intended for end users, but a link to it can always be found in forums dedicated to BIOS modification.
Open our ROM file in FITC 8.xx and all descriptor settings are in full view:
I highly recommend not to change anything, who do not know why he does it.
The most frequently changed settings here are the access settings to the regions (highlighted in green in the hex editor screenshot), which are of two kinds in the wild: the above-mentioned “everything is possible” and the standard Intel settings. Sometimes the openness of an entry in the IU region helps to cope with a violation of its working capacity, simply by overwriting it completely. On boards with standard settings, this is impossible without access to the ME, which is implemented differently on different boards and may require quite nontrivial manipulations (closing the legs of an audio chip during loading, for example).
The reverse side of openness - a malicious code can do anything with a descriptor and the rest of the contents of the BIOS chip. For some reason, it is not customary to talk about this, despite the fact that absolutely all ASUS motherboards on the P67 with BIOS versions 3xxx and all ASUS motherboards on the Z68 have an open descriptor. And no security, and with obscurity problems, what engineers thought - I do not know.
The second useful setting is the BIOS chip density, which has to be changed if the corrupted BIOS is restored to a board with a large chip using a workable board with a smaller chip.
Gbe
Present only on motherboards with integrated Intel entry-level network cards, such as 82579.
The datasheet for this chip in section 10 contains a description of the NVM structure, which is stored in the GbE region as a whole.
The main setting that may be interesting to change is the MAC address, located at the very beginning of the region, in the first 6 bytes. If suddenly you need to change the hardware MAC of your integrated Intel card, and there is a GbE region on your board - you know what to do.
In our example, the GbE region is at offset 0x1000 from the beginning and contains the standard MAC for all NVM images released by Intel as an update - 88: 88: 88: 88: 87: 88: 88:
When flashing with standard tools, the GbE region is not updated at all, despite the presence of updated NVM in the BIOS update file, so Intel had to release a separate NVM Update utility when, as a result of an error in version 1.3, the card stopped working normally after installing Windows 8.
The region contains a bunch of other settings that you can read about in the above datasheet.
ME
Here is the Management Engine Firmware and its settings. About ME, you can write endlessly, because there is nothing there. You can read the best description of the structure of this region and possible attack vectors on it in the report of Igor Skochinski at Breakpoint 2012 .
For those who have not left to read it - a brief squeeze:
Intel chipsets have an ARCompact microcontroller, powered by an ATX on-call line, with access to all devices, RAM, its own network stack, and running under the ThreadX RTOS. Here it provides all the advertised Intel technologies, such as Active Management, AntiTheft, Identity Protection, Rapid Start, Smart Connect, Protected Audio Video Path and so on and so forth. And with the help of the Dynamic Application Loader on it, you can even run Java applets.
Fortunately, with IU security, everything is more or less in order, and so far I have not heard about cases of successful implementation of malicious code, but the MK chipset, which executes unknown programs to no one but Intel, and has full access to RAM and networks are a cause for paranoia in people prone to it.
You can change the available ME settings using the same Intel FITC:
In our example, the ME region starts at offset 0x3000 and is 1.5 MB in size, which indicates a fee without the support of AMT .
Bios
A region consists of one or more EFI Firmware Volume, the structure of which I will write in the second part of this article.
In the same place, we will touch on the UEFI boot process and patches that are useful in some cases.
Platform Data Region
The region is intended to describe any platform-specific capabilities and should be used by OEMs as planned, but in fact I have never seen it.
Information sources
- Secure Firmware Update, UEFI Plugfest presentation by Zachary Bobroff (AMI)
- Intel 6 Series Chipset and Intel C200 Series Chipset Datasheet
- Intel 82579 Gigabit Ethernet PHY Datasheet
- Rootkit in your laptop, Breakpoint 2012 presentation by Igor Skochinsky (Hex-Rays)
PS
I do not know in which hub should put this article. Maybe a UFO will create for us a UEFI hub?
I look forward to your comments and apologize for any errors, which I ask to report in a personal message.
Thank you for your attention and see you in the second part.
Source: https://habr.com/ru/post/185704/
All Articles