Maybe since you can’t really mess that up without breaking the signature. Although it sounds stupid & unsafe. Maybe those "headers" (00 00 00 40) or close to them.
Edit: Those Reserved [0x4] would be ideal for that but they are all 0
Edit 2: Take bup for example, the compressed size should be 0x259800
One more thing on SPI pointers: ME has no access outside of ME region normally, and SPI flash is mapped to the way it’s last byte has 0xFFFFFFFF physical address (because FFFF:FFF0 is the predifined reset vector of any x86 CPU for years). I haven’t followed the discussion from the beginning and can’t add anything because of NDA, but cutting the wrong branches is allowed. 
Thank you CodeRush for the input.
Lordkag: Most probably that size is the uncompressed one. I tested both (via header size & by manually finding the end of section) and the image from the header size is always larger. I couldn’t figure it out where the compressed size is. Maybe at the .met of each section or the general FTPR $MN2 manifest. Enough progress for one day. 
ME11_Flag02.rar (1.19 MB)
Even those with flag 00 are compressed, by using LZMA. I can’t get them to extract with 7-zip or lzma, but they look like having an LZMA header. Those with flag 02 are using a custom compression, most likely Huffman. Since the LZMA has the uncompressed size in the header, it only needs the compressed size. I don’t know how Huffman works, but if it is reading the file bit by bit and traversing a Huffman tree, then filling a buffer (decompressed size) is a better idea then checking the compressed size.
I am struggling with Asrock automatic ME recovery feature previously described in the thread here and here. Unfortunately, from the discussion I am unable to figure out what should I patch in the BIOS file I uploaded here.
So far I have tried to update ME using software utility and patching the BIOS file following this guide. I used for patching ME 7.1.10.1065 extracted from one of Acer HM65 chipset notebooks as well as ME 8.1.40.1416 found here. In all cases I end up with the original 7.0.10.1203. Particularly upsetting is that this BIOS update was shared by Asrock technician via mail due to my finding of data corruption on HD writing. It solved the issue when only 8GB RAM is installed but still persists with 16GB RAM. Technician in one of mails blamed Intel management engine but when I tried to get help on 16GB issue he stopped responding. Hence my obsession with updating ME. thanks
For future reference:
Yes if you try to extract these the resulting .mod file is 0 bytes. Maybe it’s a custom LZMA compression. So 00 is default (LZMA) and 02 Huffman. What you said about Huffman makes perfect sense. Most probably the ME co-processor starts the decompression and keeps a buffer equal to the uncompressed size to not waste memory. As far as size is concerned, if the decompressed data is equal to the buffer size then everything went ok.
What is your ASRock motherboard model? Don’t use ME firmware extracted from other computers without changing settings with FITC or without making sure it’s valid for your system. When you say HD you mean HDD (hard drive)? I doubt ME has anything to do with that. Most probably faulty RST drivers or drive itself. Either way, I have neither the tools nor the knowledge to remove that ASRock protection mechanism. Lordkag may be able to help.
@shurik
The link to the mainboard page would have been better. You have Vision 3D Series (Sandy Bridge), I suppose? The problem is that they are not doing a direct version comparison, but rather a variable comparison, either with the version of ME backup (B3160739-1365-48A7-AECB-038652E2B528) or with the version stored elsewhere. I think I can patch it, as long as you take the risk of bricking your board.
One question: when you try to update the ME to 7.1.60.1193 and restart, what message do you see on the screen when re-flashing the backup? Is it "The firmware version is difference!" and "Start to update Intel ME firmware after counting down…" by any chance?
@ lordkag
Thanks for looking into that. The ASRock BIOS page is here . The BIOS I uploaded is the newer version shared by mail v1.10c. I tried to reupdate FW in Windows and DOS. In both cases after reboot I am getting “erasing firmware” message but after finishing update PC automatically reboots and I get the boot logo screen hiding messages as BIOS settings are getting reset. I clearly remember at some point during previous attempts settings were not reset and I got to see restore message with sort of ASCII squares to show progress. I will not brick the board as I have a separate BIOS chip for exercise. The original chip is on the shelf. If it does not work from the first try I would have to wait approx 2 weeks to get a new chip as the only source I found is in Germany and sipping to California takes at least 2 weeks.
@ plutomaniac
I do not know if it is ME but only BIOS update solved the original problem that was present with only 8GB RAM. Now it happens if I try to install 16GB. See the last more or less meaningful post from ASRock. After they just tried to get me to test more RAM manufacturers etc.
Support
To
CC TSD
Sep 6, 2012
The message is caused by ME broken.
We made special BIOS L1.10C to recovery Intel ME.
re-flash BIOS L1.10C to try first.
If the problem still cannot be solved, We can send you BIOS chip for
replacing.
ASRock America Support
-----Original Message-----
— On Fri, 8/17/12, wrote:
> From:
> Subject: Re: FW: Fw: RE: ASRock RMA E20429
> To: “Support”
> Cc: “TSD”
> Date: Friday, August 17, 2012, 3:23 PM Hi,
>
> Detection of the memory is not the problem. It has detected the extra
> RAM without any problem and worked well with one single exception. It
> brought back the problem I had with 1.10 version of BIOS that is hard
> drive writing data corruption. With 1.10c version and 8GB RAM
> everything works well. With 16GB it’s back. The way I test it is to
> create couple dozen gig split archive with parity set (e.g. using
> Multipar) on another
> PC. Corrupt a few files and move to Vision 3D then try to repair
> them.
> It will invariably fail. I believe you can test it with Patriot
> version of RAM and it would have same effect as Corsair RAM. If it
> does not I could order Patriot RAM as a fix.
>
> Thank you and have a nice week end,
This looks more and more like a BIOS issue and not ME but still, lordkag will help you bypass that firmware recovery measure. The 1.10c BIOS does not have a new ME firmware either way (unless they changed it’s dependencies which, if the problem persists, won’t get fixed after the actual ME firmware update either way). Maybe the new BIOS removed the firmware update protection? That’s what I understand from their reply.
You mentioned ME8, your HM65 chipset can only work with ME7 firmware. So the latest you can update to is 7.1.60.1193 1.5MB. Don’t try 8.1.40.1416, 8.1.52.1496 or anything like that.
In order to avoid using FITC and checking whether your Flash Descriptor is unlocked, it’s best to use FWUpdate after lordkag has modified the BIOS to remove the flashback protection. The BIOS images do have an unlocked flash descriptor (ME Analyzer, SPI row) but that doesn’t necessarily mean that the actual SPI is unlocked. If you want to check that, download the v7 System Tools and try to run fptw -d BIOS.bin. If it shows error 26 your FD is locked and the only way to update is by either using FWUpdate or a programmer.
@shurik
If you really want to be able to update ME, be warned that there is no safe way! If I don’t get the right place or all the necessary steps, you will either have a boot loop or a freeze during ME check. The good thing is that you have a backup chip, so you can revert to a working state by using BIOS hot swapping. You should research what it means, but here is the short version. You have a test chip and a backup chip, you use and flash the test chip. If something goes wrong and it is impossible to get to Instant Flash and flash the original BIOS file, you apply the hot swapping method. It means that you remove power, take the test chip out, put the backup chip, boot to BIOS or Windows, take out the backup chip (the content is already on the RAM) while the system is ON, put the test chip while the system is still ON, start BIOS flashing with the original BIOS file, shutdown when it is finished. You have to have a good grip, avoid metal tools, use rubber gloves to avoid static electricity.
Now comes to the methods:
- I’m not entirely sure, but I think that the check happens between the version of main ME and backup ME. I see the GUID of backup ME being loaded, the tag $MN2 is searched, the version is loaded, this gets compared with the main version. So it should be possible to replace both ME with the same version (FITC prepared) and prevent the reflash. The advantages are that this is a clean method, with the recovery process still in place. The disadvantages are a boot loop if I’m wrong (fixable with hot swapping or a programmer) and the fact that you are stuck with one version of ME.
- The second method is to ignore the comparison. The advantage is that you can have any ME version, the disadvantage is that you loose the ME recovery option. But I’m not yet decided on what to patch, if it should be the entire branch with the backup ME loading and verifying, or just the reflashing part when there is a version mismatch. This is where you come in to action, if you want this second method. I need you to be very specific on what you see on the screen when the ME is re-flashed by recovery. Do you see “Updating Intel ME Firmware…” followed by "(nr/nr) Erase - nr " + "(nr/nr) Write - nr " and “Done, reset system again after counting down…” ? Do you see the message “The current version of Intel ME firmware is x.x.x.x, backup is x.x.x.x” or is this part of BIOS menu setup? Do you see “The firmware version is difference!” + “Start to update Intel ME firmware after counting down…”? You should flash the official HM65MXM1.10 before testing this, because that one has more debug messages than the unofficial 1.10c. And check all the BIOS menus for the message “The current version of Intel ME firmware is…”, to know if it is always displayed or just during reflashing, to keep it or remove it.
If you can’t be specific, then I will have to take a guess and patch before those messages, because I think they are invoked only during ME reflash.
@lordkag
The message "The current version of Intel ME firmware is x.x.x.x, backup is x.x.x.x" is part of the normal boot process
The message "Updating Intel ME Firmware…" followed by "(nr/nr) Erase - nr " + "(nr/nr) Write - nr " appears when I restart PC following ME update using "fwupdlcl -f filename.bin"
after that system restarts and after I can only see the logo with messages being hidden behind it because BIOS resets to defaults and the default option is to show logo. Updating ME via patching BIOS file boots straight into logo. Logically the only remaining message you mention “The firmware version is difference!” must correspond to the restore procedure.
I would tend to prefer the second option giving me freedom to choose ME version. I also prefer the 1.10c unofficial BIOS as plutomaniac notes above the data corruption may not be related to Intel ME but some other BIOS function. I also googled BIOS hot swap and there are multiple detailed guides making me confident that I should be able to do it if push comes to shove.
@ plutomaniac
I did not look the ME version of the original BIOS. You may be right that the data corruption may be unrelated to ME in which case that HTPC may be stuck with only 8GB RAM. The ASRock support could be just a red herring. Nevertheless since this issue forced me to learn all the ME stuff I am now determined to update all family PC’s MEs.
Regarding updating to ME 8.1.40.1416 I read that I should not in change including in the first message of this thread but this HM65 motherboard BIOS update included this exact version of ME. Hence my attempt to use it.
ME 8.x on HM65 works after some amount of black magic, but as unsupported configuration, so if anything goes wrong with that Jetway board, Intel will say "you are on your own, guys".
That 1.10 BIOS for you board is based on old Aptio4 platform version with Rev1 volumes, and that platform can only use ME 7.x versions, so please stick with them if you want to brick your system.
Interesting, I didn’t know that. Back at 2012 it was said that laptop chipsets had some hardware limitations for not supporting ME8. So some HM65 can use IVB cpus?
Just a small correction. Also, regarding Revision I assume you are talking about this:
So unofficially ME8 (and thus IVB) can be a thing for HM65 as long as Rev >= 2 to my understanding. Usually though a firmware upgrade also requires newer dependencies like ME9.1 compared to 9.0 for desktop 8-series.
Not that I’m going to try it, just for the sake of knowledge.
@shurik
It is more clear now and I know what to patch. But make sure you know the hot swapping method, because I could be wrong.
@shurik
Here is the patched file. Take HM65MXM1.10c and replace AMITSE using the file inside the archive. If you use MMTool:
- open the file HM65MXM1.10c in MMTool Aptio.
- select the Replace tab
- scroll until you find module AMITSE with GUID B1DA0ADF-4F77-4070-A88E-BFFE1C60529A. It should be on index 2B.
- select AMITSE, browse for the file AMITSE_Mod.ffs, hit Replace button, Save Image as…
- if you use UEFITool instead of MMTool, search for AMITSE and use "Replace as is…" from right click menu, save image.
- flash this new image, let it do its thing with reboot or anything else, once completed shutdown the PC.
- try to boot, check all messages you see on screen.
- if you get a freeze or a boot loop, use hot swapping to repair the chip.
- if you can boot to Windows as usual, flash ME 7.1.52.1176_1.5MB firmware. Use this one because it is the last complete and clean image of ME 7.x 1.5MB.
- once it reboots, check if you have any freeze or boot loop. Check displaying messages.
- if you can boot to Windows with no problems, shutdown the PC. This is to finish ME update.
- boot, check the ME version from BIOS screen and with MEInfo.
- some of us had minor issues with 7.1.60.1193, so keep 7.1.52.1176_1.5MB for a few days, see how it goes, then you can update to 7.1.60.1193_1.5MB and see how that one works.
Report if you have any problems during flashing or if ME update works.
AMITSE_Mod.rar (135 KB)
As long as FWUpdLcl is used, this does not matter. For ME7 only UPD images can be used either way.
Forgot about that one. But I still recommend he tries with 7.1.52.1176_1.5MB first, only after a few days to move to 7.1.60.1193_1.5MB.
Awesome! I had myself mentally prepared to spend the week end perfecting BIOS hot swapping skills but everything worked like a charm. Now the boot message is ""The current version of Intel ME firmware is 7.1.52.1176, backup is 7.0.10.1203". On the other hand I tested my recovery parity set and it repaired successfully with 8GB RAM but still failed with 16GB. Plutomaniac was probably right the issue was not with ME.
What "minor issues" should I watch for before updating to 7.1.60.1193?
Makes sense, ME should have nothing to do with that. That ASRock assistant was just bored probably and didn’t know what to suggest.
You shouldn’t have an issue with 7.1.60.1193, I don’t remember someone ever reporting anything wrong with it. Use the latest FWUpdLcl v7.1.50.1166 from this thread. Even if something doesn’t go right, you can always do a BIOS hotswap either way to repair ME (provided that your flash descriptor is unlocked).
Updates:
Updated at ME System Tools v9.0: MEBx Release Notes from v9.0.0.0023 → v9.0.0.0024
Updated at ME System Tools v7.1: Flash Programming Tool(DOS) from v7.1.30.1139 → v7.1.50.1166
Updated at ME System Tools v7.1: Flash Programming Tool(Windows) from v7.1.30.1139 → v7.1.50.1166
Updated at ME System Tools v7.1: Flash Programming Tool(Windows64) from v7.1.30.1139 → v7.1.50.1166
Source: