HP_BBUpdate & Other HP-Specific BIOS Modding Protection (12th Gen Intel / AMI)

Outsyde · August 23, 2023, 8:50pm

I have an HP Omen 12th Gen Intel laptop with an AMI BIOS.

I’m thinking of modifying it and flashing it back with a CH341A.

I’m not new to this stuff in general but I’m new to HP-specific considerations.

I’m reading that on some HP models the BIOS is encrypted, and that there is extra cryptographic verification at the EC level.

I don’t think there is anything special with the model I have though, since a BIOS image can be read just fine with UEFI Tool or AMI tools. There is only a single 16MB (128Mb) system BIOS chip (the other is the nVidia VBIOS). The image does not have any $HSS or $HCS patterns. This is a gaming series laptop, there are no references to HP Sure Start or anything like it throughout the IFR (so even in the hidden settings).

But I also can’t seem to find any success stories of modded HP Omen BIOSes. So am I missing something here? Will I run into issues if I just modify an image and flash it? Short of flashing a modified image, how can I check if there are extra HP-specific hurdles that would have to be negotiated?

I read through the posts here and external articles. To the extent that I can tell, none of the things described there apply to this situation, but perhaps I’m just looking in the wrong place. Please tell me what I am missing.

Edit: Title updated to reflect HP_BBUpdate as a point of interest.

Sweet_Kitten · August 24, 2023, 4:18am

There was success with HP Gaming 15-EC series on Ryzen. This required the signature verification in HP_BBUpdate module to be disabled.

Outsyde · August 24, 2023, 11:19am

Excellent! This is very helpful. Thank you @Sweet_Kitten!

So there is indeed a HP_BBUpdate module, GUID: 94F994D5-4F3D-4FA6-BDA1-D398C3B0BB8 and also a HP_BBUpdate_Loader, GUID: 5C0203AC-5118-4952-9AAE-614AAE683FD4 in the BIOS I have.

_{For the record, my BIOS is a 08A13, version F.15, although the system board ID is 08A14: no mistake here, the BIOS image seems to be common for both versions. Just adding this for completeness, as it’ll eventually come up later anyway.}

Prior HP BIOS Mod

Findings

I found some details regarding a prior mod involving HP_BBUpdate, close to the HP 15-ec series but not quite the same. It’s for a HP Pavilion 15-bc404ur (4EL78EA), an 8th Gen Intel / nVidia device from 2019 with an AMI BIOS as well. Even more similar then, so far so good.

On another forum, cerg2010 (credit where credit’s due) posted a mod against BIOS version F.21 (2018-11-14) for this device.

_{The stock BIOS image was included in update SP92665 from HP. A user on that forum preserved an earlier version of that download, which is a completely different executable but the BIOS images stored inside them are identical, so never mind. Two other images are included in the update, for 084ED and 084F7 as well, but the mod is for system board ID 084F8.}

Besides the signature verification check removal (which is what I’m most interested in), the mod also unhides the setup menus, removes the PRRs and Wi-Fi whitelist, enables BCLK overclocking, and disables signature check for BIOS recovery mode flash (will execute any EFI file named HpBiosUpdate.efi or HpBiosMgmt.efi). So the scope of changes is quite vast. Kudos to the modder!

To that effect, there are changes in two modules as well as to the ME region. The changed modules are:

Pre-EFI Initialization (PEI) module HP_BBUpdate GUID: 94F994D5-4F3D-4FA6-BDA1-D398C3B0BB8F, which appears twice in the 084F8 image, so it has to be replaced twice. In my 08A13 BIOS I only have it once.
Driver Execution Environment (DXE) module AMITSE GUID: B1DA0ADF-4F77-4070-A88E-BFFE1C60529A.
_{Note / Reminder: the proper way to extract these modules for comparison with UEFI Tool is to right-click and Extract body… of the PE32 Image Section under LzmaCustomDecompressGuid. It’s easy to get that wrong.}

Interestingly, there were 7 further BIOS updates for this device. The latest one is F.33 (2022-08-16), as part of SP141996. While AMITSE has changed significantly between the versions, the HP_BBUpdate module remains the same in both F.21 and F.33, which means that part of the mod could be reused for the newest version. Unfortunately, the HP_BBUpdate binary is completely different in the 08A13 BIOS I’m trying to mod (that’d make it just too easy).

Conclusions

