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:

MN2_Prod_1 = MN2_Rgn_1 = MN2_Upd_1
MN2_Prod_2 = MN2_Rgn_2 = MN2_Upd_2

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:

Yes of course.

http://www.mediafire.com/download/xxk1vs....1195_tests.rar

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.

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.

Zitat von lordkag im Beitrag #5

---

- 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.

---

I am actually talking about these tools (me_unpack.py & me_util.py):

https://github.com/skochinsky/me-tools

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.

Btw, you might be interested in ME v9.6...