Using the latest versions of ME Analyzer + Database, I have looked at the ME Firmwares I have. This is what was labelled as rare:
- 5.2.40.1037 was mistaken as 1.xx FW.
- 9.1.10.1005_1.5M update.ffs is not really a ME Firmware, but an update or such (there are 2 identical DESC+ME_cut, in fact), found in Intel. I know that Gigabyte is also using this type of ME recovery, with the descriptor and a small part of ME packed in a ffs. You probably already encountered this situation, so I’m not saying that you should support it in any way, but it is always best to have all kinds of test samples.
- the rest of the files are normal ME Firmwares.
These are only the Firmwares that were already uncompressed. I still have others packed in exe or archive, but chances are that you already have them. Still, I will make some time to compare them, sooner or later.
Thank you lordkag for the files and explanation. A lot of ME 5.x firmware were affected by the ME 1.x bug. The new check will never fail again, I should have tested that before 1.1.0 release. Anyway, 5.2.40.1037 was already at the repository/database and the rest of ME6, ME7 & TXE1 were added to the appropriate places. ME7 v1 and v2 were identical apart from the source system which was Q67 in one file and C206 on the other. No worries about the other firmware which are compressed etc, whenever you have time. 
Regarding FFS image, it’s indeed something unique. It has 2x (FD + FPT + part of FTPR region). I’ve no idea what it’s purpose but maybe it’s there to verify that the SPI ME image is the “proper” one based on the Recovery. The FTPR region included has it’s own signed $MN2 header and if that’s the same with SPI then the ME is untouched. Just an idea. Either way, based on the facts above (2 FPT & 2 FTPR), I have added detection of such EFI FFS extracted images alongside other bug fixes at the latest ME Analyzer v1.1.1 which can be found at it’s thread with database r12 included.
I have now finished comparing the remaining of the files. This is the content:
- 6.1.30.1074 from a file fw6_1_30_1074.exe, most likely this one.
- 6.2.20.1035 from a file fw6.2.20.1035.exe, probably from here.
- the other three from Station-Drivers packs, named as old.bin and saved before flashing.
Have you looked at Gigabyte type of recovery with the first 512KB of SPI in a ffs file? It is probably present in all 9 series boards, with DESC+GbE+ME_Cut being stored in GUID 821D110C-D0A3-4CF7-AEF3-E28088491704. Here is a sample file.
No I did not know about the Gigabyte FFS modules. I looked into them a little bit. They are always after MERecoveryDxe module and as you said it’s GUID + first 512KB of SPI image meaning FD + GbE + ME_cut. My previous theory regarding checking whether the SPI ME is untouched was clearly wrong. Although it could be a thing for 1.5MB it’s not valid for 5MB extracted FFS modules. The FTPR region of 5MB (first $MN2) starts well after the 512KB mark (even without the inclusion of FD & GbE before it). So if you extract the FFS module of a ME 5MB SPI image, the resulting file will show nothing at ME Analyzer as there is no $MN2 at the first 512 (-FD - GbE) kilobytes. I tested this on a Gigabyte B85 SPI image with ME 9.0 inside. GUID is the same of course. Apart from Gigabyte (GUID 821D110C-D0A3-4CF7-AEF3-E28088491704), have you found other manufacturers with a similar module? From where is the other module with the 2 FPT and the 2 FTPR for example?
Attached is a non-public release of ME Analyzer v1.1.2 with Gigabyte FFS Module support and DB r13 based on the firmware you provided above. I discovered today that surprisingly the repository has a very-very small number of UPD images after ME7. For example, the ME 8.1.52.1496 UPD image was created by my system today. I don’t even have the latest versions of 9.0, 9.1, 9.5 & 10.0. Never noticed it until now.
ME Analyzer v1.1.2 Partial.rar (28.6 KB)
It is for recovery purpose, but not really a trusted solution, be it 1.5MB or 5MB. Probably they count more on the fact that this file has the Flash Descriptor and the FPT header of ME Firmware, just to check the validity of SPI content, not a true recovery solution. As a proper recovery, we have Asrock with its ME backup, just that they decided to go on the dark side and lock the user to a specific ME version. But since Gigabyte already has Dual BIOS and unlocked descriptor, I don’t know the purpose of this small file.
The other file comes from Intel most likely, since they use this special packaging in .BIO files. You can use this link or this one to check for similar files. No other OEMs use this method. Asrock’s ME backup is not part of this list, because it is a full ME, just the container it is different - ME region vs ffs file.
For the ME update files after 7.x, while it is not important for end users, it is rather difficult to gather these images for repository. Without users saving their old firmware, is there any way to find them?
I think there is a small error in this 1.1.2 version:
@Fernando
If I’m not mistaken you have a ME9.1 and ME10.0 system. Can you provide us with two UPD images from those systems? You need FWUpdLcl -save command for this.
@lordkag
As you said, it’s a lot more likely that they use these for FPT comparison and not actual code. I know about Intel bioses, I check their site with BIOS keyword often. How did you extract such an .ffs from Intel .BIO images? I tried PhoenixTool and UEFIExtract but couldn’t get to it after a lot of searching.
Either way, I saw at the file you posted above that the GUID is the same as Gigabyte’s so that made ME Analyzer integration a little easier. Attached below are the tested .ffs modules as well as ME Analyzer v1.1.3 which now supports detection of Gigabyte, Intel and Unknown OEM MERecovery GUID. I also fixed the ffs_warn error and bundled it with DB r14 which has a small name fix (more below). This is how it looks like:
Regarding UPD images, since neither Intel nor OEMs release them after the ME7 days I thought that the only way to get them was via FWUpdLcl -save command. However, after some small research I discovered today that ME8, ME9.0 & ME9.5 can be cut after FTPR and create UPD images easily. As we both know ME6 used a small $MN2 extra header to sign the UPD image so it’s not possible there and ME7 can be cut easily after FTPR. I don’t know about ME9.1 and ME10.0 because I don’t have an UPD image sample to test. It’s important to note that the cutting must be done after FTPR and not at the first $MN2 section. This last detail is crucial for ME8 which has an $MN2-headed MDMV region before FTPR.
EDIT: ME8 is kind of an exception, UPD images can be created manually but it’s kind of a hassle. You have to cut after FTPR and add MDMV to the end as well.
I randomly opened firmware 9.1.0.1110 in the hex editor and saw this:
Seriously Clevo? This was found at their latest SPI image for W35xSSQ/W37xSS Series. How many systems have they bricked for being careless, I wonder. Anyway, this extracted image turned out to be EXTR after all so I updated the DB to r14 to address that. Obviously the previous firmware will show as “rare” at ME Analyzer when loaded but it doesn’t matter if it’s corrupted. I have attached the fixed image below for now.
EDIT: It won’t brick systems. The fash descriptor points to 0x1000 for ME starting offset so in theory it’s ok. Not that it makes sense being there.
9.1.0.1110_1.5MB_PRD_EXTR.rar (1.01 MB)
ME Analyzer v1.1.3 Partial.rar (28.7 KB)
MERecovery_FFS_Tests.rar (362 KB)
Having the same GUID as Gigabyte makes me think if that file is indeed from Intel. I know that it comes from a BIOS file that uses the same packaging as Intel .BIO files, but which one? Anyway, for extraction I used UEFIExtract using the wrapper UEFIExtract.bat/py from #Extractor.
That’s right, we discussed this before about ME update files, at that thread about signing a ME6 update file. But wasn’t it a problem with such cutting? Don’t know if I’m imagining, but there is a little memory bookmark that it is telling me there was a little difference between the cut and the actual ME update. Still, will have to actually compare the files before making a statement.
You know, I actually looked at the Clevo screen for seconds, trying to figure out where the problem is. I was almost about to ask you about it, then I saw the double header.
Yes the GUID is the same but the structure is different. That’s how ME Analyzer tells them apart. One has GbE (Gigabyte) at 512KB whereas the other (Intel) does not (filled with padding where it should have been) but everything is doubled at a size of 1MB. So it would seem like the Intel ffs is two times the Gigabyte one minus GbE. Maybe GbE is missing because that SPI image came from a non-GbE system. To test that we need to find a non-GbE Gigabyte BIOS. Shouldn’t be hard. If I’m right I’ll have to rewrite that ME Analyzer code.
Regarding the cutting, are you referring to ME6? ME6 can be cut after FTPR again but they used an extra $MN2 header of 4KB at the top which holds the signature and could only be created by some special Intel tool that we don’t have. ME6 is a lost cause. Good news is that I finally found a “newer” 1.5MB UPD image recently (6.0.3 → 6.0.40). But everything else after that should be just fine. Apart from ME7 which I already knew it could be cut and ME9.1 & ME10.0 for which I do now currently have UPD samples, I tested ME8, ME9.0 and ME9.5. The resulting UPD images were identical with the ones FWUpdate made with a slight size difference which is normal due to extra padding.
Ha-ha, yes. That’s why I added the red box you know! 
I’ve no idea how they did that and how they haven’t realized that it can brick consumer systems. Maybe that’s why they don’t release BIOS updates publicly, they know how often they mess up. They probably use hex editors to update the ME and that’s how this happened.
If anyone has a 1.5MB system with ME9.1 or ME10.0, can you create an UPD image using FWUpdLcl -save command?
If anyone has a 5MB system with ME8 or ME9.0 or ME9.1 or ME9.5 or ME10.0, can you create an UPD image using FWUpdLcl -save command?
Warning: Do not use the images 9.1.0.1110_1.5MB_PRD_RGN , 9.0.20.1427_1.5MB_PRD_RGN and 9.0.20.1447_1.5MB_PRD_RGN from the current 9.0 and 9.1 repositories as they are “corrupted” and need to be re-uploaded. Not that I except anyone to use such old releases but just to be on the safe side.
@ Lordkag or anyone else interested
MERecovery FFS Modules: I was right, GbE exists only on systems that utilize an Intel Gigabit Controller. It’s not something Gigabyte-specific as I initially thought. I also found such GUID modules where their size was not enough to hold an $MN2 region and thus ME Analyzer did not report anything, not even that they were FFS. So I had to rewrite some parts of the code. There is no more OEM-based analysis (Intel or Gigabyte) and all irrelevant to FFS information is not shown (SVN/VCN, Region/UPD, PRD/PRE/BYP etc). Now, regarding the MERecovery FFS Modules there are two methods of analysis at ME Analyzer v1.1.4.
If $MN2 and GUID exists, the image is analysed to show Type, Version, Release & GUID:
If $MN2 is missing but the GUID exists, the image cannot be analyzed but the fact that it’s an FFS MERecovery Module is shown via Release followed by the detected GUID:
The extracted FFS Modules obviously have the GUID header at the first 0x10 bytes and this is where ME Analyzer only searches for it. Thus, there will be no false-positives with full SPI images where the GUID can be found at some point inside the file’s contents.
Clevo MERecovery Feature: Turns out there is a hidden Aptio option which allows updating the ME from inside the BIOS by loading an UPD/RGN (not sure about UPD) via USB like the regular BIOS update. The SPI images that Clevo releases seem to include a double FPT header of it’s first 0x100 bytes for Recovery purposes in case of something goes wrong during the flash procedure. How it works, why it’s only the first 0x100 etc I don’t know. The only difference between those first 0x100 bytes is the inclusion of FITC version and a fixed FPT checksum for the latter.
Initially I mentioned that such SPI images could lead to bricks but after a more careful look I saw that those 0x100 bytes are right before the start of the ME region as dictated by the Flash Descriptor limits. For example F00 - FFF for the “recovery” $FPT (0x100) and 1000 + 17F000 for the actual ME Region image. As far as cutting is concerned, I think Lordkag’s Extractor uses the Upper and Lower Flash Descriptor limits to determine where the ME starts and ends and after that it’s cut to 1.5MB from the regular 2MB full padded size. So this additional double $FPT header detection might not be required for that utility.
Anyway, ME Analyzer v1.1.4 can now detect double (cut) FPT headers and automatically choose the proper one which for the Clevo SPI images it’s the second.
ME 8.x-10.x UPD Cutting: My hypothesis that cutting after FTPR was right for ME 9 and up. However, ME8 had the MDMV region before FTPR unlike it’s successors. So in order to create UPD images you have to cut after FTPR and then manually add MDMV at the end of the resulting image. So yes, it’s very much possible. Just kind of a hassle.
Based on the above, I manually made UPD images for 1.5MB ME9.0 and ME9.5 systems. Since I don’t have UPD images from ME9.1 and ME10.0 systems, I cannot cut without making sure that everything went properly based on a FWUpdLcl - made UPD sample images. Also, I don’t have any 5MB UPD samples so those cannot be cut yet as well.
MERecovery_FFS_GUID_Samples.rar (576 KB)
MERecovery_FPT_Clevo_Sample.rar (2.95 MB)
Ah, this is what you were saying with Gigabyte and GbE region. I didn’t realized it at the time, for I would have said something. This is the reason Extractor is saving the GbE region as [Ven-Dev] Intel GbE Lan Firmware [vers].bin, because it is Intel only. You can also find it in ME packs in Image Components -> GbE. Besides, the Intel regions related code is from UEFITool, so if something is wrong you know whom to blaim. (CodeRush, don’t shoot the joke messenger!)
I see that you found that doubled ffs and others. I hope it wasn’t too much wasted time, we both learned new things.
It is interesting that Clevo is placing this backup header inside the DESC region. I wonder if it is Intel idea or their one, I also wonder what happens when there is a GbE region present.
My English failed me back there and now that I read it again, makes sense. I knew what GbE was even though I don’t know specifics since I never had a system with Intel Gigabit (only JMicron, Atheros and others). I have been seeing them inside the ME packages for quite some time now. I’ve always wondered whether I should be keeping those but I haven’t researched such firmware and don’t know whether it’s updated often, what versions are out there etc. I vaguely remember something like GbE 0.13 and 0.15 or similar. Anyway, what I meant was: I thought that all the Gigabyte FFS Modules included the GbE section even if they did not have an Intel GbE compatible controller. Obviously that was wrong and now that I think about it, it never really made sense in the first place. Ha,ha… 
Yeap, I think CodeRush is off the hook for now. No cardinal mistakes so far!
No it wasn’t a waste of time. We learned some new things and now any tools will be more feature-rich. Regarding Clevo SPI images, why would there be an issue if GbE was present?
Regarding the Clevo matter, you can see that the recovery FPT header is not part of the ME region, but rather of the previous one, which in the case of the sample you uploaded is Descriptor region. So, when a Clevo system has a GbE region, where is this recovery FPT header placed: in the GbE fimware (which is weird, to say the least) or in the Descriptor region, separated from the ME entirely?
And is this placement of a recovery FPT header in the descriptor an Intel thing or a Clevo thing?
Note 1: Intel ME 11.0 Firmware Repository Pack was temporarily removed. When all 4 SKUs are identifiable, it will be updated & uploaded again.
Note 2: Intel ME 9.6 Firmware Repository Pack was permanently removed. The 9.6.0.1038 firmware can be found at the Other folder of ME 9.5 Pack.
Note 3: All UPD images from ME8 and up were permanently removed. ME Analyzer will be updated in the future to ignore them if the RGN/EXTR is there.
Oh this is 1.5MB! Finally! We will be able to update to something latter than the ancient 6.0.40 version that I had found some months back. It also includes the 5MB UPD image as well which will be added to the repository only since we have a newer available. But it’s good news for ME6 1.5MB users. Not the latest version but at least not ancient.
Thank you bin456789, will update the ME thread soon.
Hello 
Here is Intel TXE FW 2.0.2.3094 1.375MB Region, 13/10/2015
TXE_2.0.2.3094_1.375MB_RGN.zip (821 KB)
It seems like the link for Intel ME 9.5 Firmware Repository Pack r11 no longer available, could you please upload it again? thanks