Since AMITSE is just the setup utility, no matter what is there would not prevent a modified BIOS from booting. While I also want to unhide menus (in fact it’s the very reason why I’m attempting the mod), it’s outside the scope of the question here and can be ignored for now.
There is no mention of any mods to HP_BBUpdate_Loader and since it’s also present in the 084F8 image, it can be concluded that it doesn’t have to be modified.
The reason why there are two versions of HP_BBUpdate in the 084F8 image is because there seem to be two exact copies of the same EFI firmware filesystem there, both with the same Volume GUID: 61C0F511-A691-4F54-974F-B9A42172CE53. In HP_BBUpdate itself, there are mentions of “1st” and “2nd” boot blocks, $HP1stBB and $HP2ndBB, etc., which I think refers to this as well. By comparison, in the 08A13 there is only one Volume GUID 61C0F511-A691-4F54-974F-B9A42172CE53, which falls in the BootGuard-marked area. HP_BBUpdate is outside it, on a Volume GUID: 14E428FA-1A12-4875-B637-8B3CC87FDF07. Essentially, the image layout is significantly different.
The ME region is completely different in the mod compared to the stock F.21. At first glance, it’s difficult to say what exactly is going on there. Running them through @platomavfan’s ME Analyzer, it seems these are actually two separate versions: 12.0.10.1127 in the stock BIOS vs 12.0.0.1069 in the mod. Thus, the mod is a downgrade. Looking at the earlier BIOS releases: F.17 (SP8813), F.18 (SP88779), and F.19 (SP91738), it turns out all three have the same ME version as the mod. And thus the difference between the stock ME region from these earlier versions and the mod is just down to 5,688 bytes out of the 3,141,632 bytes total size, so approx. 2%. Much easier to investigate further if need be.

I’m sharing all the relevant files so there is no need to redo the same work if anyone else wants to look into it: 110.44 MB folder on MEGA

_{The file names are hopefully self-explanatory.}

To Do

Disassemble and compare 084F8_HP_BBUpdate_F.21_F.33.efi and 084F8_HP_BBUpdate_F.21-Mod.efi to see what the patch is doing exactly: there are 3 different bytes as per 084F8_HP_BBUpdate_F.21-Mod-Diff.txt. Using these findings, reapply the same patch to 08A13_HP_BBUpdate_F.15.efi.
What about the ME region? In order to make a modified BIOS boot, are changes necessary to the ME region as well? Or is this part of the other mods only? The definite answer is in the 5,688 different bytes between 084F8_ME_F.17_F.18_F.19.rgn and 084F8_ME_F.21-Mod.rgn as per 084F8_ME_F.21-Mod-Diff.txt.
The BIOS I’m trying to mod has BootGuard enabled with both Measured and Verified boot. The Firmware Information Table (FIT) has entries for Startup ACM, BootGuard Key and also TXT Policy. None of this is present in the modded 084F8 8th Gen BIOS from 2018. Does this present an additional obstacle? The following seems to be a good BootGuard primer but the implications are unclear to me at this point: Bootguard - Trammell Hudson's Projects
And of course, is that the extent of it, or were there other possible surprises added by HP between the 8th and 12th Gen?

I’m not exactly there yet but it’s a start. If anyone wants to chip in, it’d be much appreciated. @Sweet_Kitten’s answer helped a lot, and I’m very grateful.

Sweet_Kitten · August 24, 2023, 11:46am

It’s unlikely that ME region requires any change. But I’m not sure, because I never managed to unlock an HP OMEN laptop of which I undertook in the past.

I reproduced the patch in HP_BBUpdate, but Boot Guard prevented me from moving forward, I think. And I don’t know what exactly do about Boot Guard.

You have a CH341, it worth trying to change the default value for Boot Guard in NVRAM. Provided that there’s an option for that in Setup and HP_BBUpdate is already patched.
That’s it that I can say.

Outsyde · August 24, 2023, 12:46pm

Which variable would that be? There’s nothing Boot Guard-related in the IFR, except status report under IBV Advanced (hidden menu) → CPU Configuration:

Text Prompt: "Boot Guard Status ", Help: "Boot Guard Status Register value", Text: "N/A"
Text Prompt: "Boot Guard ACM Policy Status ", Help: "Boot Guard ACM Policy Status value", Text: "N/A"
Text Prompt: "Boot Guard SACM Information ", Help: "Boot Guard SACM Info MSR value", Text: "N/A"

I am disabling BIOS Lock (offset 0x1C) and RTC Memory Lock (0x1B) in PchSetup already. Other than that, I can also set ME Reflash Enabled in MeSetup (0x03) and ME Disabled in MeSetupStorage (0x02), which reset themselves on next reboot.

Disabling ME does not seem to work, and there is a message flashing on the screen following POST for a split second: “Me Fw Downgrade - Request MeSpiEnable Failed.”

