I am very grateful of the help provided by all you people. Payment was suggested, not mandated (file was linked first). I was happy with the amount I paid, I hope he was too! 
Well thatâs cool of him then, now I have much less negative thoughts about it since it was presented as optional after BIOS was provided anyway - very cool of him I suppose, I take back all of my negative thoughts 
I charge⊠1x Beer, and hope you have at least 12 problems needing solved immediately 
I can try again on the 280 error if you want? You got unlocked menus again correct?
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