[SOLVED] "Unknown descriptor version: 7" when passing stock HP BIOS image

[WaseemAlkurdi]

Dear all,

I have a HP EliteBook Revolve 810 G2 laptop. I have attempted to disable Intel ME as described under (). However, I'm getting errors: First, running ifdtool on the stock HP BIOS image results in:

waseem@redacted:~/me_cleaner$ sudo ../coreboot/util/ifdtool/ifdtool -d ~/L86_0140.bin File /home/waseem/L86_0140.bin is 8388608 bytes Unknown descriptor version: 7

And intelmetool -b prints:

waseem@redacted:~/coreboot/util/intelmetool$ sudo ./intelmetool
Bad news, you have a `8 Series LPC Controller` so you have ME hardware on board and you can't control or disable it, continuing...

MEI found: [8086:9c3a] 8 Series HECI #0

ME Status   : 0x1e000245
ME Status 2 : 0x60002306

ME: FW Partition Table      : OK
ME: Bringup Loader Failure  : NO
ME: Firmware Init Complete  : YES
ME: Manufacturing Mode      : NO
ME: Boot Options Present    : NO
ME: Update In Progress      : NO
ME: Current Working State   : Normal
ME: Current Operation State : M0 with UMA
ME: Current Operation Mode  : Normal
ME: Error Code              : No Error
ME: Progress Phase          : Host Communication
ME: Power Management Event  : Clean Moff->Mx wake
ME: Progress Phase State    : Host communication established

ME: Extend SHA-256: a5f317b15d978d0d0066770953f9f03188e061d74292b92a137a4199d2df4139

ME: Firmware Version 9.5.1730.15 (code) 9.5.1730.15 (recovery) 9.5.1730.15 (fitc)

ME Capability: Full Network manageability                 : ON
ME Capability: Regular Network manageability              : OFF
ME Capability: Manageability                              : ON
ME Capability: Small business technology                  : OFF
ME Capability: Level III manageability                    : OFF
ME Capability: IntelR Anti-Theft (AT)                     : OFF
ME Capability: IntelR Capability Licensing Service (CLS)  : ON
ME Capability: IntelR Power Sharing Technology (MPC)      : OFF
ME Capability: ICC Over Clocking                          : ON
ME Capability: Protected Audio Video Path (PAVP)          : ON
ME Capability: IPV6                                       : ON
ME Capability: KVM Remote Control (KVM)                   : ON
ME Capability: Outbreak Containment Heuristic (OCH)       : OFF
ME Capability: Virtual LAN (VLAN)                         : ON
ME Capability: TLS                                        : ON
ME Capability: Wireless LAN (WLAN)                        : ON
Bad news, you have a `8 Series LPC Controller` so you have ME hardware on board and you can't control or disable it, continuing...

ME Capability: BootGuard                                  : OFF

Your system isn't bootguard ready. You can flash other firmware!

Running me_cleaner.py on the stock BIOS image results in very concise and very unhelpful output:

Unknown image

However, running this same command on the ME Firmware image obtained from HP Support and Drivers for my laptop results in some output. Edit: Some output, unlike what happened with this guy: https://github.com/corna/me_cleaner/issues/152 (see first comment)

I'm stranded on this ... Any help is greatly appreciated!

[persmule]

Where does your "stock HP BIOS image" come from?

me_cleaner.py can only work on images identical to what is dumped from rom chips, rather than "stock BIOS images" designed for vendor tools.

[WaseemAlkurdi]

The BIOS has a "backup existing BIOS" option. This image is from there.

[WaseemAlkurdi]