Disabling BIOS/RTC lock does work to an extent as reported by Chipsec:

=======================================================================
[x][ Module: BIOS Region Write Protection
[x][ =======================================================================
[*] BC = 0x10000888 << BIOS Control (b:d.f 00:31.5 + 0xDC)
    [00] BIOSWE           = 0 << BIOS Write Enable 
    [01] BLE              = 0 << BIOS Lock Enable 
    [02] SRC              = 2 << SPI Read Configuration 
    [04] TSS              = 0 << Top Swap Status 
    [05] SMM_BWP          = 0 << SMM BIOS Write Protection 
    [06] BBS              = 0 << Boot BIOS Strap 
    [07] BILD             = 1 << BIOS Interface Lock Down 
    [11] ASE_BWP          = 1 << Async SMI Enable for BIOS Write Protection 
[-] BIOS region write protection is disabled!

(Before, it was BLE = 1, SMM_BWP = 1, and thus BC = 0x100008AA.)

But this isn’t enough to even get full read access via FPT (fptw64 -d fails although I can dump BIOS, ME, and descriptor separately).

UEFI variables are not write-protected, so I have full access to them (maybe except Secure Boot-related stuff but that’s off anyway). So if there is any other setting to loosen this any further I’d like to know.

I’ll look into this HP_BBUpdate patch next.

Edit #1: And thanks!

Edit #2: I know of course there is more to UEFI vars than what’s exposed through the IFR but I find it difficult to work with EFI Shell’s dmpstore -all -s dump.txt “text” output, so if you could be more specific in what I should be looking for, it’d be great.

Sweet_Kitten · August 24, 2023, 1:31pm

I thought the IFR would tell, but it doesn’t have a switch for Boot Guard. Maybe there’s any variable store related to BG?

Outsyde · August 24, 2023, 6:04pm

As much as I’d love to get rid of Boot Guard while at it, I don’t think it’s that simple. So rather, I’m thinking of approaching the problem from the other end: since the HP_BBUpdate module happens to be located outside the area marked for Boot Guard “protection,” I’d like to confirm a modded BIOS will still work as long as I don’t touch that area.

I hope someone could corroborate that because the exact scope of what can and cannot be done with Boot Guard remains a mystery to me. I guess I’ll have to do my own research but if someone could shed some light on it, I’d be grateful because so far other than that, the problem seems approachable.

Sweet_Kitten · August 24, 2023, 6:34pm

And so applies to HP. This is a quote from a topic about some interesting tool. I wonder if it can be combined with the knowledge we already have.

Outsyde · August 24, 2023, 6:56pm

I guess the answer is a tentative “yes” in this case, if things haven’t changed since 2019:

But then also:

Outsyde · August 24, 2023, 11:09pm

OK. So I looked at the patch. It changes 3 bytes total in 2 places:

jnz → jmp

Jump-if-non-zero becomes an unconditional jump.

xor al, al → mov al, 1

HP_BBUpdate-08A13-2

xor al, al is effectively mov al, 0 and the patch changes it to mov al, 1

Very elegant. I adopted it to HP_BBUpdate version in the BIOS I’m modifying (08A13 F.15). Hopefully it works.

It can be downloaded from the Mega.nz folder.

Outsyde · August 26, 2023, 7:00pm

I prepared a mod with a couple of changes, and did some testing today:

Scope

The modified modules were:

Setup EFI Executable
899407D7-99FE-43D8-9A21-79EC328CAC21
AMITSESetupData Data / Non-Executable
FE612B72-203C-47B1-8560-A66D946EB371
- To reveal all setup menu options
HP_BBUpdate PEI Executable
94F994D5-4F3D-4FA6-BDA1-D398C3B0BB8F
- To bypass modification prevention check (see previous posts)

All outside of Boot Guard-marked areas as identified by UEFI Tool.

Tests

1. All 3 Mods: HP_BBUpdate, Setup & AMITSESetupData

EC Working (Fan & Backlight)
Screen Remains Black Permanently
No Caps Lock LED Flashing Signal
^{(This is used by HP to relay POST failure codes)}

2. No HP_BBUpdate; Setup & AMITSESetupData Only

To confirm that the lack of any prompt whatsoever is due to HP_BBUpdate not running properly.

Screen Goes On
Prompt: “BIOS Corruption has been detected”
Self-Reboot
Prompt: “The boot recovery files cannot be found or are corrupted”

I checked that these messages come from the HPCrisisRecovery module
5AF2FFE6-82F4-4CD4-AAA8-7BE868691FC1

So the unmodified HP_BBLoader was allowed to run normally by Boot Guard or whatever else but decided not to let me run the modified BIOS.

3. No HP_BBUpdate or Setup; AMITSESetupData Only

AMITSESetupData is a non-executable data file only, so it was worth checking if changing it only and nothing else might go unnoticed.

Result the same as (2)

4. HP_BBUpdate: Minimal Mod (Text String Substitution Only)

To rule out an issue with my patch to the code of HP_BBUpdate, I made another really simple one, where I only changed one word within a text string. This is 100% guaranteed to run just as the original.

Result the same as (1)

So something is preventing HP_BBUpdate from being run if modified at all, no matter how insignificant the change is.

5. HP_BBUpdate, AMITSESetupData - Built with AMI MMTool

For all prior mods, I was using UEFI Tool 0.28.0, which is an old version (as the development branch remains read-only for the time being). So to check if this might be an issue with the software, I tried rebuilding this mod with AMI Module Manipulation Tool (MMTool) 5.02.0025 instead.

Result the same as (1)

So it does not seem to be an issue isolated to a specific tool being used to modify the image.

Conclusions

Modules I’m interested in modifying are outside the scope of direct Boot Guard “protection.” The system can run normally with them modified.
However:
A HP-specific PEI module, HP_BBUpdate runs at an early boot stage and prevents the boot from proceeding normally if it decides the image was modified.
The HP_BBUpdate module can be patched to allow normal boot under any circumstances.
But:
Any change to HP_BBUpdate results in it not being run at all due to some lower-level protection being in place

What Next

Figure out how to fool HP_BBUpdate BIOS was not modified without patching it
- or -
Find a way to disable the lower-level mechanism protecting HP_BBUpdate from being modified (is this the infamous Boot Guard already?)

I’m temporarily out of ideas, so I’d appreciate any help.

Outsyde · August 27, 2023, 1:48pm

Looking further into the boot process from the very beginning, I checked the SPI dump with MFIT, part of Intel’s CSME Tools, and unfortunately it’s all locked down:

Flash Settings → FPF Configuration → Hardware Binding: Enabled
Platform Protection → Boot Guard Configuration → Boot Guard Profile 5 - FVME

The interpretation, from a “confidential” Intel document for an earlier platform but this part doesn’t seem to have changed:

And there’s the key:

Platform Protection → Hash Key Configuration for Boot Guard / ISH → OEM Public Key Hash:

E2 A3 0D 7A CB 43 77 5C E5 34 31 02 51 56 B4 E9
DE 03 B9 61 18 B0 AE 8A 7B D6 FF 82 A6 E6 0D 34
79 A6 2F E0 47 62 9E 16 76 78 EB E1 5E B5 83 20

So unless HP’s matching private key leaks (as have some others), there’s no way of preventing the next stage, which means the following apply:

Intel Boot Guard Boot Policy (ACBP)
C30FFF4A-10C6-4C0F-A454-FD319BAF6CE6
Intel Boot Guard Key Manifest (KEYM)
7C9A98F8-2B2B-4027-8F16-F7D277D58025

And this binary will run, and there’s no way around it:

Authenticated Code Module (ACM)
6520F532-2A27-4195-B331-C0854683E0BA

The ACM format is publicly documented in the Intel Trusted Execution Technology Software Development Guide (PDF). Relevant excerpt:

Boot Guard 5 - Entry Point (1)

Boot Guard 6 - Entry Point (2)

So then the question is:
What does the ACM do on this system, and can anything be done about it without modifying it?

If anyone else wants to look at it, the files are here:

08A13_F.15_ACM_ACPB_KEYM.zip (73.1 KB)

This is on my to-do list.

Meanwhile, also in MFIT I noticed the following setting:

Platform Protection → Descriptor Configuration → Flash Descriptor Verification Enabled: No

Which means I should still be able to set the ME Alt-Disable Mode (aka High Assurance Platform, or HAP), and even unlock the descriptor, not that it changes much.

doggermithril · January 31, 2024, 3:25pm

I’ve been discovering a universal root kit in HP laptops since UEFI was introduced and it is always in DXEs for input devices and it’s usually i2chid 13KB or AmiI2cHid which is a newer DXE version that is only 7KB. You can find ample evidence on google and HP support forums with laptops that have disabled keys and trackpads. In my case it is much more severe affecting all other hardware like the ssd, wifi, bluetooth, usb ports and it even deletes the boot partition label occasionally. You probably already know all of this. Since it is not likely you can boot a modified image can the DXE at least be updated in some way or deleted?