skysafe/reblog

GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.We found a laptop laying around the office that had BIOS password enabled. optionally verifies the integrity of the DXE phase's code. Some of these drivers persist even after your OS has booted.UEFI defines its own filesystem format for use in flash images. The BIOS region consists of several firmware filesystem volumes and an NVRAM variable storage area. check, but that wasn't possible on this laptop because hardware-based firmware security was enabled.In the image above, areas marked in red are protected by Intel BootGuard. by end-users.None of us had ever seen the secure boot enable flag or the BIOS password stored anywhere except inside of thing that we wanted to try was completely clearing all of the NVRAM variables and having the board use its default If we were lucky, secure boot would be disabled and the BIOS password would be gone. when we tried to boot the board after clearing the variable store, we were presented with the following error message:We searched for a portion of that string in the dump, and then loaded the DXE driver containing it into IDA. was not enough data in the variable to contain either the password itself or the hash of the password. been stored off-flash on an entirely different chip.It was possible to return to the boot device selection menu after you had booted into a flash drive by exiting the UEFI We looked at the NVRAM boot entry for the setup menu and saw that it protocol and found one place where we believed that it was determining whether or not a BIOS password was enabled. called one of the functions provided by the protocol, and if the return value had its lowest bit set, it would do something with the string Enabled, otherwise it would do something with the string Disabled.We assumed this was related to the code for displaying the menu entry for the BIOS password, and that the function it bank ID 0x57.We wrote a quick UEFI app to try and read out all 0x100 bytes from that bank ID, but every call we made to eepromRead returned an error code for the first 0x80 bytes. have been impractical to dump or reflash whatever chip it was stored on.We knew at some point during boot, the permissions had to be set to allow at least some operations, because the prompt we noted earlier, if you booted into an external app, such as a UEFI shell on a flash drive, the "Enter Setup" button instead of a path to a file to run, the variable contains the GUID of a built-in app. These are all of the options that we changed:At this point since we were unable to boot into anything except the boot menu, our only option for editing those NVRAM needed the address of the UEFI system table, and the automatic scan for it failed.In most UEFI binaries built using EDK-II, the system table gets stored in a global variable when the driver/app's bytes in UEFITool to determine which module we were currently executing code in. extracted from the firmware dump to figure out which base address corresponded to each module we were interested in.We pondered the best way to execute arbitrary code for a while. the firmware; after our code had run we could just reboot the board.We looked back at the code inside of BpwManager, and determined there was a two byte checksum that we hadn't erased. After overwriting the two bytes and resetting the board, the BIOS password was finally gone! tried setting our own password from the setup utility just to make sure that it was actually gone and we had full