But the questions were still defined and the code that acted on those options was still present, so simply modifying the variables while still inside Boot Services gave me what I wanted. In my case, the firmware option I wanted to alter had been enclosed in "GrayOutIf True" blocks. As long as all the security critical variables are Boot Services only, an attacker should never be able to run untrusted code that could alter them.
UEFI variables can be flagged as being visible in both Boot and Runtime Services, or can be flagged as Boot Services only. This is also considered a security boundary - before ExitBootServices everything running has been subject to any secure boot restrictions, and afterwards applications can do whatever they want. The transition is triggered by the OS calling ExitBootServices, indicating the handoff from the firmware owning the hardware to the OS owning the hardware.
#UEFITOOL GREYED OUT FULL#
Given that a bunch of these config values may be security relevant, this seems a little concerning - what stops an attacker who has access to the OS from simply modifying these variables directly? UEFI avoids this by having two separate stages of boot, one where the full firmware ("Boot Services") is available, and one where only a subset ("Runtime Services") is available. And now you have the list of variables and offsets and the configuration associated with them, even if your firmware has chosen to hide those options from you. Running IFRExtractor-RS against it will then pull out any IFR data it finds, and decompile that into something resembling the original VFR. If you use UEFITool to search for "Setup" there's a good chance you'll be able to find the component that implements the setup UI. UEFI firmware images are typically in a standardised format, and you can use UEFITool to extract individual components from that firmware. Rewriting Setup-EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 with a modified value in offset 0x39 will allow direct manipulation of the config option.īut how do we get this data in the first place? VFR isn't built into the firmware directly - instead it's turned into something called Intermediate Forms Representation, or IFR. The question indicates that the offset for that variable is 0x39. VarStore GUID: EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9, VarStoreId: 1, Size: 0xF4, Name: "Setup"Ī UEFI variable called "Setup" and with GUID EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 is declared as VarStoreId 1 (matching the declaration in the question) and is 0xf4 bytes long. But where's that stored? Earlier we have another declaration: As a checkbox, if it's set then the value will be set to 1, and 0 otherwise. Other questions can then rely on the answer to question 53 to influence whether or not they're relevant (eg, if console redirection is disabled, there's no point in asking which port it should be redirected to). In which question 53 asks whether console redirection should be enabled or disabled. An example in this language might be something like:ĬheckBox Prompt: "Console Redirection", Help: "Console Redirection Enable or Disable.", QuestionFlags: 0x10, QuestionId: 53, VarStoreId: 1, VarStoreOffset: 0x39, Flags: 0x0 Questions can be made dependent upon the answers to other questions, so you can have options that appear or disappear based on how other questions were answered. At the most straightforward level, this lets you define a set of forms containing questions, with each question associated with a value in a variable. One of the things UEFI introduced was a mechanism to generically describe firmware configuration options, called Visual Forms Representation (or VFR). Thankfully in this case there was a way around that. Some emails revealed that this was a deliberate choice on the part of the system vendor, so that seemed to be that. Today I had to deal with a system that had an irritating restriction - a firmware configuration option I really wanted to be able to change appeared as a greyed out entry in the configuration menu. Update: There's actually a more detailed writeup of this here that I somehow missed.
0 kommentar(er)
