Developers Club geek daily blog

3 years, 11 months ago
Release of motherboards on chipsets of Intel of a sixth series (P67 and his brothers) bringing a new variant of BIOS — UEFI on the mass market of the PC. In this article we will talk about the device of files of UEFI Capsule and Intel Flash Image.
The structure of EFI Firmware Volume and the patches useful in an economy will be describ in a second part.

UEFI Capsule


As an example of a file of UEFI Capsule we will take an image of BIOS for ASUS P8Z77-V of version 2003.
It are the typical representative of family of AMI Aptio4 UEFI with the several extensions of ASUS which are not strongly influenc it a format. As an example it are t because at it there was all components of a file of UEFI Capsule about whom I would like to tell today.

With this file in the first part of article it will be necessary for operation for us:
  • The Hex-editor on your taste, I will use HxD
  • The utility of Intel Flash Image Tool of the suitable version, for chipsets of 7 series — are the version 8.xx

Ha unpack archive, we received a file in the size 0х800800 byte with the extension of CAP.
It are a file of UEFI Capsule which format were describ by AMI on UEFI Plugfest one of conferences and looked so:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
We opened a file the hex-editor and we checked it on correspondence to this format, in our case the title looked so:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
The size of title really 0x0000001C, the common file size really 0x00800800, the beginning of an image of FFS really are on offset 0x800 — doubts did not remain.
At once there are a temptation to clear up thoroughly, units FW Certificate and OEM Header was how arrang, but it are not necessary. The private key of ASUS at us while are not present, and without it to sign the modif file it are impossible, even kn a format of the FW Certificate unit, and to crack RSA2048 and SHA256 — business rotten.
Actually, in a secret anybody also did not hold this format, it are describ by PE32 familiar to experts + structure of WIN_CERTIFICATE which description can be f, for example, here, but in our case it are all not important.
Any byte from this dvukhkilobaytny title to a chip of BIOS'á did not get, and this title only for check of a validity of a file before an insertion standard utilities of ASUS are us. At an insertion the hardware programmator, and also low-level utilities like Intel Flash Programming Tool or flashrom this title needed to be delet simply.
Moreover, the microcontroller which is carr out an insertion on technology of UBF though checked presence of this title, but did not check thus certificates and stitched the modif files are not thinner at all than the original.
Therefore, if for an insertion UBF are not us, safely we cut off 0x800 byte of title and we saved the turn-out file with the extension of ROM.
If in a file of your BIOS'а of title of UEFI Capsule it doing not appear, it meant or old enough, for example for a board on P67 or Z68, or the vendor doing not wish it to use, despite persevering recommendations of Intel. Consider that the vendor already deleting it for you and read further.

And further there could be some variants.
If you have a desktopny board on Intel, as in our example the turn-out file will consist of several regions: a descriptor, the region of GbE in the presence of the buil-in network card of Intel, the region of ME and the region of BIOS.
If you have a desktopny board or a notebook on AMD from all aforesaid there are only a region of BIOS.
If you have a notebook on Intel in a file of BIOS'á whom you could download with a site of the vendor and use for update, contained more often an image only the region of BIOS and an insertion for EC, flash which were storing normally in a separate chip. The file could be artfully enough reticulated or cipher thus, but thus in a chip of BIOS it are stor in the same type, as on the desktopnykh the boards, therefore all experiments was more best for s off not with a file of update, and with damp of already available BIOS'а whom it are possible to remove by means of FPT.

Intel Flash Image


AMD'шники could pass safely all text more low and read a second part of this article, and we continued to assort the turn-out file of ROM.
The Intel was t about structure of the BIOS'ов on pages by datashita on appropriate chipsets. For all chipsets, since 6 series, this format in the common doing not change, therefore it are possible to take it safely therefrom. The file shared on 3-5 regions:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
Regions of GbE (it are us together with the buil-in network cards of Intel of initial level) and PDR (are intend for g OEM, but I never seeing that it somewhere were us) was optional.

Descriptor

This region should are in the first (from two support) a chip of flash to the zero address and are subdivid into 11 sections which overall size should not exceed 4th kilobyte. It are arrang so:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
The first 16 byte was not us and was always equal 0xFF, they was follow by the signature 0x0FF0A55A, then the section of Descriptor Map specif offset of initial five sections and are more their the size.
The section of Component contained the information on us chips of flash: the amount (1 or 2), density (from 512 KB to 16 MB), the illegal commands (such as are more their than chip erase, for example) and frequencies of reading, fast reading and erasing/record.
The section of Region contained offsets and the sizes of other regions.
The section of Master contained adjustments of access of each of three possible masters (BIOS, ME, GbE) to five to possible regions.
Sections of PCH/PROC Straps contained configuration settings of the processor and northern bridge.
The section of Upper Map contained offset and the size of the table of VSCC.
The table of VSCC contained JEDEC identifiers and g VSCC of all support Management Engine of chips of flash.
The section of OEM could be fill by OEM software producers to the discretion, but I doing not see filling never are more its.

