Posts Tagged ‘UEFI’
In case you didn’t already know, the Extensible Firmware Infrastructure’s Human Interface Infrastructure uses Internal Forms Representation protocol to display things like your setup utility’s menu. By having access to the Internal Forms Representation, we can know everything about a menu which can assist us immensely when modding bios. I’ll also be using this application in a few of the tutorials I write, so get used to using it now
I was getting tired of all the requests to expand EFI IFR Dumper to include support for UEFI’S IFR protocol, and as a result I decided that now is a better time than any to update my program. So here’s Universal IFR Extractor, the successor to EFI IFR Dumper. Designed to easily extract and convert the Internal Forms Representation used in EFI modules into a human readable format. Now supports both EFI and UEFI IFR protocols, so it should work with all cases
In additional, Universal IFR Extractor now has a graphics user interface to make it easier to use. It’ll quickly tell you what protocol a selected module uses so that you’ll be able to know what protocol format you should know in order to modify the forms. Intel has great documentation on how EFI and UEFI IFR is formatted, so it should be too hard to start modifying it after reading through those. I’ll also create a tutorial on how to preform simple modifications, like how to unsuppress hidden options, so stay tuned. Hope you all enjoy! Download it here
I first started working on Module Helper back in September when Andy’s tool V2.19 was released. As some of you may know, that iteration altered the format of the extracted EFI modules by storing a module’s header, code, and name all in the same file. This created some issues with disassemblers not being able to automatically recognizing the format of the EFI modules and the size of data modules not being updated if changed. Dealing with all these negative aspects was trivial but annoying, which is why Module Helper was developed. It was originally capable of splitting the modules header and data into separate files an it could update the sizes in the headers. It also had a renaming feature that would make locating certain modules easier. I only made this program only for Linux, but I had always planned to port it over to Windows before releasing it.
However, Andy’s tool V2.50 was recently released, and it has switched back to using the earlier format for the extracted modules. This event made Module Helper obsolete, but by this time I had gotten used to how it would rename functionality. I didn’t want to lose this convince, so I changed it a little to work with the latest version of Andy’s tool.
This article documents the exciting work being done by some of our top contributers in our forum. The modifications performed on systems like the Dell 15z reflect the most advanced examples of BIOS modifications done within our community. For more information, please visit the thread.
Phoenix SecureCore Tiano, used by Dell, is a tough nut to crack – we came to what we have today by taking little steps on a road that wasn’t smooth to begin with. Phoenix nor Dell have provided any information regarding SCT 2.0 and to this day the BIOS on these machines has not been upgraded to 2.3.1 which allows for ME v8 (brings IVB CPU support) and SecureBoot capabilities.
The number one utility in all of our research is without a doubt AndyP’s Tool, which can be found here. Huge props to him – without his tool our work wouldn’t be possible. Please note, that for some reason later versions of this tool such as 2.11 don’t seem to unpack the BIOS.wph’s capsule properly, so use versions prior to that if you are going to attempt doing some *magic* on your own. There have been a new Phoenix Tool release v2.12 but I have yet to try it, I personally still use 2.02 and it has been producing stable and working output.
The BIOS chip structure is the following:
Platform: Intel(R) HM67 Express Chipset
— Flash Devices —
Size: 4096KB (32768Kb)
00000000h – 00000FFFh: Flash Descriptor Region
With the advent of UEFI and Windows 8 comes some security and usability issues. When Windows 8 is released, UEFI’s “Secure Boot” will be required to be turned on by default and it will be left to the OEM’s on how to implement it. What does this mean to you? Maybe nothing.
Windows is still the most popular PC Operating System in the world. As such, it is highly likely that the computer you are reading this article on is running some version of Microsoft Windows. If you are running Windows 7 and up, your OS is compliant to UEFI specifications. But what if you want to run a different OS, like Linux, older versions of Windows? You could be out of luck.
What is Secure Boot?
Secure Boot is a UEFI 2.3.1 specification that during the boot process verifies certificates (or keys) held in the firmware, and compares them to other Option Roms and OS boot loaders. If the correct key is not in the firmware, or is in the “Blacklist”, Secure Boot will prevent the OS from loading or could prevent you from upgrading to certain manufacturers option cards. Since it will be up to the OEM (Original Equipment Manufacturer) to implement the Secure Boot feature, it is also up to them whether or not to add an option in the set-up to disable it, or to be able to update the “Allowed” OS list. So, if you were to buy a Windows 8 PC and want to install a new version of Linux, and there is no option to disable Secure Boot, and the key for the version of Linux you are installing is not found in the firmware, the OS will fail to load. This feature is intended to prevent malware such as “rootkits” and “bootkits” to install themselves and run when booting your OS. According to Microsoft, the Windows 8 implementation of Secure Boot, programs will not be able to change Secure Boot security settings to prevent malware from gaining access through reprogramming the firmware.