Recent days in order to activate the WOL feature on the notebook, there is some understanding of the UEFI BIOS. The new generation of UEFI specification realizes a lot of advanced functions, Boot,secure interface, file system support, extensibility, secure Flash (capsule), and so on, and these are intended to make the user experience better, use more convenient, safe function, by the manufacturers read the wrong warp. M$ uses the secure boot feature to restrict the computer from installing other operating systems, even installing Ubuntu-like systems, and even further installation of various drivers is restricted (this will later be written again, in general, through the PK self-signed bypass). Len0v0 uses UEFI advanced features, after the user re-install the system automatically reinstall Lenovo components, it is understandable, but the domestic version of the **@*%#¥ ..., and the previous period of time has been burst security loopholes. Time Cure Flash makes it extremely difficult to refresh firmware, perfect brush write only to crack signed capsule structure or use SPI burning. Not to mention the whitelist limit users to install a new network card, the previous period of time to make a fuss about me, EC loopholes and so on. In short, the real power of UEFI can be implemented, but also to see the various manufacturers of (Wei) (suo) and state (Cheng) degrees (du) ... The real security is not the manufacturers feel safe, but to make users feel safe, to their own use of things have complete control.
Platform: Lenovo G50-80 Notebook, UEFI bios,insyde BIOS
Conclusion:
1. Using the Insydeflash tool, in general, secure Flash, that is, directly write the upgrade file to the memory area (or ESP partition), form capsule, then send the SMI instruction, set the updated variable, and then S3 reboot, After reboot, the system goes directly to upgrade mode, performs capsule checksum by the existing BIOS , (may include Insyde QA and manufacturer trust tests, similar to RSA signatures), The checksum is refreshed by the Flash program in the existing BIOS, which may flush the EC (internal microprocessor firmware, such as motherboard driver, function key driver, etc.), ME (CPU microcode), FV (not knowing anything). System variables may be refreshed during this period, such as the original BIOS settings, secure boot key,slic, root certificates, and so on. This causes the BIOS changes cannot be brushed in, the BIOS check program in Flash, the crack calibration program itself needs to brush into the new BIOS, and do not crack the checksum can not be brushed into the new BIOS, this security is very high. See the UEFI capsule specification, as well as Intel's development Guide, and Tinocore's source code for details. (https://www.techinferno.com/index.php?/forums/topic/1870- flash-modified-biosuefi-which-are-digitally-signed-circumvent-secure-flash/)
2. The Bios-mod website gives the recover way, by pressing a few keys at boot, let the computer enter the BIOS Repair mode, read the firmware from USB, and restore itself. The key here is how to get into the recovery model and how to obtain the correct recovery file. After groping, G50 model recovery key is: Shut down, plug in the battery, plug on the USB flash drive with recovery files, unplug AC, press and hold fn+r do not let go, plug AC and press the power button to boot, power lights flashing red, release all keys. But the correct recovery file format and file name were not found. The estimate should be to use the official given upgrade file bioss.fd, perhaps should be renamed to BROADWELL.FD (from Pcdpeim module found, see https://www.bios-mods.com/bios-recovery/ insyde-bios-recovery/#comment-1457), unplug all USB devices outside of your USB drive ... But has not been successful , the reason is unknown. And it is said to be recoverable, the recovery process also needs to be verified, and This approach may not bypass the checksum .
3. Directly write Flash, this method includes the use of the FPT tool under DOS (Intel's official Brush writing program, the development of UEFI tools, can be directly written), under the EFI shell with some tools to write, DOS under the other tools to brush and write, These methods are directly read and written by some special instructions flash chip, there is a great danger, on the one hand these read and write instructions may be locked, it is easy to write failure. On the other hand because do not understand the structure of the flash (manufacturers can not be public), it is easy to brush into bricks (such as the wrong area, or the ScanDisk code brush off, etc.) ... These will cause irreparable soft-brick ..... Non-warranty. It is generally not possible to fix it personally unless you have an SPI tool.
4.SPI, using the burner directly to brush the chip, the risk of the same, but due to the SPI, Flash content can be fully read and write, you can read it first to do a full backup. There is always a fix to the problem. The advantage is that the clamp can be directly clamped on the chip pin, without the need for desoldering, very convenient. This is also the general motherboard repair method. (Https://www.bios-mods.com/forum/Thread-TUTORIAL-how-to-unlock-hidden-tabs-in-lenovo-g50-80-Mod-lenovo-g50-80-bios)
But! Flash chip is very easy to brush bad, once the bad is more troublesome. In addition, stable SPI tools are not cheap. And, for the EC and CPU ME, there seems to be no way to write directly. Nvram (the location where the system variables are saved) is unclear.
5. Directly read and write variables, to achieve the purpose of partial modification. This is also recommended on the Bios-mod forum. In general, under DOS or EFI shell directly read and write NVRAM, to cross the BIOS interface directly modify the function of the system. The problem with 3, some read-write instructions may be locked. As for how to determine where a variable is stored, the UEFI BIOS file needs to be parsed, and some tools can be implemented, including the various tools, scripts, such as Universal IFR extractor in the MDL and Bios-mod forums, roughly by parsing the UEFI The BIOS file found the variable storage location (UEFI file is easy to parse, has a fixed format, the tool can parse most formats, but some vendors do not parse the UEFI BIOS). (Https://www.bios-mods.com/forum/Thread-READ-FIRST-Access-Advanced-settings-through-EFI-shell). The Bootx64.efi is a generic uefi SHELL and can be compiled by Tinocore's corresponding source code.
These are several ways to brush and write Insyde BIOS. The specifics of handling the Insyde BIOS can be found on Google or in the Bios-mod and MDL forums. The next article continues.
Insyde [email protected] Discussion