Can the BIOS ROM be dumped (and the patched image restored) from the system itself (a.k.a. without chip readers, as I don't have access to one)?

[persmule]

I don't believe your "backed up existing BIOS" is identical to the whole content of the flash chip. That's why me_cleaner.py correctly reported "unknown descriptor version" since it has no valid descriptor at all.

The chip needs nearly always to be manipulated with an external programmer, unless the existing firmware is a free-as-in-freedom one like coreboot (if so, the "internal" programmer could be used via flashrom(8).). Proprietary vendor firmware tends to have loads of restrictions preventing the end-user from accessing the whole chip.

[corna]

Can the BIOS ROM be dumped (and the patched image restored) from the system itself (a.k.a. without chip readers, as I don't have access to one)?

You can try with flashrom, in some (rare) cases there's free R/W access to the SPI chip

[WaseemAlkurdi]

@persmule How can I verify the descriptor myself? The Wiki says that the manufacturer of the motherboard (usually) provides a utility to convert the image into a standard format. HP, er, doesn't. The existing firmware is not at all free. Heck, there isn't even a standard BIOS maker's name (like AMI/Aptio//InsydeH2O/Award/....) anywhere, suggesting that this BIOS is HP's own sick-proprietary, almost-totally-undocumented brain-child.

@corna If flashrom fails, could I end up with a shiny aluminum paperweight without access to HP's Esc+Up+Down recovery method(*)? I have no access at all to an external SPI programmer, or otherwise, I would've already done it. (*) HP laptops have a method of recovering BIOS by loading an alternative UEFI firmware to flash a BIOS image from a USB. However, I don't know if that UEFI firmware is on a separate chip or on the same one, defying the purpose. Problem is that the flashrom README specifically warns:

Do not use flashrom on laptops! The embedded controller (EC) present in many
laptops interacts badly with any flash attempts and can brick your laptop
permanently.

And my laptop DOES have an EC (defined in DSDT under EC0). Is there a way to non-destructively check for R/W access to SPI flash?

Sorry for the really long comment, a sloppy habit of mine.

[persmule]

@WaseemAlkurdi Buy an external SPI programmer, even the cheapest but easiest-to-use ch341a, please.

Is there a way to non-destructively check for R/W access to SPI flash?

Just use flashrom(8) with "internal" programmer to probe the SPI flash, verbosely: # flashrom -p internal:laptop=force_I_want_a_brick -VV You are very likely to find that the ME region is not readable via "internal" programmer. That is why an external SPI programmer is nearly always needed to disable Intel ME.

Tools with adamant are necessary to repair porcelain.

[WaseemAlkurdi]

@persmule Not all people live in places where you have quality hardware shops. It is not a price issue, so why the prejudice xD? You might say eBay (which is how I bought this laptop) but shipping costs are insane for smaller items, not quite so for larger ones ($15 for shipping a laptop is reasonable, but $15 for a $5 item is quite not!) I'm a medical student at a (somewhat) quality institution ... Do you know of faculties where they use such things? (None at all ICT related ones, been there) I'll try with flashrom ... hope I'm of the 1% where it works! And thanks for all help!

[corna]

In general (but not always) reading with flashrom is safe: once you have the dump you can get the access permissions with ifdtool -d dump.bin. I highly suggest you to obtain an external programmer, using me_cleaner without a recovery solution is really dangerous.

[corna]

Note that any Linux board with a SPI interface (so, most of them) can be used as a programmer, so if you find a Raspberry Pi (or a Beaglebone, or a C.H.I.P., ...) you can use that. Just make sure that they match your PC's SPI voltage (3.3 V usually).

[WaseemAlkurdi]

@corna You said: "but not always". Does that mean that there is a realistic risk of bricking the laptop when reading the flash with flashrom? Or is it "just saying"? I think I could find a Raspberry Pi ... But one question remains: could I find out the SPI voltage with your average multimeter? Guess I'll have to dismantle the laptop then ...

[WaseemAlkurdi]

I really, really, really don't want to enter hardware/electronics in this ... I have near-zero experience with them ... Is it like 0% hope that something software can be done?

[corna]

Unfortunately the BIOS update download of your PC contains only the BIOS region, so I can't determine whether the regions are writeable.

You said: "but not always". Does that mean that there is a realistic risk of bricking the laptop when reading the flash with flashrom? Or is it "just saying"?

The brick is quite unlikely by reading only, however you should ask it to the flashrom guys.

But one question remains: could I find out the SPI voltage with your average multimeter?

Yes, the SPI chips have a common pinout, so you should be able to get it by measuring the voltage between pin 4 (GND) and pin 8 (VCC).

I really, really, really don't want to enter hardware/electronics in this ... I have near-zero experience with them ... Is it like 0% hope that something software can be done?

There's something like (rough estimate) 30% of chance that you can do this by software alone, but there's also a 20% that you'll brick your PC. Unbricking it with an external programmer is easy (I periodically brick+unbrick my PCs 3-4 times a week), it's up to you.

[WaseemAlkurdi]

@corna A really hearty thanks for all your help! You say that you brick your PCs 3-4 times a week ... so is the common "bricked the BIOS = motherboard swap" a myth?

[corna]

It depends on your definition of "bricking": in the BIOS/firmware world bricking means flashing an unbootable firmware, so you can't flash a new working one from software. However that's limited to the software flashing: if you have an alternative way to program the working firmware (and a working firmware, that's why you should do a backup beforehand), everything is ok, no need to buy a new motherboard.

Obviously, this doesn't cover the case where you break the hardware (like if you break the SPI chip by connecting it wrongly), but sometimes you can recover also from those by replacing the faulty piece.

[WaseemAlkurdi]

Exactly ... So to make sure I understood you properly:

1. Flashing an unbootable firmware to SPI (which can be an improperly patched BIOS - a BIOS for a different mobo - something from /dev/random or /dev/zero) is recoverable with a SPI flasher, unlike the popular belief of replacing the motherboard. This begs the question: why do people waste their money on a new motherboard in that case?
2. Breaking the chip while flashing it (by wrongly connecting, breaking pins, etc) is unrecoverable except if you replace the SPI chip. Am I correct? And how do I mark this as solved? This thread is definitely useful for posterity.

[corna]

1. Yes. I suppose the common belief of replacing the mb comes from the fact that people are usually uncomfortable by connecting external stuff to their hardware (plus SPI programmers are quite cheap today, but this wasn't true in the past).

2. Yes.

3. Breaking anything else: it depends on your hardware skills, everything could be repaired in theory ;)

And how do I mark this as solved? This thread is definitely useful for posterity.

Just click 'close', I'll link this thread in the other discussions. :)