Yes, but i only had time to try it quick this morning, maybe i overlooked something, but everything looked normal in UT and mmtool.
@Pacman
No, I haven’t tested them, because I don’t have the needed hardware. Should have posted a warning, but it is not too late to do it now. I uploaded the ffs files, because this way Sonix can inspect the files and cut to his needs, which is the executable section - body of PE32+. It is not recommended to use the ffs file as is, because your BIOS might expect a different GUID or not be able to follow the dependencies. Not to mention that these particular files I have uploaded have the dependencies after PE32+, which I don’t know if it is the right thing to do.
In order to use them, open your BIOS file in UEFITool, search for SataDriver, select “Replace as is…” and replace with the above file, save as temp.rom. Open temp.rom in UEFITool, search again for SataDriver, expand it until you see PE32+ image section, extract body of PE32+ and delete temp.rom. Then open your BIOS file again, search again for SataDriver, expand it until you see PE32+ image section, replace body of PE32+ with the previous saved body and save. This preserves the GUID, dependencies, UI. Or you can wait for Sonix to provide clean files, with common GUIDs and dependencies.
There is also the manual way, with parsing sections and extracting the body of section type 0x10, but you again end up with UEFITool, unless you want to fix the section size, data size and checksums on your own.
If you did all this and still have problems, then maybe it is the driver itself.
Yes, i did it in a similar way, but just replaced the whole body of the Satadriver with the body from your file.
I wont be home until monday, i will try some other things then, only have my phone now.
@lordkag , I’m really glad that you can use my code to develop something, so I will never say anything against it, no need to mention it further.
Thank you for the report on that new Intel BIOS, support for this type of GUID section is added to UEFITool 0.19.0 release.
@lordkag
Totally agree with CodeRush. I want to wish you further success! 
Added:
I’ll have to think about.
I think generally exclude update LAN BOOT QCM-Atheros.
Kaveri and Kabini this APU, iGPU (VBIOS) have another name Spectra and Kalindi.
Fix.
Tool DrvVer must write all over again. I’ll do later.
Thanx SoniX,
UEFITool 0.19.1 is also out…
https://github.com/LongSoft/UEFITool/releases/tag/0.19.1.1 (UEFIExtract 0.3.2 / UEFIPatch 0.2.2 too).
When comparing latest UBU 1.8.15 with previous 1.8.13 I’ve noticed that Modules>VGA>2170.bin has been replaced with a September-modified one vs the November one in 1.8.13. Probably SoniX has a good reason for it, but since is not listed in changelog, I report it just in case 
Yes, I replaced the reference (original) file, since the module was set on what that motherboard from ASRock.
Hello,
the changes at AMD AHCI OROM v3.2.2.0 (Device ID 4391/7801) from v3.2.1.0 has on my ASRock AOD790GX/128M the following effects:
+ In Bootorder (BIOS) there’s written correct “AHCI: SSD 850 Pro” instead of “IDE: SSD 850 Pro” (in AHCI-Mode).
o AHCI-Mode is funktion normaly.
- The Bootprocess is delayed at least 1 Minute for every SSD/HDD while the Operation-LED ist shining almost all the time. Maybe the drive is testing S.M.A.R.T.-Errors?
I don’t like that & kicked it away and gone back to Version 3.2.1.0 - that’s I would let you know … and share my experience.
Best regards, MiMo
Am I missing something? I have Rampage IV Extreme. EFI installation Windows 8.1
Prior to using v1.8.15 … Intel RST software reported I was using RAID ROM version 13.5.0.2118
After changing bios with 1.8.15 … RST software now reports I’m using 13.1.0.2126 
Is there no 13.5.0.2164 for my board?
I notice in the MODULES\IRST\13_5\ Folder there’s no SataDriver43_x79 in v1.8.15 is this an error?
@ bolt4brekfast:
Welcome at Win-RAID Forum! It is a pleasure for me, that you are a member of my Forum.
Only SoniX is able to answer your questions.
Regards
Fernando
I’ve been a long time lurker lol 
Thanks for the warm welcome.
@ bolts4brekfast:
If you don’t want to wait for SoniX’s answers and need the SataDriver43_x79 v13.5.0.2164, please let me know it. Then I will create the file for you and other X79 chipset users.
That would be great! Thanks!
@ bolts4brekfast:
Attached is the requested Intel EFI SataDriver v13.5.0.2164 with the GUID 43A0A7B3 for X79 chipset systems running their Intel SATA RAID Controller in RST mode.
I just have tested this module with the BIOS 4901 of the ASUS Rampage-IV-Extreme and it was no problem to replace the original SataDriver v12.7.0.1936 by this one.
Note:
After the replacement of the module it will still be shown within the MMTool as being "SataDriver_12_7_1036". Nevertheless it is the SataDriver v13.5.0.2164.
You can easily verify it by opening the file with a Hex Editor and searching for the text "external".
Good luck!
Fernando
Intel-RST_EFI-RAID_SataDriver_v13502164_GUID-43A0A7B3.rar (77.3 KB)
And I assume that afterwards, Intel RST will report 13.5.0.2164?
UPDATE: It works! Thank you so much for taking the time to do this! 
I have 2 questions.
1) Which RAID mode is used?
2) What is the mode you have full UEFI or Lagacy?
@Sonix and Coderush
I am grateful for your kind words, since both of you were a major influence in starting this, but I don’t plan to release it to the general public, not even on a separate thread on this forum. My coding skills are at high-school levels and are bound to stay there, because of some personal problems, plus I’m not that sociable to be in front of a project. I just wanted to have this discussed like gentlemen. It was my way of asking for pardon or acceptance, since it is a little rude to have this published on your thread and with your code. If it is OK with you, I will only post once in a while, when I add/fix something important, to not clutter this thread. Fixes happen all the time in the background, but I won’t publish them until there is a great need for them.
I will use this post to publish another version, since I have added something useful. Now the Extractor tries to detect the GUID for those OROMs placed out of CSMCORE. It should catch most cases, where the OROM follows after header, especially in Insyde BIOS. If there should be misses, I will try to do something when I’ll have test cases, but I feel it would be close to impossible without a full parser. There are some lines (546-549) in Z.Version.py for extracting the ffs containing OROM, if it should be needed, but right now I’m only extracting the OROM itself.
I have also noticed that OROMs might get extracted multiple times for APTIO, when CSMCORE or CSM-EFI is uncompressed. This can be prevented by adding a variable in lines 170-171 of Extractor.bat and search main volume only in that case. But this might skip some strangely placed OROMs in APTIO, so it would be better to just uncomment line 767 in Extractor.bat if you want to have a clear distinction.
#Extractor4Upd.rar (50 KB)
@lordkag
Thank you for your utility is very useful. Keep it up! Always looking forward to your news. 
PS Check definition versions of files in the archive.
Add:
Unfortunately many of the files associated with USB, do not display the version.
qcm_atheros.rar (27.7 KB)
I’m getting “file size exceeds the volume size” with UBU 1.8.15 trying to update microcode on Rampage IV Black Edition 0801 bios.