This post is specifically meant for the firmware of this thread! Don’t use it for other machines- you risk a brick! Other systems will have another structure, other addresses, other places where machine specific information is stored!
Checking an Intel NUC firmware- for the example in #3: This is bios 0070, a little harder to find, but softpediastill has DNi70070.bio
Open the bricked bios in UEFIToolNE:
Check the bios region, the first 2 volumes with identical GUID are NVRAM, the other 5 volumes are static, meaning they should be identical to the update file.
Open the update file (corresponding verion) in UEFIToolNE:
and open the tree:
Extract all the volumes from bios-/firmware- dump and from update file (right click- “extract as is”) and compare them one by one with the corresponding volume from the update file. They have to be a 100% identical (which they were for the bios used here). If they’re not identical, try to find out where the update stopped, find out which parts of the firmware already were updated, so that you can decide to which version you want to go to. The release notes will give you the necessary information which downgrade might be possible. Look for ME version and/ or mcodes if you’r unsure whch version this might be.
For example: IF the last UEFI volume in the dump was already updated, and the update process stopped in the second last volume- take these to volumes and replace them with the stock volumes from the update file of the old bios version. Use UEFITool025 or UEFITool028- replace as is.
(Volumes can be extracted from the update file “as is”, for raw files use "extract body"
So there are few other things that could be wrong: corrupt ME, corrupt NVRAM, corrupt flash decriptor. Corrupt GbE wouldn’t keep a machine from booting, normally.
ME can be cleaned as described in [Guide] Clean Dumped Intel Engine (CS)ME/(CS)TXE Regions with Data Initialization
NVRAM can be emptied easily- there are two NVRAMs in the beginning of bios region:
,
First picture shows beginning of NVRAM, in second picture look for the line ‘GUID store’, that’s the last part of the NVRAM, a list over all GUIDs built up bottom- up.
Some NUCs seem to have the machine specific informations stored in NVRAM, these should be kept (the GUID for the entries isn’t stored in the GUID store). In addition the default values need to be kept, too. For these models it’s safe to clear data after StdDefault and empty the GUID store for the GUIDs now no longer in use.
Save to delete:
Search for the start adddress of the first NVRAM entry after StdDefaults in UEFIToolNE, note it (here 0x8019F6)
Search for the start adddress of the next volume in UEFIToolNE. The last bytes before this next block is the GUID store, containing all the GUIDs of the NVRAM, one line one GUID, all blocks despite the last in reverse notation and all GUIDs written from bottom (=last line) up.
Start address of next volume or next padding is here 0x820000, since you want to keep the last line of the GUID store the block you want to empty/ fill with ‘FF’ ends at 0x81FFEF
Open the firmware image in an Hex editor (HxD for example), right click, ‘select block’, put in the start- address (0x8019F6) and of end- address (0x81FFEF)
Block should look like this:
Right click into the block, select ‘Fill selection’, change ‘00’ to ‘FF’, OK
Check the results: Open the modified file and view the first NVRAM entry. It should still show the 4 machine specific entries, the volume for the StdDefaults (with its own GUID store), followed by FreeSpace and then the GUID store of the NVRAM volume. Last line of the NVRAM volume contains only the GUID for the StdDefaults? Next volume starts same address as before? File size hasn’t changed?
Do this for the second NVRAM, too. Result should look like:
@REDHEAD93 : Since the static parts of your dump were a 100% identical with stock, i emptied NVRAM. This should give you a 100% fine stock bios region with machine specific data saved. If this doesn’t work, one could as mentioned clean the ME. Another rare thing: GbE starts at 0x1000, GbE information (MAC) is at 0x2000. Might be an Intel- ‘trick’?
This post is specifically meant for the firmware of this thread! Don’t use it for other machines- you risk a brick! Other systems will have another structure, other addresses, other places where machine specific information is stored!