Looks like it's all unlocked @Vaxter - send me dump from FPTw.exe -d bios.bin and I can confirm for you, also send fd.bin dump too.
If FD unlocked, and it looks like it us, at least for reading, then you should be able to update complete BIOS including FD, did you flash mod BIOS like this >> FPTw.exe -f ModBIOS.bin

I don't think you need audio pinmod now, unless FD is not unlocked for write, only read, that is why I said attach BIOS dump above and FD dump too.
That second image, doesn't show it wrote/updated FD. If ME version was changed SKU to 370 then you need to also write FD, I will check files when you send if ME SKU was changed or not (If not, it may be needed, maybe need to use other AIO Tool)
I am not sure if it's needed for your setup or not, but if it is and coffeetime did not change that you need to use other tool, then write entire BIOS including FD using FPT

Apparently there is another unlock method E8 which is described in this whitepaper https://bromiumlabs.files.wordpress.com/..._whitepaper.pdf and even used in the wild by the UEFI Malware Lojax https://www.theregister.co.uk/2019/01/02/lojax_uefi_rootkit/

I would add an honorary mention to this magnificent post! Well done @plutomaniac!

the ru.efi tool, once you get the offsets with the IFR tool, ru.efi can help modify the setup var on the system using efi shell, saving the effort of dumping the spi (although you should really do it for backup, just in case)
link: http://ruexe.blogspot.com/

You are right, as always :)
What I forgot to mention was that you probably can extract the IFR from an OEM BIOS update image without needing to dump SPI, I have been playing around with this kind of "non invasive" (not popping the hood so to speak)
for a while with moderate success. i haven't had the chance yet to try to change authenticated setup variables, but would be interesting to see what would be the options once i do.

In my experience, well I mean from seeing users experience with RU/Shell (have not used it personally), this does not always match-up/change the correct/same variables from BIOS setup module as Grub does, so should not be used for this in many instances.
I have ran into this issue many times while trying to help users change something in grub and they try RU/Shell instead, that's where my experiences with this come from.

You're welcome. Yes, AMISetupwriter does similar thing, but it uses the shell method (Similar to RU, but more closely like grub) to write on reboot, there may be cases where it wont work either, but same can happen with grub too. Sadly there's not a "one fits all" for this.

Insyde BIOS is tricky, depending on how BIOS is setup, the variables from "Setup" can be used, or it could be one of several setup/custom variables within NVRAM that are used/loaded instead, and you never know which is used until you try and it succeeds or fails to change the setting.
When trying to change things like this on Insyde BIOS, setup/IFR method can be tested first if user can get grub loaded, if that fails then certainly regular shell edit would fail similarly too.
H20UVE is better tool to change variables like this on Insyde, you can dump all variables, setup, custom etc can all be dumped and edited at once.
Using this, in combination with setup_var2/var3 to get other setup GUID's can help you know which GUID is actually being used setup or customer etc. You can tell by the other GUID's var2/var3 gives you when showing output from "setup", hard to explain except in direct situations

For sure, none of this we've been discussing would ever help to unlock FD anyway

I think this section need to be updated: D. Check Locked/Unlocked Status.
We can not check the lock status by just dumping the flash. In some cases, the flash can be dumped succussfully, but the Descriptor Region is still locked.

@plutomaniac @Lost_N_BIOS
I use the ru.efi several times.And I found something different.
1.Not all the mobo could show the offset(including SETUP guid) in the ru.efi.
2.ru.efi may show and be modded the offset besides SETUP guid,such as platform guid.
3.I think ru.efi could just show and be modded the area of "00-FF" offset in the guid.If exist some offset over the area of "00-FF" as "406", ru.efi could not modify it.

@finnce - you can always check status with the dumped BIOS or dumped FD, I am not sure what you mean by you can't check it by dumping

@gloobox - I've never used RU, but I can tell you from seeing others use and try to use it, what it shows you is not always the correct and proper locations to edit like you would if using grub / setup_var
Rest of your comments, I can't comment back on, no experience with this tool.

Not sure if of any interest, but stumbled upon a Supermicro bios with a tool for unlocking ME region:
"On X10 DP Grantley platforms, Supermicro introduces a jumper-free solution that places ME into the manufacturing mode. The user doesn't have to open the chassis to adjust the ME-related jumper on the motherboard any more. The ME manufacturing mode is required upon updating all software-strap settings in Flash Descriptor Table (FDT) inside ME region."

Depends on reading a "CMOS50 value" with a DOS program, so it's changing a CMOS variable as described in chapter E6, but with a DOS- program (program for EFI shell exists as well):
...
"fdt -w 50 A5
afudos %1 /P /B /N /K /R /ME
fdt -w 50 00"
...

Board was X10DRU-i+, bios X10DRU9_611.zip