Hi, I want to announce one of my new tool, a Tool to patch certain bios part at runtime, not all can be patched, but If you know what are you doing, you can do some serious thing.
An example of usage is to unlock recent Legion BIOS
4 Likes
I can not forgive myself for missing the publication of this tool!
I used resorting to OS functionality to automate BIOS unlock process, but unforeseen factors always acted against me… An enabled antivirus, UAC component and etc.
With your new creation it’s different now. I’m going to expand the number of community patches. And also to add something from myself, as I did it mercilessly with your LenovoH2O-Unlocker 
and then had been throwing the link at every requestioner.
Maybe I will use the rEFInd specially for BIOS with only UEFI Secure Boot available.
Thus, in anticipation of all this, I have a question. On the GitHub page of the project is said: “the Bios UI will be not loaded as we booted from a USB, but we can force it to load with”. …with loading the SetupUtilityApp module. Is there a quick solution in order to find a module with the same role in a BIOS of some other manuf?
1 Like
I unarchived the GitHub - SmokelessCPUv2/SREP-Community-Patches: A List of community patches to use with SmokelessRuntimeEfiPatcher repo, so fell free to open pull request
regarding which is the UI app, most likely will the only one marked application between all the dxe driver
I would like to know about one specification of your tool.
I made a config file for some Honor notebook that has no cE! backdoor. Entering the BIOS UI at the end is no problem. But the patch option containing 81 hex symbols to be replaced doesn’t seem to work.
Is there a chars limit in your program for this operation?
Sorry for my impatientience, because the best decision was to check the log file firsrly, but this is also a reserve for the future.
No char limit
But without log, I can’t say much 
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
1 Like
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
1 Like
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.