Patching already loaded module is tricky…
Cause if you patch a part of the code that has already been executed, and will not be executed again the patch is useless…
This could be the case of IFR on an already loaded module…
The IFR has been installed in the HII Database, and even you patching it in the module will not work, cause will not be installed again that code is not executed…
I was working in a way to patch loaded IFR, but I lost intrest as I don’t needed it…
It’s overcomplicated for me to understand how the HII database module and the IFR table from SetupUtility are connected.
Your words did not convey to me the reason of patching failure. Can I interpret them so that I can’t change the IFR?
Let’s put this way
you have the IFR when the module load it install to something called hii Database
then setup utility read from there
Module → IFR → HII Datatbase
the UI read from database and display…
So if you patch before being inserted in the database will work, after not…
so in this version most of the IFR patch will fail, if done on a Loaded Module
the next version will allow to patch also IFR of already installed module
you can try this was and see if something change:
instead of Loaded use a Combo of LoadFromFV and Exec, and see if reloading it do something
Thank you for explanation.
I thought that “Op Exec” is meant for starting executing all commands. I can use it differently? Where should I put it correctly in syntax?
Op Exec, tell to execute the patched Code…
if you do for example
LoadFromFV → it load the binary in Memory
Patch → Patch the binary in memory
Exec → Execute the Just Patched binary
so exec make sense only on LoadFrom… Op
Hello again.
I hope you’re doing good.
I’m writing this post to announce the ideas that I came to recently, as well as to find out how realistic I am in your opinion.
Here’s what I want to know.
It is known that the latest Insyde BIOS revisions, those that load all HIIs at the same time, have a wonderful app module that plays a key role when using SREP. But what about older revisions or even other oems? Where We’re Going? 
I’m pretty sure you’ve already seen the attached page of printable UEFI specifications, but I have to put my mind at ease on this one. There’s already an Android and Linux apps for booting to FW UI… On the next boot, unfortunatelly.
https://github.com/Keddnyo/BootUEFI
https://firmwaresecurity.com/2020/04/05/os-indications-tool-for-setting-the-osindications-uefi-variable/
https://github.com/eaut/uefi-boottools/blob/master/scripts/uefi-boot2setup
Can we somehow abuse the OsIndications to get to FW UI instantly? Or otherwise… Trace a piece of code in BIOS that interacts with this flag and, you know, put that code into a separate program.
How much this will cost? As an average student, I am not rich, but for the sake of further progress, I can ~help.
Here’s the part why I did not reach out to you through the messaging system.
I would like to thank you publicly for all your contributions. You’re not even thinking about how large the number of people that use your programs. I personally think that your latest releases are the real breakthrough.
In this regard, this evening I resorted to brainstorm reviewing the possibilities for the expanding usefulness of SREP.
So far, having difficulties conquering the excitement, I already realized that with SREP you can freely use tools that previously required integration into a BIOS image or run through a shell. Such as this one.
Returning to the topic of unlocking, I remember an interesting modding request. In short, changing the BIOS in this particular case triggered something that loads the FW UI at every boot. After removing some module, this was stopped, even though the form’s GUID was never in the array of allowed. And I wonder if it works this way: something >> ReFlash module >> FW UI. So, it would be perfect if a module that would help make AMI friends with SREP was accidentally found. I am writing this thinking that there will be some competent person who will deal with this, if lucky, without my participation. I’ve never had an AMI BIOS PC, but when I do, I’ll be able to test it for myself.
the flag is intresting, I need to check it, but it might work, and tbh don’t even sound too difficult to try out.
regading SREP most likely in the next month I might releas a new revision, that will be way more powerfull,
Will it support fuzzy matching?
I am modifying some Clevo BIOS and just editing some IFR suppress if, I want it support multi version.
Clevo new BIOS have Intel Boot Guard enabled so there might be no BIOS mod anymore.
I’m planning to add a lua scripting engine, to allow more complex script and condition etc…, for patter matching it depend of what you mean for fuzzy matching, I can easily add a wildcard matchining search…
but for more exotic matching you have to explain how you want them to work
For now wildcard is enough, I just want it run like UEFIPatch.
Was wondering how do you use this tool to lets say load an efi module? Also is the effect of this tool permanent?
Thank you
Op LoadFromFS
<.efi>
Op Exec
Exec option applies to the last loaded app only. Use “Op Exec” after each to load multiple apps.
Effect is not permanent.
After bootx64 loads does it continue to look for the Windows or other OS boot file? How does that work? guessing you would have to daisy chain load the windows boot loader off of the efi partition on your hard drive.
Thanks
SREP is not an OS loader. It can be, but not needed at all, in the first place. After you launch SREP, it does whatever you programmed within the available functions. The source files are available on github.
Loading the only UiApp of UMAF tool successfully brings you the default tabs layout configured in AMITSE. And it also opens UiApp as FrontPage.
So, I would venture to say that the solution is already there. It works this way: SREP >> UMAF UiApp >> FW UI.
Do you happen to know about this before, @AARCH64_EL3?
Loading only UiApp is highly unstable and has a very low success rate across bios vendor, expecially on newer bios with grphical/mouse UI
Will it load an FFS file? Or do I have to convert it to efi?
Also does it matter if using a usb key how the disk is formated? If I go UEFI with GUID EFI system partition will it load from the EFI partition or does it have to be a single partitioned drive or not matter?
Thanks
I’m no expert, but I believe it needs to be a pure .efi file for proper loading. Normally, you should use FAT32 formatted flash drive. SREP will load files specified from the root of partition.
Well I tried to create an uefi compatible usb stick with its own system efi partition housing an EFI/BOOT folder because I have CSM turned off. In any case had no luck getting my bios boot menu to see the BOOTx64.efi file or recognize the usb stick as a bootable drive no matter where the EFI folder was located. By all right the system should have seen it though I did not try to create a lone fat32 partition. Maybe was a bad usb stick. Still chasing the dream to be able to daisy chain load lets say the resizeable bar efi mod file and then daisy chain load my windows system or another boot loader of my choice.
Thanks
tbf, loading the RebarMod or any other DXE driver from Storage , before the boot option is easy and is a supported natively by UEFI…
not even need any external tool…
