The dumped ME region is corrupt so it cannot be properly parsed by FITC. In such cases, I advise people to look online for someone else’s dump from the same model, and use that ME region for cleaning instead.
Thx! Then I must wait on the dump of my brother in arms wdaniels 
Hopefully his ME region dump will not choke FITC
or can I do something with the ME Region, Stock image which I extracted from the Dell A22 BIOS Update? (See attached picture)|addpics|hck-7-0e16.jpg|/addpics|
I believe that file was an update image for fwupdate, of which an EFI variant will run during the BIOS update process, not a configured region. I will dump mine this friday, I didn’t have any time today. Since mine has less severe symptoms of breakage (basically slow boot and suspend problems), I have high hopes my dump wont be corrupt.
I plan on wiring up the chip to the SPI bus of a raspberry pi running flashrom and dump it like that. I will solder wires in place in stead of waiting for a clip which I will only use once. Once the FD is unlocked I can always service it (as long as it boots 
)
PS:
MEAnalyzer dump of the file extracted form the BIOS update:
File: section_5_9.5.61.3012.data
Family: ME
Version: 9.5.61.3012
Release: Production
Type: Region, Stock
SKU: 5MB
SVN: 1
VCN: 11
PV: Yes
Date: 2017-04-07
Size: 0x702000
Platform: LPT-LP
Latest: Yes
You cannot use the stock ME regions found inside the Dell HDR images as they have no OEM configuration. The whole point of the cleanup guide is to take an EXTR (configured) and clean it from any garbage. RGN don’t have any configuration so they are useless in this case, thus someone else’s dump is needed.
@wdaniels : looking forward to your dump. Soldering wires is less problematic than using the SOIC clip. I had a hard time until it finally recognized the chip ID.
I searched the net for other Dell 7130 dumps, but it appears we are the first ones who are doing this (not counting the Dell Depot service techs)
@plutomaniac : yup it’s now clear to me
Is there a possibility that some BIOS can initialize the ME OEM data region. I ask because some Dell 7130 users reported they could overcome similar problems after a CMOS reset followed by a BIOS upgrade?
And can stock firmware updates again lock the FD?
PS: I just read this. Is the HAP topic already discussed in one of the win-raid forums?
I have successfully dumped the BIOS with the raspberry pi. I am currently patching the FD. I could share it already, but I am not sure if my MEBx password is in there somewhere in plain text (bad programming practice so I assume not but you never know). Let me quickly reassemble and unprovision AMT, and I will give you a fresh dump with FPT.
PS: Good question about the automatic relocking of the FD. I was thinking about this as well yesterday, I know there are some security risks but I would like to leave it unlocked to fix future problems.
Excellent job! Would be nice if you can take a picture of your raspi and how you wired it with the bios chip. Prolly you have a similar setup as shown here. Did you add resistors and a capacitor as shown on the picture there?
I don’t understand the question. CMOS has nothing to do with ME. The latter can be re-initialized automatically via FPT “-greset” parameter or manually either by a shutdown (Consumer/1.5MB) or shutdown + ~1 minute power loss (Corporate/5MB). Generally, if a ME reset does not fix whatever problems it has, a reflash of its firmware is usually required to fix corruption or similar issues.
These two are not linked together. The FD locks are found at well…the Flash Descriptor whereas the ME firmware at the Engine region of the SPI chip. FWUpdate sends the update image to the ME which takes care of everything else by itself. General SPI chip flashers such as FPT work on the entire Engine region and flash whatever they are given so its firmware must be proper (configured/EXTR). Obviously they need read/write access to the Engine region to do that, meaning an unlocked FD. But updating just the ME does not imply anything about the FD lock state afterwards.
Not here but elsewhere among other places.
Sorry for not formulating my questions clear enough.
I try to reformulate the first question: do there exist BIOS-es which can reinitialize the ME DATA section, which includes the ME OEM data, or is that region provisioned by the OEM in factory and is under the sole supervision of the ME CODE section and BIOS has nothing to do with it?
The second question: can stock BIOS updaters, e.g. 7130vPro_A23.exe, which update EC, system BIOS, ME, OROMs, etc. cause a relock of the FD access control fields?
Something else is puzzling me: why does the Dell update engine not start when the ME file system is corrupted? When I execute a BIOS updater, e.g. 7130vPro_A23.exe, the system reboots straight into Windows, the update engine does not start.
The BIOS does not have read/write access to the ME region by itself. It can communicate with the ME via some of its modules. The DATA section of the ME is set at the manufacturing line by the OEM and generally speaking, the BIOS does not interfere. That can vary though depending on the OEM as the BIOS can be used sometimes to recover/reflash the ME region firmware when a problem is encountered. Some OEMs used to force a ME firmware downgrade for example when the user updated it manually via FWUpdate (dick move), others hold a copy of the DATA section at a BIOS module and use custom methods to repair it in case problems are encountered or similar (temporary FD unlock and reflash with no user intervention etc). But as I said, generally speaking, the BIOS cannot “re-initialize” the ME.
If “stock” updates hold a FD section which has the read/write access locked then yes, it can be the cause of a locked FD after the update. To this date, Dell hasn’t included FD sections at their HDR so their systems rely on the locks set at the manufacturing line. Even if an FD section is not included though, OEMs could easily for instance run an efi/dos/windows version of Flash Programming Tool and use “-closemnf” parameter to lock the FD if found unlocked. So as you can see, once again, it varies greatly depending on OEM implementations.
Hi all. I have dumped through FPTW64 successfully too. You can find the file here (this is an untouched dump). The cleaning process of the guide worked with a non-fatal warning on build about a setting and yielded an output image, but I couldn’t flash it back with FPTW64, it gave me the error “Error 280: Failed to disable write protection for the BIOS space!”.
I googled around a bit and there are ways around this, but in the worst case I will have to wire up the SPI chip again… Or maybe if I just rewrite the ME I don’t get the error. Anyway, it’s quite late here and that is something for tomorrow. I took some pictures of how I wired up the chip, I can share these as well tomorrow.
Good night!
EDIT: other people looking for a dump can download one here: https://www.dropbox.com/s/h93poxdeetf7z1…eneric.bin?dl=0 or here: http://people.cs.kuleuven.be/~wilfried.d…age_generic.bin
This is a cleaned dump based on A12, you can just flash it straight to the chip. If this gets your system working again, upgrade through Dell’s EXEs to A23 or later. It is better to do it like this rather than flash straight to A23, because other hardware with firmware/ROM will get upgrade along the way when using Dell’s EXEs.
Thanks for the dump, I will try it out later today. Concerning error 280, apparently it is an additional BIOS write protection and probably your best bet is to only write the ME region. To get rid of error 280 I found this: [PROBLEM] How to mod an Intel mainboard BIOS? (9)
Thanks for the info! I’ll try disabling it by modifying the Setup UEFI var. If all else fails I will have to rewire it, but I have already partially reassembled so I would like to avoid that.
Wilfried
I managed to disable the lock in software. Extracting IFR shows that the BIOS Lock parameter is at 0x75, just write 0x00 there and it will unlock.
Still have the double POST after reflashing, will keep investigating.
Offset 0x75 from the start of spi.bin?
I will start recovery of my tablet now.
No, no. Wdaniels meant that the BIOS Setup variable for locked BIOS is found at 0x75 (it’s not an offset from the start of the SPI the way you interpreted it). It would involve booting from an efi shell and typing something like “setup_var 0x75 00” or similar. I suggest you wait for wdaniels to explain.
There are a lot of ways to do it, but I used a patched grub from here. Reboot and load that EFI executable. The easiest is to just replace the windows bootx64.efi in the root of your ESP partition and select your SSD drive in the quickboot menu. This won’t break windows booting windows, it has a separate boot entry pointing to a duplicate in one of the subdirectories.
Anyway, once loaded just execute
1
setup_var 0x75
1
setup_var 0x75 0x00
@plutomanicac: I downloaded and cleaned wdaniel’s spi dump and can either flash the outimage.bin or the “ME Region-after-cleaning.bin” (size: 0x4CA000, does it need padding?) which I found in the FITC Decomp folder after doing step 14 of the cleaning guide. What do you recommend? (I unlocked bios write protection already as per wdaniel’s instructions)
PS: I should add my current corrupted ME is v9.5.60.1952 and wdaniel’s clean ME is v9.5.61.3012 and my BIOS is A22 and his A23
EDIT1: Flashed the entire image: IT WORKS ! Big thanks to wdaniels and plutomaniac for the fantastic help
EDIT2: @wdaniels : I do have that double POST as well, but I seem to remember I had that also before my problems started. The DELL logo appears first for about 2-3 seconds, then black screen for about 7-8 seconds and then DELL logo again with Windows boot spinner underneath
PS2: where is that BIOS setup variable physically stored?