Posts Tagged ‘BIOS’
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.
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.
Ever since the computer was born, there needed to be a program to tell the CPU where things are and how to use them. In 1981 the IBM 5150 introduced the BIOS (Basic Input/Output System) to the IBM-PC market. The IBM 5150 had an 8088 16bit (16bit internal bus, 8bit external bus) processor, so the BIOS chip was limited to 16 bits and 1MB of memory space. Years went by and the CPU became more powerful, with a wider bus and more memory access. However, the BIOS remained the same, and retained it’s 16bit bus and 1MB memory limit, depending on the PC-AT hardware platform.
Enter EFI/UEFI (Extensible Firmware Interface/Unified Extensible Firmware Interface respectively). EFI was introduced in the mid-1990′s with the Intel-HP Itanium processor systems as the older BIOS was considered too limited for large server systems. In 2005 Intel dropped the EFI platform and handed it over to the Unified EFI Forum, which then became the UEFI.
There are several advantages to UEFI over the BIOS. UEFI boots faster, has the ability to boot from very large hard disks over 2TB, drops the MBR (master boot record) for the GUID Partition table, architecture and drivers are CPU-independent, an extensive GUI with mouse and network capabilities are possible, and ACPI and SMBIOS are also included as these are not dependent on the 16bit limitations of the older BIOS.