So I was wondering how possible that is. I have already tested it for ME v7 with great results as you just have to copy-paste a part of the extracted ME region to create an update file usable with FWUpdLcl (check the Update section). After ME8 both ME Update images & extracted Regions can be used with FWUpdLcl so it doesn’t matter for such platforms. However, that’s not the case with ME v6.
I have extracted a ME region v6.1.20.1059 1.5MB but it’s useless unless converted to an update file. The question is how can this be done. I have found ME v6.0.3.1195 Update Image, Production Image & Extracted Region. So in theory if I compare these files I should be able to understand their differences. After searching I’ve come to these conclusions:
Production Image -> two $MN2 “sections” at 640KB each (MN2_Prod_1 & MN2_Prod_2 files) Extracted Region -> two $MN2 “sections” at 640KB each (MN2_Rgn_1 & MN2_Rgn_2 files) Update Image -> three $MN2 “sections” with the first at 9KB and the other two at 640KB each (MN2_Upd_0 & MN2_Upd_1 & MN2_Upd_2 files)
Guess what? The two $MN2 sections from Production,Region as well as the last two from Update are identical. Meaning:
So the only actual difference between the 3 files (production, update, region) is a small 9KB section (UPD header?) which I named MN2_Upd_0.
Now I wanted to check this “header”. I took another update file, ME v6.0.0.1184 and copied it’s header at Hdr_6.0.0.1184 file. Also renamed MN2_Upd_0 to Hdr_6.0.3.1195 for simplicity. I was hoping that the two header files would be identical except the offset after $MN2 which signifies the firmware version and is what the FWUpdLcl tool actually reports to the user. However, the two headers are not that similar. I removed all similar parts and was left with a ~1KB file which has the actual header differences.
The goal is to understand whether this header is important and if yes, then what does it signify. After that, it should be very easy to apply this to ME v6.1.20.1059 and create an Update image out of an extracted ME Region.
I have attached below the two 9KB ME Update headers, from v6.0.0.1184 and v6.0.3.1195. Can someone determine whether they are important or what do they mean? If you remove all identical parts and the $MN2 part with the offset that signifies the firmware version the result is this:
Can you upload to an external source (like mediafire or whatever) these group of ME images with same version? I need to do some reading first, but I can’t resist to check something new.
The story goes like this for $MN2 part: 0x80 header, 0x100 public key, 0x4 public exponent, 0x100 RSA signature. The rest is information about sections, but I haven’t yet dived into it. The thing is, if that section is not signed on its own and final image, there is no way to edit because of RSA. But it is possible that not all of them are needed for update file. Will have to read first.
Prod_6.0.3.1195.bin is a renamed PCH_4M_Production.bin file Upd_6.0.3.1195.bin is a renamed PCH_4M_UPD_Production.bin file RGN_6.0.3.1195.bin is the extracted ME Region from a BIOS image
I have cut some FF padding from the ME Region file to make it the same size as the Production image. Same file though.
Very interesting. So it makes sense that:
The Header (0x80) shows the different version so it’s slightly different The Public Key (0x100) is the same The Public Exponent (0x4) is the same The RSA signature (0x100) is of course different
The public key changes between different ME major versions. For example ME v7 has a different one than ME v6, ME v8 etc…
This shows the difference between the two RSA signatures.
Since some files have the same SHA-1 hash code, it is clear that each extracted $MN2 “region” (1 & 2) from all three files has the same RSA signature. That means that any ME update/production/region uses different RSA signatures for each $MN2 section. That also means that the “unique” 9KB UPD Header has it’s own RSA signature as well. So basically:
MN2_Prod_1 & MN2_Rgn_1 & MN2_Upd_1 → same RSA signature MN2_Prod_2 & MN2_Rgn_2 & MN2_Upd_2 → same RSA signature Hdr_6.0.3.1195 → unique RSA signature for the extra (1st from the top) $MN2 section that the update file exclusively has
Keep in mind that the way I named them, MN2_Upd_1 is the 2nd $MN2 and MN2_Upd_2 is the 3rd $MN2 section from the top of the UPD file. The 1st $MN2 is the one in question.
So I analysed further, by also taking 6.x 5M firmware in comparison, since we have many of those. It seems the first section has nothing to do with the firmware itself, rather it is a general update block, with basic info and signature, one for 1.5M and another for 5M. The good news is that it can be ported. We can take the first section from any 6.x 1.5M update image and patch it. This is the header, simple as it can be:
This is the rest of the info. The only thing not possible to update is the RSA signature.
And this is the bad news, there is no way to obtain it without a private key. What we can do is leave it as it is and see if FWUpdLcl complains and what message it prints. I can analyse further to see if I can skip this check, since this first RSA signature is needed only in the update process, the ME firmware is contained in the other 2 $MN2 sections.
One thing I forgot to add. Intel had a way to make an updated image from full ME, so there must be a tool that extracts MN2 sections from full image and adds a signed MN2 update section. Either this is a separate private tool, or it is a secret command in FWUpdLcl / FITC. Now back to topic.
Is anyone with a board that has 6.x 1.5M firmware willing to do some tests, no matter the risks? I have built two images:
- upd_6.1.20.1059-modnosig.bin is the update ME, but with older and invalid signature for MN2 update block. The actual ME is intact. - upd_6.1.20.1059-modsigpad.bin is the update ME, but with a valid signature, expect that it is signed with my own pair of public+private keys.
My take is that both images are harmless in nature, just that FWUpdLcl will print some error about invalid signature. But I’ve been wrong before, so full commitment to any risk involved is needed. I need a screenshot of that error to move along. The second image tries to test if the signature is tested only by reading public key. This would be a serious security violation from Intel side, but why not test it?
Thing is, in theory before ME8 the ME region could be corrupted and the system would still work. The BIOS was built to detect a corrupted ME and ignore it. That’s theoretic of course, haven’t tested it. I have a 5-series system but unfortunately it uses the ME Ignition firmware (0.2MB) since it’s a P55 chipset. So, I can’t be of any practical help here.
If someone has a Dual BIOS 5-series system (or programmer knowledge if he/she wants to be risky) then reply here to test Lordkag’s test files.
I did some tests on my own systems, primarily at my Z77 (ME8) and my HM65 (ME7). The ME8 FWUpdLcl tool definitely checks the signature and refuses to proceed if anything is wrong. I tested changing the date, version, private key etc and all failed with the same error at Stage 3.
The ME7 FWUpdLcl tool seems to check the signature as well, does not display any error but gets stuck at the beginning of the update at Stage 3. Maybe Stage 3 is the actual signature checking.
I think at some point I came across an old System Tools Guide from v2.x or v1.x that listed what all the Steps do (they have probably changed since then but it could be helpful). It listed the procedure, back then the guides were a little more detailed because the tools were in early stages and AMT was a rare occurrence.
According to Igor Skochinsky, this won’t work. Intel has hardcoded the public key to the bootrom of the ME processor and that’s what it checks every time to verify that no tampering has been done to the firmware or RSA signature.
Have you watched or read the pdf of his presentation regarding ME Secrets? It’s very interesting. He has also written a tool that uses Python and via it you can send commands to ME via the MEI driver. I haven’t managed to get it working on my system though, I don’t know why. I thought that this tool would be great for unlocking the descriptor via software by using the HMRFPO ENABLE command. HMRFPO is not FPT compatible but it would be useful for other things.
Actually, it is his tool, dump_me, that I was reading to find about ME stuff. His other tool is also interesting. I don’t know how he assembled all this knowledge, but it is something.
So, without private keys, we have no way to produce the image. But how did Intel produced the image, if not by some tool?
Intel uses a different public/private key for each ME generation so that even you manage to get one you will only be able to do something with it on that ME series only. They seem to have thought of everything, good for them I suppose. My guess would be that the private key is kept somewhere else, maybe a separate secret/confidential tool. Intel knows that OEMs leak the ME confidential packages all the time by accident or boredom so why would they include such a tool in there? Or maybe it’s a secret parameter/command at the available tools but again, they get leaked often so it would be risky to keep such a command in these packages.
