Yes, I never thought to check before trying the flash? 
I now have error 28 which I understand is the prr error? I don’t have a flash drive I can make the DOS system on right now but I can do it tomorrow I think (need to find a spare)
Okay, so I tried with a USB DOS stick.
I used prr first, then ran fpt (the DOS version) fpt.exe -f -bios e5-571~1.bin then got error 200 and then ran prr2 giving the first screenshot;
Realised my syntax might have been incorrect then tried fpt.exe -bios -f e5-571~1.bin and got error 75: fparts.txt missing (so I copied it to the stick)
This time using the correct flash part info I got the same message as under win64; error 28 but prr2 still reads as the first screen
e5-571~1.bin <<< Do you really have the tilde in the command, or filename itself? If yes, that might be an issue causing the false fparts error.
Anyway, looks like my edit failed, it should have removed it all not left you with error 28. I will have to take a look again, but getting down to 28 and the info from your first image should help me find it now and remove the remaining 28 error.
This is controlled by two files sometimes, and I was only editing one, I may need to edit both
Thanks for confirmation the BIOS is unlocked again now, at least I got something right here 
Yes in DOS mode the filesystem is 8.3 so I used what it gave me on dir
@Lost_N_BIOS I’m extensively using my laptop for my graduation and I am working with Altium Designer 17. It all worked fine for the months I’ve been using it, but since yesterday, my laptop froze 3 times with the same glitching result seen in post #34 (Microcode Update of Insyde UEFI BIOSes (3))
MEInfo Version shows 6.0.50.1252 (did we update it? I can’t remember. I know that 6.0.40 was unstable and 6.0.32 was the default one).
Could it be that 6.0.50 is also unstable on certain load or could it be because I added more shared memory to my iGPU (320mb)?
hey, can anyone help with flashing lenovo g570? ive been trying almost everything but no change or best i get is "region map not found".
it became very hard to understand. icant get a dump file for some reasin and im lost for a long time. anyone wailing to help and i sure will donate something.
Sorry for bumping this old post, but doesn’t the “Microcode Update of Insyde UEFI BIOSes” topic title align perfectly with my request? 
I’m trying to update my microcode on an Insyde BIOS.
I managed to do it for the Intel ME Firmware with some tweaking, but when it comes to the microcode, I can’t seem to make it work.
I’ve been following all the guides for the past two weeks.
- It’s impossible to replace the microcode in FFS, RAW, or BIN mode with UEFITool (0.25, 0.25.1, 0.28),
- It’s impossible to replace them manually (HxD) even with address corrections in the FIT Table,
- It’s impossible with UBU (last and old),
- EzH2O v2.1.0.13 asks microcodes as txt patch file : is it the same as microdat.dat?
- And if I do everything manually at binary level, there are of course checksum and CRC errors.
- Etc.
Please note that I can update it using in software mode with the driver technique available here, and the latest microcode available here, which I convert from .bin to .dat with an AHK program 
(which I can try to improve and turn into a standalone EXE if there’s a high demand for it).
So don’t worry, I’m not asking someone to do it for me, but i just confirm me to move on and settle for the 
software version:
So, I would like confirmation that Insyde BIOSes are too secure to update the microcode (bootguard, need vendor’s private key to re-sign, etc.) and that even someone like CodeRush , Lost_N_BIOS , LS_79 , etc., wouldn’t be able to do it so I can move and let this topic finally and definitively fade into the depths of oblivion? 
What is the problem- inserting/ changing a Microcode or get the changed bios region flashed?
Edit
There’d be just one new µcode for 906A3?
NPx0PNx.12_906A3_430.zip (5.2 MB)
Output MCE, Security tab UEFIToolNE
output_sec_tab.zip (8.3 KB)
IBB Segments:
Flags: 0000h, Address: FFD3D000h, Size: 00086000h
Flags: 0000h, Address: FFE72000h, Size: 00150000h
Flags: 0000h, Address: FFFC2000h, Size: 00010000h
Flags: 0000h, Address: FFFD2000h, Size: 00001000h
Flags: 0000h, Address: FFFD3000h, Size: 00027600h
Flags: 0000h, Address: FFFFB000h, Size: 000003C0h
Flags: 0000h, Address: FFFFB4C0h, Size: 00004B40h
Can’t find something that’d compromise security since both _FIT_ and µcodes are out of protected areas and parser output and sec- info in UEFIToolNE is identical, but maybe I’m missing something?
1 Like
@ lfb6, thank you for your intervention and your help ! 
There’d be just one new µcode for 906A3?
Exactly. 423 to 430. As you have already found. 
OLD Microcode : 687.3 KB file on MEGA
NEW Microcode : 699.2 KB file on MEGA
Regarding the microcode update, I see that you used UEFITool.
So, I’ll spare you my other tests and describe you what I have done with UEFITool on my side. In case someone can teach me my errors so I can future do it myself and why not for others on the forum like you did for me.
1) I opened the original BIOS 32 MB file on MEGA in UEFITool_NE_A67_win32 (new engine).
We do find a FIT Image and we find 2 blocks containing 3 microcodes under the GUID 1FAE4D78-CB33-4F73-8881-A1EA8F5EDFEF.
- a) A block Image with 1 µcode for CPU 906A2 (body = 206848 bytes)
- b) A block Image with 2 µCodes, for CPU 906A3 and CPU 906A4 (body = 218112 bytes)
I want to remind you that according to this GitHub issue 
and the following image: the UEFITool version _NE = New Engine does not allow direct changes in the BIOS image.
2) So, I switch to UEFITool_0.28.0_win32 (the latest available in the old version, but I get the same result with UEFITool 0.25 or 0.25.1).
With UEFITool old version, we don’t have the microcodes themselves visible, but since we know the GUID 1FAE4D78-CB33-4F73-8881-A1EA8F5EDFEF. from point 1/, we know the area to replace.
This GUID 1FAE4D78-CB33-4F73-8881-A1EA8F5EDFEF (body = 424960 bytes) Image is supposed to contain the 3 microcodes, which are a) + b) in size.
206848 bytes + 218112 bytes = 424960 bytes.
3) If I try to insert all 3 microcodes and delete the old one, I can’t even save, I get an error like in this image.
Logical since I have an unknown subtype…
4) So, I abandon the idea of adding the 3 microcodes and will simply replace the microcode with that one of my processor (intel 12700H = 906A3): It works but…
But if I reopen my modified BIOS, despite having only that one microcode in place, I no longer have a FIT image
So, too afraid too flash this without a FIT…
So, no, you’re not missing anything. It seems the problem is more about me not knowing how to insert one or more microcodes. 
However, I promise you that I make efforts to follow the detailed guides here step by step. But maybe the problem is that I’m not skilled as you all as with computers and BIOS? 
I used HxD. Since you want to exchange just the second µcode you don’t even have to change _FIT_ since it’s the last µcode and the first won’t change, so the startaddress will be identical.
- Exchange the second µcode in HxD
- Cut 0x800 “FF” since new µcode is longer
- Adjust the length of the EFI volume
- Correct the checksum
(In the file I created 2 posts earlier i changed the order just to see if _FIT_ changes would work, too.)
1 Like
You can’t insert 3 µcodes of this class in this bios, there’s not enough space left. But A3 and A4 are identical except number and checksum (?).
EDIT:
You tried to insert the µcodes as an EFI volume each under the volume that contains the old µcodes, that doesn’t work.
Those µcodes are lying ‘raw’ in a single EFI volume => ‘Replace body’ would do the trick since the body is just the 2 µcodes after each other. This way EFI volume size would be changed automatically.
Unfortunately UEFITool 0.28 deletes the _FIT_, so that would be a brick. UEFITool 0.25 does work for me.
And the warnings in Messages ‘non-empty pad- file content will be destroyed’ should always ring a bell- but in this case these volumes aren’t changed.
2 Likes
@Michael_Code, there is enough space for 2 microcodes; the problem was me trying to insert an extra µCode (906A3 and 906A4 for two CPU are in a same and unique microcode).
For @lfb6, thank you very much for 1st initially doing the work and 2nd taking the time to explain your entire process with so much details and precisions 
.
As a result, I’ve found and understood many of my mistakes, sometimes very foolish, sometimes very unlucky, but now I am able to update my microcode by myself 
thanks to you 
.
I will edit this message tomorrow with a step-by-step explanation of my process and an explanation of my errors, which may serve as a guide for other members or as a reference for common mistakes to avoid.
See you soon, and once again, thank you very much @lfb6 for taking the time to explain to me in detail, mission accomplished! µCode rock!
Does that mean you updated your firmware and your board works with the changes? Otherwise it’s just theory up to now…
1 Like
Sorry. I just wanted to say that it looks much better than my initial attempts when I was completely losing the FIT table!
It’s just that by modifying the two microcodes in the same reverse direction that you did, I manage to obtain the same BIOS with an updated microcode and identical security tables. Almost everything is the same as yours, except…
Except… That I’m stuck on one detail, which is that our BIOS versions don’t have the same MD5. 
And upon closer inspection, I see that we have two different hexadecimal bytes, as visible in the image above. 
.
So, I am currently studying this post [GUIDE] Update CPU Microcode + Fix FIT Using UEFITool / Hex to understand why we have a 2 hexa’bytes difference even though we are following the same procedure and it seem related to µcode indeed.
If you change the order of the µcodes the first µcode will have a different size thereby changig the start address of the second µcode and _FIT_ checksum will change, too.
1 Like
Oh, yes, exactly… I see that for the addresses (offsets).
However, regarding the checksum, LOST_N_BIOS’ guide indicates that there’s nothing to calculate, that it’s updated automatically by UEFITool, but that doesn’t seem to be the case.
And I’ve been searching for a while, with moduloSum Of Bytes or moduloSum of Bytes % 256, I can’t seem to find the same value as the original BIOS or yours.
What type of checksum, and on which data should be calculated to update it?
Sorry for the noob question: I’m new into the BIOS Modding and I’d like to understand everything so I can create an AHK program that automates the process for future update for me or others.
EDIT: 
I used to calculate everything and anything, but I didn’t pay attention to the fact that the parser could correct it for me…
Again, thank you for assisting me so promptly and effectively!
I unfortunately cannot test in reality because I am encountering the following error:
Error 167: Protected Range Registers are currently set by BIOS, preventing flash access.
Please contact the target system BIOS vendor for an option to disable
Protected Range Registers.
FTP Operation Failed.
I am currently studying this guide to see if I can disable certain variables in some way.
However, from my research, it seems that for Intel 12th-gen CPUs, I am required to purchase an SPI programmer and a clip to read/write BIOS on Clevo NPxxPxx
And maybe an 1.8 V adaptor.
In addition: When working with a programmer or fpt you have to work with a dump of your own firmware otherwise boardspecific data might get lost!