search

SuperThunder / HP_Z420_Z620_Z820_BootBlock_Upgrade

A guide and collection of resources on how to make 'version 1' HP Z420, Z620, and Z820 workstations compatible with Ivy Bridge processors.
MIT License
43 stars 7 forks source link

FPT alternative software method fails #3

Open jerrywoohu opened 4 years ago

jerrywoohu commented 4 years ago

Thanks for the thorough write up! I'd like to add some data points and see if there's any more guidance on the software only method.

System Info:

Current behavior: FPT software method fails to flash modified BIOS

Steps to reproduce:

  1. Disable AMT, move E1 to bottom 2 pins, and bridge E14
  2. Dump BIOS using FPT.EXE -D ORIG.BIN
  3. Immediately reflash unmodified BIOS using FPT.EXE -F ORIG.BIN as a sanity check 
    
Intel (R) Flash Programming Tool. Version:  8.1.60.1561
Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) Patsburg Chipset - Reserved DID 0x1D41 Reading HSFSTS register... Flash Descriptor: Valid

--- Flash Devices Found ---
W25Q128BV    ID:0xEF4018    Size: 16384KB (131072Kb)

FPT Operation Passed

5. Modify BIOS using HxD (checked in UEFITool)
6. Flash modified BIOS using `FPT.EXE -F MODIFIED.BIN`

Intel (R) Flash Programming Tool. Version: 8.1.60.1561 Copyright (c) 2007 - 2014, Intel Corporation. All rights reserved.

Platform: Intel(R) Patsburg Chipset - Reserved DID 0x1D41 Reading HSFSTS register... Flash Descriptor: Valid

--- Flash Devices Found ---
W25Q128BV    ID:0xEF4018    Size: 16384KB (131072Kb)

Error 7: Hardware sequencing failed. Make sure that you have access to target flash area! Trying to erase the same block (iteration: 2)

Error 7: Hardware sequencing failed. Make sure that you have access to target flash area! Trying to erase the same block (iteration: 3)

Error 7: Hardware sequencing failed. Make sure that you have access to target flash area! Failed to erase this block 3 times!!


The tool successfully flashes the unmodified BIOS but rejects the modified BIOS.

**Methods that also fail:**
- Flashing modified BIOS region only (11200KB) `fptw64.exe -BIOS -F BIOS2.BIN`
- E1 and E14 in all different combinations and positions (none of the other combos allowed reflashing original unmodified BIOS, I could only do it with bridged E14 and E1 in lower position).
    - Error codes varied, but no other combo even reached the `Reading Flash [0x1000000]` step of the flash
- Flash with green jumper removed.
- Flashing in FreeDOS and Windows 10 results in same error.

**Other data points:**
1. Dumping and reflashing the unmodified the BIOS in FreeDOS and Windows 10 works until you reboot. You cannot reflash your unmodified BIOS file using DFT after you have rebooted. (Error 7)
2. Dumping the BIOS, rebooting, and dumping again results in BIOS files with different MD5 hashes in FreeDOS and Windows 10.
3. Using SP82644, I was only able to upgrade to ME 8.1.72 with AMT enabled in BIOS, E1 in the upper position, and E14 unbridged.
SuperThunder commented 4 years ago

I had some issues with software flashing as well, when I was testing ME v7 to v8 upgrades. As you have excellently documented, the full BIOS can be dumped, and (not?) flashed if unchanged, but won't flash if there are changes. It seems I foolishly only tested flashing of an unmodified BIOS when I was writing the bootblock upgrade part of the guide.

Looking through my notes I have references to forum posts with some stating that using E14 allowed writing to 0xFF0000 - 0xFFFFF (bootblock region) and some stating they still could not write to that region. It would be very odd if HP designed in a boot block protection override header that didn't work.

We even have an HP employee that said "Installing a jumper on E14 overrides the system ROM boot block protection circuit".

Perhaps E14 allows reading of the BB region but not writing?

There was a small reference to NIST security requirements in one HP thread which seems to be related to documents like this one (see 2.3 3.3 3.4) that basically say "The way the BIOS is verified and/or updated must not be modifiable". Perhaps the PCH (Intel chipset) on the motherboard literally does not allow any writes to the boot block region, even with E14 enabled.

"A system component may have read access to system flash memory, but it shall not be able to directly modify the RTU unless that component serves as an extension to the RTU or as an RTU itself."

I imagine Intel may have interpreted that as never allowing writes to the boot block.

Amusingly, we are considered "rogue administrators" by that document.

Unfortunately I have no further suggestions for what you can do other than using a hardware programming method of some kind. I'm too busy with school at the moment to investigate this, but I've left some notes and lines of inquiry below. When my current set of exams are done I'll update the guide with your findings and clarify the difficulty of writing the BB region in software.

My notes on software flashing (from February, not recorded in guide)

I ran out of time before I could figure it out, but I have some notes that agree with yours: (with E14 and ME/AMT overrides on)

Flashrom Notes on internal programming

There are some hints in the flashrom docs about motherboard-specific problems: https://linux.die.net/man/8/flashrom see "Board Enable"

Looking through flashrom -L,

Supported devices for the internal programmer: Vendor Chipset PCI IDs Status .......300 other chipsets...... Intel C60x/X79 8086:1d40 Config-dependent Intel C60x/X79 8086:1d41 Config-dependent

I couldn't find anything further on what makes C60x/X79 config dependent. One person seemed to have a gigabyte x79 motherboard they could freely read and write.

However given the both FPT and flashrom run into issues, I would guess the issue is that some kind of protection is remaining on the boot block.

Future test items

jerrywoohu commented 4 years ago

Thanks for the guidance, I'll keep looking into it. My suspicion is the region is not actually writable despite being reported as writable. I haven't seen any evidence of anyone successfully writing modified data to the region.

I went ahead and tracked the diff in the dumps between 3 reboots using HxD, and it looks like the only region that changes is entirely within the "Padding" area of the BIOS region that starts at 510000h. The data looks like NVRAM data or a log since I am able to see entries such as PreviousBoot Boot Microsoft EFI boot from EFI system partition (which is from rEFInd bootloader on my system).

On each reboot the previous data in this region is mostly unchanged (some random bytes increment or decrement by 1), but another chunk of data is added (which makes it seem more like a log to me). Not sure if this region is of any importance as it's labeled as "Padding" by UEFITool.

Anyway, good luck with your exams, hope everything goes well!

bibikalka1 commented 3 months ago

@jerrywoohu Software only method: https://github.com/SuperThunder/HP_Z420_Z620_Z820_BootBlock_Upgrade/issues/12