from the same spec machine (name of INIPC160 if this matters) …
Intel (R) MEInfo Version: 12.0.70.1652 Copyright (C) 2005 - 2020, Intel Corporation. All rights reserved.
Windows OS Version : 10.0
LPC Device Id: A306. Platform: Cannonlake Platform General FW Information FW Status Register1: 0x94000245 FW Status Register2: 0x69000506 FW Status Register3: 0x00000030 FW Status Register4: 0x00004000 FW Status Register5: 0x00001F01 FW Status Register6: 0x47C00BC9
CurrentState: Normal ManufacturingMode: Disabled FlashPartition: Valid OperationalState: CM0 with UMA InitComplete: Complete BUPLoadState: Success ErrorCode: No Error ModeOfOperation: Normal SPI Flash Log: Not Present Phase: HOSTCOMM Module PhaseStatus: UNKNOWN ME File System Corrupted: No FPF and ME Config Status: Committed FW Capabilities value is 0x31119140 Feature enablement is 0x11119140 Platform type is 0x42000492
Platform Type Desktop FW Type Production Last ME Reset Reason Unknown BIOS boot State Post Boot Slot 1 Board Manufacturer 0x00001028 Slot 2 System Assembler 0x00000000 Slot 3 Reserved 0x00000000 Capability Licensing Service Enabled Local FWUpdate Enabled OEM ID 68853622-EED3-4E83-8A86-6CDE315F6B78 Integrated Sensor Hub Initial Power State Disabled Intel(R) PTT Supported Yes Intel(R) PTT initial power-up state Disabled OEM Tag 0x00 TLS Disabled
Intel(R) ME code versions: BIOS Version 1.3.4 MEBx Version 12.0.0.0010 Vendor ID 8086 FW Version 12.0.24.1314 H Corporate LMS Version Not Available MEI Driver Version 1904.12.0.1208 Wireless Hardware Version Not Available Wireless Driver Version Not Available
IUPs Information PMC FW Version 300.2.11.1020 LOCL FW Version 12.0.24.1314 WCOD FW Version 12.0.24.1314
PCH Information PCH Version 12 PCH Device ID A306 PCH Step Data B2 PCH SKU Type Production PRQ Revenue PCH Replacement State Disabled PCH Replacement Counter 0 PCH Unlocked State Disabled
Flash Information SPI Flash ID 1 Not Available SPI Flash ID 2 Not Available Host Read Access to ME Not Available Host Write Access to ME Not Available Host Read Access to EC Not Available Host Write Access to EC Not Available
FW Capabilities 0x31119140 Protect Audio Video Path - PRESENT/ENABLED Intel(R) Dynamic Application Loader - PRESENT/ENABLED Intel(R) Platform Trust Technology - PRESENT/DISABLED Service Advertisement & Discovery - NOT PRESENT Persistent RTC and Memory - PRESENT/ENABLED
End Of Manufacturing Post Manufacturing NVAR Config Enabled No HW Binding Enabled End of Manufacturing Enable Yes
Intel(R) Active Management Technology - Intel(R) AMT State Disabled M3 Autotest Enabled Localized Language English C-link Status Enabled AMT Global State Enabled Privacy/Security Level Default
Intel(R) Protected Audio Video Path Keybox Not Provisioned Attestation KeyBox Not Available EPID Group ID 0x28D3 Re-key needed False PAVP Supported Yes
Security Version Numbers Minimum Allowed Anti Rollback SVN 1 Image Anti Rollback SVN 4 Trusted Computing Base SVN 1
FW Supported FPFs FPF UEP ME FW *In Use — — ----- Enforcement Policy 0x03 0x03 0x03 EK Revoke State Not Revoked Not Revoked Not Revoked # Not Revoked=0, Revoked=1 PTT Enabled Enabled Enabled # Disabled=0, Enabled=1 OEM ID 0x00 0x00 0x00 OEM Key Manifest Present Not Present Not Present Not Present # Not Present=0, Present=1 OEM Platform ID 0x00 0x00 0x00 OEM Secure Boot Policy 0x3F9 0x3F9 0x3F9 CPU Debugging Enabled Enabled Enabled # Enabled=0, Disabled=1 BSP Initialization Enabled Enabled Enabled # Enabled=0, Disabled=1 Protect BIOS Environment Enabled Enabled Enabled # Disabled=0, Enabled=1 Measured Boot Enabled Enabled Enabled # Disabled=0, Enabled=1 Verified Boot Enabled Enabled Enabled # Disabled=0, Enabled=1 Key Manifest ID 0x0F 0x0F 0x0F Persistent PRTC Backup Power Enabled Enabled Enabled # Enabled=0, Disabled=1 RPMB Migration Done Disabled Disabled Disabled # Disabled=0, Enabled=1 SOC Config Lock Done Not Done Done # Not Done=0, Done=1 SPI Boot Source Enabled Enabled Enabled # Enabled=0, Disabled=1 TXT Supported Disabled Disabled Disabled # Disabled=0, Enabled=1
ACM SVN FPF 0x02 BSMM SVN FPF 0x00 KM SVN FPF 0x00 OEM Public Key Hash FPF 69602F34CC9D121ECB7785F4F5CA4153ADC35633FF13A76B914FB2FE2835F691 OEM Public Key Hash UEP 69602F34CC9D121ECB7785F4F5CA4153ADC35633FF13A76B914FB2FE2835F691 OEM Public Key Hash ME FW 69602F34CC9D121ECB7785F4F5CA4153ADC35633FF13A76B914FB2FE2835F691 PTT Lockout Override Counter FPF 0x00
Having now discovered the ‘UEIFTool’ I ran through the same proceedure as post 1 to make a new outimage.bin for Hydrogen. A copy is at http://www.damtp.cam.ac.uk/user/cm214/tm…ogen_remade.bin . In the UEIFTool it loads without the error I get with my ‘how to brick a PC’ .bin file. Is part of ‘what have we learnt from this post’ is that the resulting outimage.bin file should be loaded into UEFITool first before sending it to the BIOS?
This is what UEFITool shows in the ‘Parser’ tab for the hydrogen_remade.bin file:
1 2 3 4 5 6 7
FfsParser::parseIntelImage: unknown flash descriptor version 0.0 FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume's free space FfsParser::parseVendorHashFile: new AMI hash file found FfsParser::parsePadFileBody: non-UEFI data found in pad-file FfsParser::findFitRecursive: FIT table candidate found, but not referenced from the last VTF FfsParser::findFitRecursive: real FIT table found at physical address FFD20100h
@osk866 This isn’t consistent. This machine has a newer ME/PMC firmware and AMT/ TLS is disabled. Might be just updated, or another configuration?
I’m sorry, but it’s necessary to have: - a firmware dump of this specific machine, too, and - the value of the service tag of this specific machine, too (or a set of MEInfo -verbose, service tag value and SPI/Bios dump of the same specific machine)
You don’t happen to have these systems in China, France, Hong Kong, Israel, Korea, Poland, or Russia? (KVM should anyway be possible without TLS, and- just in case- without TPM chip, too)
Intel (R) MEInfo Version: 12.0.70.1652 … TLS Disabled … IUPs Information PMC FW Version 300.2.11.1020 LOCL FW Version 12.0.24.1314 WCOD FW Version 12.0.24.1314 … Intel(R) Active Management Technology - Intel(R) AMT State Disabled … AMT Global State Enabled …
╔════════════════════════════════════════════════╗ ║ hydrogen_original.bin (1/1) ║ ╟───────────────────────────────┬────────────────╢ ║ Family │ CSE ME ║ ╟───────────────────────────────┼────────────────╢ ║ Version │ 12.0.0.1069 ║ ╟───────────────────────────────┼────────────────╢ ╔═════════════════════════════════════════════╗ ║ Power Management Controller ║ ╟─────────────────────────────┬───────────────╢ ║ Family │ PMC ║ ╟─────────────────────────────┼───────────────╢ ║ Version │ 300.2.11.1011 ║
When I said I have 200 machines to enable AMT I should of explained that they are different models of Dell, they’re not the same as Hydrogen. There’s Optiplex 7010, 7040, 7060, 7070, 3070 and 9020’s. Are we going slightly of topic here with the MEInfo -verbose output the machine INIPC160? INIPC160 is a i5-8500 like Hydrogen, that’s why I chose that machine.
I can get a firmware dump of INIPC160 tomorrow but will this help me work out why the MEBx boot option wasn’t availableon HYDROGEN (sorry if I’m missing the link here)?
@osk866 It depends. Had this other PC been exactly the same then it had been inconsistent. If it’s another configuration it might just be that that one has AMT disabled.
The other thing is: What happened to your image?
UEFItooNE is a very fine tool for scanning images and new parser messages are always suspect. If you have a programmer and a good backup one might decide for oneself if time for hardware reflashing or exploring these messages is more important.
Service tag- I’m sorry, meant the sticker inside the chassis with the AMT code.
I still got some difficulties to reproduce your file…
- Why didn’t the first machine have AMT accessible even when all settings in ME from original bios dump are enabled and DELL sticker says ‘fully enabled’?
- For the second machine: Is MEInfo consistent with the ME sticker and settings in ME firmware? If yes can AMT enabled the ‘normal way’?
First question requires a programmer, since system is bricked. Starting point would anyway be flashing the original bios since it’s got all settings enabled.
Second question requires bios dump and info from sticker. If second machine has consistent information (sticker, MEInfo, firmware) and AMT can be enabled according to the book, everything is fine.
@plutomaniac Regarding settings for AMT/ clean ME- Do you have an idea why FIT v12 in its latest version no longer can write a correct FD version and changes order for ME boot and data partition?
Versions FIT 12.0.49.1536 Tools <= r25 FIT 12.0.64.1551 Tools >= r26 unknown FD version, changed partition order
This is consistent with the older ME/ PMC files from original image and also when exchanging with latest versions.
Would you prefer a version here? (I’d tend to making a ME region with latest tool and replacing it via UEFItool in original bios to keep FD?)
The location/offset of Boot (BPDT/IFWI) and Data ($FPT) partitions within CSE region do not matter, as long as they are correctly referenced/adjusted in CSE Layout Table. You can check these offsets via "MEA -dfpt" parameter but FIT does these things correctly by itself of course. You can ignore them.
The FD version does not matter. You can ignore it. TLDR, Intel added FD version at CNP (CSME 12) but originally it was set to 0.0 and later revised to the more sane one of 1.0. UEFITool does not understand value 0.0, which is the old/initial value.
This is a very good question, no idea why the MEBx boot menu was never visible. As the user needed the machine back and it was under warranty Dell are replacing the motherboard. While this ‘solves’ the problem it doesn’t answer why MEBx never showed.
This second machine (same chipset and CPU as hydrogen), called INIPC160, the ME sticker in the case says ‘3 ME Disabled’.
I load this image into FIT. Change the AMT settings:
Intel AMT Support = YES Intel ME Network Services Supported = YES KVM Redirection Supported = YES
Build menu -> Build Settings -> Generate Intermediate Files = NO
Save xml file.
Close FIT
Run MEA.exe on the inipc160_orignal.bin:
Family │ CSE ME ║ ╟───────────────────────────────┼────────────────╢ ║ Version │ 12.0.24.1314 ║ ╟───────────────────────────────┼────────────────╢ ║ Release │ Production ║ ╟───────────────────────────────┼────────────────╢ ║ Type │ Extracted ║ ╟───────────────────────────────┼────────────────╢ ║ SKU │ Corporate H ║ ╟───────────────────────────────┼────────────────╢ ║ Chipset │ CNP/CMP-H B,A ║ ╟───────────────────────────────┼────────────────╢ ║ TCB Security Version Number │ 1 ║ ╟───────────────────────────────┼────────────────╢ ║ ARB Security Version Number │ 4 ║ ╟───────────────────────────────┼────────────────╢ ║ Version Control Number │ 14 ║ ╟───────────────────────────────┼────────────────╢ ║ Production Ready │ Yes ║ ╟───────────────────────────────┼────────────────╢ ║ OEM Configuration │ No ║ ╟───────────────────────────────┼────────────────╢ ║ FWUpdate Support │ Impossible ║ ╟───────────────────────────────┼────────────────╢ ║ Date │ 2019-02-13 ║ ╟───────────────────────────────┼────────────────╢ ║ File System State │ Initialized ║ ╟───────────────────────────────┼────────────────╢ ║ Size │ 0x77C000 ║ ╟───────────────────────────────┼────────────────╢ ║ Flash Image Tool │ 12.0.0.1069 ║ ╟───────────────────────────────┼────────────────╢ ║ Latest │ No
From this information I chose the firmware file ‘12.0.24.1314_COR_H_BA_PRD_EXTR-Y.bin’ from ‘Intel CSME 12.0 Firmware Repository r24’ as it closest matches the version number and the SKU. Rename this file ‘ME Sub Partition.bin’ and copy it into '\Intel CSME System Tools v12 r28\Flash Image Tool\WIN32\inipc160\Decomp' overwritting the existing ME Sub Partition.bin (I notice they are a different size!)
Open FIT again, load saved xml, check settings for AMT, then run BUILD.
The resulting file is then loaded in UEFITool NE, no warnings. The output of the ‘Parser’ tab =
FfsParser::parseIntelImage: unknown flash descriptor version 0.0 FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space FfsParser::parseVendorHashFile: new AMI hash file found FfsParser::parsePadFileBody: non-UEFI data found in pad-file FfsParser::findFitRecursive: FIT table candidate found, but not referenced from the last VTF FfsParser::findFitRecursive: real FIT table found at physical address FFD20100h
I have not/dare not send the file to the BIOS until you’ve read and looked at what I’ve done. I really don’t want to brick another PC, my confidence level is very low at the moment.
As for what you were asking @plutomaniac about, way over my head I’m afraid, I’m beginning to get a bit lost with what’s going on so far, sorry.
Once again thanks for your help and patience with this.
@osk866 Procedure seems to be fine and if I use the same settings I get a bitwise identical file- but wait flashing it!
Regarding settings I’d recommend to use these settings:
Management Application Supported is necessary, the other marked settings would be standard for AMT enabled machines, too.
In addition for your other machines- you might check the TLS setting- last item in the AMT section (it’s already enabled for this machine).
About your fear for flashing- you have 199 machines to go, right? But the better argument is that you flashed a corrupted file that had an extremely high probability og bricking. So there’s a reason for what happened. Hope you ordered a programmer as insurance, when you have one at hand you’ll feel better at once.
Please change the other settings, build a new file and post/ attach it.
@lfb6 Thanks for checking and for the recommendations.
Something I have done and I should of possibly held off doing was that I upgraded the BIOS to the latest version available from Dell - boot PC, F12, update flash from USB stick. I thought while the flashing was taking place that maybe I should of waited but it’s done now. Hopefully it won’t mess anything up.
Family │ CSE ME ║ ╟─────────────────────────────┼───────────────╢ ║ Version │ 12.0.24.1314 ║ ╟─────────────────────────────┼───────────────╢ ║ Release │ Production ║ ╟─────────────────────────────┼───────────────╢ ║ Type │ Extracted ║ ╟─────────────────────────────┼───────────────╢ ║ SKU │ Corporate H ║ ╟─────────────────────────────┼───────────────╢ ║ Chipset │ CNP/CMP-H B,A ║ ╟─────────────────────────────┼───────────────╢ ║ TCB Security Version Number │ 1 ║ ╟─────────────────────────────┼───────────────╢ ║ ARB Security Version Number │ 4 ║ ╟─────────────────────────────┼───────────────╢ ║ Version Control Number │ 14 ║ ╟─────────────────────────────┼───────────────╢ ║ Production Ready │ Yes ║ ╟─────────────────────────────┼───────────────╢ ║ OEM Configuration │ No ║ ╟─────────────────────────────┼───────────────╢ ║ FWUpdate Support │ Impossible ║ ╟─────────────────────────────┼───────────────╢ ║ Date │ 2019-02-13 ║ ╟─────────────────────────────┼───────────────╢ ║ File System State │ Configured ║ ╟─────────────────────────────┼───────────────╢ ║ Size │ 0x77C000 ║ ╟─────────────────────────────┼───────────────╢ ║ Flash Image Tool │ 12.0.64.1551 ║ ╟─────────────────────────────┼───────────────╢ ║ Latest │ No
inipc160_new_bios_rename.bin loaded in UEFITool NE, no warnings. The output of the ‘Parser’ tab =
FfsParser::parseIntelImage: unknown flash descriptor version 0.0 FfsParser::parseVolumeNonUefiData: non-UEFI data found in volume’s free space FfsParser::parseVendorHashFile: new AMI hash file found FfsParser::parsePadFileBody: non-UEFI data found in pad-file FfsParser::findFitRecursive: FIT table candidate found, but not referenced from the last VTF FfsParser::findFitRecursive: real FIT table found at physical address FFD20100h
I wonder what you did, latest bios update contains ME update, too, and other stuff, see picture. And yes, the bios region is updated…
Anyway: I did the same modifications and got a bitwise identical file. I’d propose you flash this file the way you described before. Make a new dump right after flashing without rebooting. Please run a MEInfo -verbose after reboot / fptw64 -greset and poste it.
When the system is working fine, you might run the Dell installer for updating the whole package. And don’t worry, for ME this will not change the settings.
Is the moral of this thread that you should always look at the output of FIT (outimage.bin) using UEFITool to make sure it loads OK? Do we need to worry about what the Parser output says in UEFITool if the new bin file loads without error? I guess the question is when we use UEFITool and load outimage.bin, what do we look for to tell us NOT to flash the new .bin file, what should be look at to ring alarm bells that we’re about to brick the PC?
Thank you for all your help with this. I’ve learnt a bit more (a rather costly learning exercise mind you). Mainly the use of a new tool to me, UEFITool. thanks
@osk866 Thanks for reporting the result and good to hear that everything works now!
I really can’t tell what went wrong with the first build.
What you need or should do for checks depends your personal thirst for adventure/ need for safety and the consequences. If it’s your own system, you have a flasher at hand, are pretty sure you did it right and are eager to try- the worst thing that could happen ist diasassembling the machine, flash the backup, try again. If a customer is waiting for a machine one would possibly play more carefully.
To put the file into UEFItoolNE is a very simple measure to check for structure and parser errors. As written before, you can’t 100 % exclude a brick, but with severe errors or an unreadable file it’s quite likely a brick. I put most files in UEFItoolNE and MEA, sometimes MCE and somtimes I compare the files in HxD to check where to find first changes/ if changes are where they’re expected. In case you change something in ME region and find first discrepancy in bios region (like in your first file), I’d become suspicious.
When doing this first time it’s also possible to describe what one did, attach the file here and ask for a check before flashing. That’s normally less work/ writing than fixing a brick. (But would possibly not work so well for all your 199 machines )
Flushed with success I thought I’d try out the new UEFItool on a different model of Dell, Optiplex 7010. The output of UEFItool on the dumped image didn’t error in red and a warning, neither was it happy with the image. Let me explain.
New PC, INIPC204. Dell 7010 (out of warranty). Label in the case ‘ME Disabled 3’. BIOS version A29
Processor=Intel(R) Core™ i5-3470S CPU @ 2.90GHz Intel(R) 7 Series/C216 Chipset Family SATA AHCI Controller Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E2D Intel(R) 7 Series/C216 Chipset Family USB Enhanced Host Controller - 1E26 Intel(R) Q77 Express Chipset LPC Controller - 1E47 Intel(R) 7 Series/C216 Chipset Family SMBus Host Controller - 1E22
load into UEFITool.exe, Parser tab shows ‘MeParser::parseFptRegion: FPT partition table header checksum is invalid’ - doesn’t look good. Also, UEFITool.exe doesn’t show contents of the ‘Structure’ window in yellow.
I ran fptw64 -d three more times, same output in UEFITool.exe
Intel(R) Active Management Technology - NOT PRESENT Intel(R) Standard Manageability - NOT PRESENT
Output from ME Analyser on inipc204_original.bin
inipc204_original.bin (1/1) ║ ╟───────────────────────────────┬────────────────╢ ║ Family │ ME ║ ╟───────────────────────────────┼────────────────╢ ║ Version │ 8.1.72.3002 ║ ╟───────────────────────────────┼────────────────╢ ║ Release │ Production ║ ╟───────────────────────────────┼────────────────╢ ║ Type │ Extracted ║ ╟───────────────────────────────┼────────────────╢ ║ SKU │ 5MB ║ ╟───────────────────────────────┼────────────────╢ ║ Security Version Number │ 1 ║ ╟───────────────────────────────┼────────────────╢ ║ Version Control Number │ 4 ║ ╟───────────────────────────────┼────────────────╢ ║ Production Ready │ Yes ║ ╟───────────────────────────────┼────────────────╢ ║ Date │ 2017-10-24 ║ ╟───────────────────────────────┼────────────────╢ ║ Size │ 0x4A4000 ║ ╟───────────────────────────────┼────────────────╢ ║ Flash Image Tool │ 8.1.40.1416 ║ ╟───────────────────────────────┼────────────────╢ ║ Chipset Support │ CPT/PBG/PPT ║ ╟───────────────────────────────┼────────────────╢ ║ Latest │ Yes
Does it look like AMT isn’t possible on this motherboard even though the spec of this PC on the Intel website says vPro should be possible. I’m baseing this on that UEFItool doesn’t like the dumped image.
I’ve not gone any further with this PC - running FIT etc as it looks like it’s failed at the first hurdle.
There are always some specific recommendations for the different ME versions (but since you don’t want to clean ME firmware you don’t have to follow all steps always). For ME 8 it reads:
For ME 8 settings are named different, here you ‘disable’, so the answer is almost always "no"
And for disabling Anti-theft do the 2 mentioned changes in PCH strap 2 in addition!
- There may be some trouble with some (newer) SPI chips- some flash programs can’t read different chip-types correctly, read the post of @Lost_N_BIOS ( After reading BIOS chips, Dell Latitude 3510 won’t start ) I don’t know of any consistent and complete information source which program won’t read which chips, unfortunately…
- You might check with "fptw??.exe -fwsts" if the ME filesystem is corrupted before dumping. This will also display correct chipset of the system. Alternatively MEInfo -verbose does also display ME filesystem corruption, but I’m not sure if that’s true for older versions like ME8.
- Use the newer FIT version for this ME 8
- Colours in UEFItool: Regions covered by bootguard (can be disabled in menu ‘view’) No BootGuard- no colours
Thanks @lfb6 once again for your input. Sorry if I’m asking dumb questions here, as you can tell it’s all a bit new to me.
I thought I’d listed all of the spec for INIPC204 except I failed to add that I was using ME tools for v8, Intel ME System Tools v8 r3. I ran ‘\Intel ME System Tools v8 r3\Flash Programming Tool\Windows64\fptw64.exe -d’ to make the initial image. I knew I’d forget to include one piece of potentially useful piece of information
After reading your reply a few times I don’t think I understand why UEFITool.exe reports the dumped .bin file as invalid. Is the error ‘MeParser::parseFptRegion: FPT partition table header checksum is invalid’ something to worry about?
When you say
are you basing this on the fact that you can load the dumped .bin file in FIT? I’m trying to learn when an initial dumped image is not good, when you can’t use it to create a new .bin file that would be used to flash the BIOS.
Did you mean ‘MEInfoWin64.exe -fwsts’ when you said
@osk866 No problem with Intel ME System Tools v8 r3. If you’d have continued you’d have seen that there are two FIT versions included:
Use the newer one of the two.
I happen to know some Ivy Brigde bios that have a checksum error for the FPT partition table and they work just fine. This wont be of any concern. In addition: If you change settings and exchange ME region with a ‘blank’ ME from the repository the FPT partition table will be rebuild by FIT. And MEA is rather rigid and checks the ME regiosn very thoroughly but doesn’t give any warnings for both versions .
You can change the checksum to the correct value (FD), UEFItool_NE will read without any error. Then make the changes in FIT, replace ME region.bin, build, check the new image- and there’s your error again, checksum is again C0/wrong. It’s an error in the tool…
Being able to load a dump in FIT doesn’t mean too much. Don’t rely on that!
And yes, my fault, it’s as you state "MEInfoWin64.exe -fwsts"
EDIT For ME 9.1 you get the info regarding corruption either by “MEInfoWin64.exe -fwsts” or “MEInfoWin64.exe -verbose”, but I think you’ll have to try for different ME versions, syntax may change with ME versions.
@osk866 You see, it isn’t strict rules always… Regarding the FPT partition table checksum error in UefitoolNE, I think the error might be in UEFItool itself, maybe. At least FIT and MEA are on the same side here:
)