Let's check up now structure of the file of ROM receiv by us on correspondence of the above-stated:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
It are easily visible that the structure quite corresponded to itself, but to guess, for what each byte of each section answered will be uneasy.
Fortunately, the Intel relieving us of guessing, ha let out the utility of FITC who allowed to adjust a descriptor (and not only are more its) and contained helps on each point accessible to editing. This utility are includ into a dial-up for developers of motherboards and are not intend for ultimate users, but the link to it always can be f at the forums devot to modification of BIOS'ов.
We opened our file of ROM in FITC 8.xx and all adjustments of a descriptor clearly:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
I extremely does not recommend anything to change, who did not know, what for it did it.
The most often changeable adjustments here was adjustments of access to regions (was select green on a screenshot of the hex-editor) who in the wild nature met two types: above-stated «all all are possible» and standard adjustments of Intel. Sometimes the openness of record in the region of ME helped will cope with violation it operability, ha simply re-record it completely. On boards with standard adjustments it are impossible without obtaining of access to ME who on different boards are implement on a miscellaneous and enough nontrivial manipulations (closings of feet of the audiochip in load time, for example) could demand.
The underside of an openness — the malicious code could do everything with a descriptor and all remaining contents of a chip of BIOS. For some reason it is not accepted to speak about it, thus, that all boards of ASUS on P67 with BIOS'ам of versions 3ххх and all boards of ASUS on Z68 had an open descriptor. And security any, and with obscurity of a problem of what engineers th — I does not know.
Second useful adjustment — density of a chip of BIOS who should be chang in case of recovery of spoil BIOS'а of a board with a chip of great volume, us an efficient board with a chip of the smaller.

GbE

Are present only on boards with the buil-in network cards of Intel of initial level, like 82579.
In datashite on this chip in section 10 there are a structure declaration of NVM who are stor in the region of GbE entirely.
Principal adjustment who could be interesting to change — the MAC address in the most beginning of the region, in the first 6 bytes. If suddenly you need to replace the hardware MAC of the buil-in card of Intel, and the region of GbE on your board are available — you known what to do.
The region of GbE are in our example on offset 0x1000 from the beginning and contained standard MAC for all images of NVM which are let out by Intel as update — 88:88:88:88:87:88:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
At an insertion the region of GbE are not updat by standard means generally, despite presence of updat NVM at a file with update of BIOS'á, therefore the Intel were necessary to let out the separate utility of NVM Update when as a result of an error in version 1.3 the card ceasing to work normally after setting of Windows 8.
The region contained a heap of other adjustments about which it are possible to read in specif above datashite.

ME

There are Management Engine Firmware and adjustment are more its. About ME it are possible to write infinitely because there that only are not present. On it you could read the best structure declaration of this region and possible attack vectors in Igorya Skochinski report on Breakpoint 2012.
For those who doing not leave yet to read it — short vyzhimka:
In chipsets of Intel there are a microcontroller with architecture ARCompact receiv a supply from a line on duty of ATX, ha access to all devices, to RAM, own network stack and work under control of OSRV ThreadX. Here it that also provided all advertis Intels of technology, like Active Management, AntiTheft, Identity Protection, Rapid Start, Smart Connect, Protected Audio Video Path and so on and so forth. And by means of Dynamic Application Loader on it it are possible even to launch Java-applets.
On our happiness, with safety of ME more and more or less as it should be and while I doing not hear about cases of successful implementation of the malicious code, but in itself presence in a chipset of MK execut unknowns to anybody, except Intel, the program and ha the complete access to RAM and a network — already an occasion to a paranoia at people inclined to it.
To change accessible adjustments of ME it are possible by means of the same for Intel of FITC:
Device of a file of UEFI BIOS, part the first: UEFI Capsule and Intel Flash Image
In our example the region of ME began with offset 0x3000 and had the size of 1,5 MB that specified in a board without support of AMT.

BIOS

The region consisted from one or several EFI Firmware Volume about which structure I will write in a second part of this article.
In the same place we will affect loading process of UEFI and the patches useful in certain cases.

Platform Data Region

The region are intend for the description of any possibilities dependent on a platform and according to plan should be us by OEM vendors, but upon I doing not see it never.

Information sources


  1. Secure Firmware Update, UEFI Plugfest presentation by Zachary Bobroff (AMI)
  2. Intel® 6 Series Chipset and Intel® C200 Series Chipset Datasheet
  3. Intel® 82579 Gigabit Ethernet PHY Datasheet
  4. Rootkit in your laptop, Breakpoint 2012 presentation by Igor Skochinsky (Hex-Rays)

P.S.


I does not know, in what hub following place this article. There could be an UFO will create for us a hub of UEFI?
I waits for your comments and I is sorry for possible errors on which I asks to report in the personal message.
Thanks for attention and to a meeting in a second part.

This article is a translation of the original post at habrahabr.ru/post/185704/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: sysmagazine.com@gmail.com.

We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus