Page 2 of 11
#16 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 02.05.2015 17:13

avatar

In this file there is a new TXE Firmware. I'm not sure if it is 1.25MB or not, but it is for a new platform, CherryView.

#17 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 02.05.2015 17:19

avatar

Hello lordkag,

Thank you for the report. I am aware of Braswell firmware. I took the liberty to remove the direct link (for now) to keep the open source alive. Hope you won't mind.



The structure of TXE 2.0 is exactly the same as 1.1 - nothing new like ME11 for Skylake-S. The $SKU is identical between TXE 1.0 1.25MB , TXE 1.1 1.375MB and TXE 2.0 1.375MB.

I can send you the files if you want via pm.

I'm updating 5 ME System Tools packages currently.

#18 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 02.05.2015 17:31

avatar

Are you sure it is Braswell? Because from this link, I see that CherryView it is linked to Cherry Trail and Broadwell. I know it is just Wiki and not Intel source, but I tend to believe it.

No worry about the link. Although, I don't think they will block the access, if they didn't do it by now. Still, better to be safe. I am almost amazed that SD is posting links to Realtek site with the credentials in plain text.

Without revealing too much source code, how can you tell it is 1.375MB, apart from the obvious chronology?

#19 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 02.05.2015 17:44

avatar

Zitat von lordkag im Beitrag #22
Are you sure it is Braswell? Because from this link, I see that CherryView it is linked to Cherry Trail and Broadwell. I know it is just Wiki and not Intel source, but I tend to believe it.
Braswell is the successor of Bay Trail M/D (Mobile/Desktop) whereas Cherry Trail is the successor of Bay Trail T (Tablets). Can we identify from what type of device these SPI images came from?



Zitat von lordkag im Beitrag #22
No worry about the link. Although, I don't think they will block the access, if they didn't do it by now. Still, better to be safe. I am almost amazed that SD is posting links to Realtek site with the credentials in plain text.

Yes, indeed. The ME11 firmware & drivers were kind of obvious too. Well, I guess it's best to poke the beast as little as possible.

Zitat von lordkag im Beitrag #22
Without revealing too much source code, how can you tell it is 1.375MB, apart from the obvious chronology?

Initially TXE 1.0 had two skus 3MB and 1.25MB. With 1.1 they decided to merge everything into one sku at 1.375MB. As I said, 1.25MB and 1.375MB have the same SKU. The same applies to 2.0 as far as I can see. Also, the size is clearly bigger that 1.25MB and almost the same as 1.375MB. It seems logical.

#20 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 02.05.2015 17:49

avatar

You are right. I searched for the board corresponding to the file and while I couldn't find it, I did found Pentium N3700, which is Braswell CPU.

#21 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 08.05.2015 22:47

avatar

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.

#22 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 09.05.2015 03:15

avatar

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.

#23 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 09.05.2015 20:48

avatar

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.

#24 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 10.05.2015 02:48

avatar

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.

#25 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 10.05.2015 13:56

avatar

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:

#26 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 10.05.2015 23:08

avatar

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

#27 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 10.05.2015 23:35

avatar

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.

#28 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 10.05.2015 23:47

avatar

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.

#29 RE: Intel Management & Trusted Execution Engine: Firmware Repository by plutomaniac 13.05.2015 15:57

avatar

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.

#30 RE: Intel Management & Trusted Execution Engine: Firmware Repository by lordkag 13.05.2015 21:25

avatar

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.

Xobor Forum Software von Xobor
Datenschutz