Strange modifications in the EFI folder

Hi. I have encountered such a strange problem that I noticed something modifies the files (memtest.efi, SecureBootRecovery.efi,kdnet_uart16550.dll, bootmgr.efi etc) in the EFI folder. The date of file modification appears. The HASH checksums also change. The signatures seem to be normal, they indicate the new signature date. I have not found any information about this in Windows updates. I understand that it is impossible to trace what makes changes in these files somehow programmatically. Of course, maybe someone has more information about updates. Please share the information.
(Windows 11 Enterprise LTSC Evaluation 24h2, image from MS site)

misterq said:

Please share the information.

Click to expand...

Called my mother, she had no idea what I was talking about. Told her to go back to sleep, that it was all a dream.

What is it exactly you are worried about?

I didn’t get past the first Google response (which is Ai) It’s just too early here, sorry.
This is what Google spued out. Most of the information is obvious, but I copied & pasted regardless.



The files memtest.efi, SecureBootRecovery.efi, kdnet_uart16550.dll, and bootmgr.efi are crucial for the booting process and are typically not modified during normal system operations.While Windows Memory Diagnostics (memdiag.exe) can be related to memtest.efi, any unauthorized modification of these files could indicate a problem or a potential security issue.

• memtest.efi:
  This file is part of the Windows Memory Diagnostics utility (memdiag.exe). It's used to perform memory checks during the boot process to identify potential RAM issues.
  
  
• SecureBootRecovery.efi:
  This file is used in UEFI systems to provide a way to recover from Secure Boot issues, which is a security feature that verifies the authenticity of the boot process.
  
  
• kdnet_uart16550.dll:
  This file is a kernel debugger network driver and allows debugging from a remote machine.
  
  
• bootmgr.efi (or Bootmgr.efi):
  This file is the main component of the UEFI boot process in Windows. It's responsible for loading the operating system.

Potential reasons for modification and what to do:

1. Malignant Activity:
   Unauthorized modifications could be a sign of malware or malicious software trying to interfere with the boot process.
2. System Error:
   It's possible a system error or a corrupted file could lead to accidental modifications.
3. Software Interference:
   Certain software, especially bootloaders or tools that modify the system's boot configurations, could unintentionally modify these files.

Troubleshooting Steps:

1. Check File Properties:
   Right-click each file and examine its properties, particularly the "Details" tab, to see if the file size, date, or version has been altered.
2. Run a Malware Scan:
   Perform a thorough malware scan using a reputable antivirus or anti-malware program.
3. Restore from Backup:
   If you have a recent system image or restore point, consider restoring your system to a known good state.

misterq said:

something modifies the files (memtest.efi, SecureBootRecovery.efi,kdnet_uart16550.dll, bootmgr.efi etc) in the EFI folder

Click to expand...

Welcome to Eleven Forum.

I see the same. I don't think it's anything to worry about though. The creation date corresponds to the date of my clean install, and the modification date to that of the installing a cumulative update. It would seem that the 'something' that modified it was Windows Update.

misterq said:

I have not found any information about this in Windows updates.

Click to expand...

I have. It's at the bottom of the KB for the cumulative update I installed.

Microsoft said:

File information

For a list of the files that are provided in this update, download the file information for cumulative update 5055627.

Click to expand...

Found this in the .csv file I downloaded.

SecureBootRecovery.efi saved me. I had installed the new Microsoft 2023 certificates with Mokichu's scripts, then (I don't even know why), I cleared all the uefi database keys from the bios and could no longer enable secure boot (the button was grayed out).
If I loaded the default keys, secure boot was enabled, but I encountered a "Secure Boot Violation. Invalid signature detected" message during startup.
I tried updating the new certificates again with Mokichu's scripts, but the operation permanently showed as "in progress" .
Then I read here "How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 - Microsoft Support" that If a device has the Secure Boot settings reset to the defaults after applying the mitigations, the device will not boot. To resolve this issue, a repair application is included with the July 9, 2024 updates that can be used to reapply the “Windows UEFI CA 2023” certificate to the DB (mitigation #1).
I followed the simple instructions here [Notebook] Troubleshooting - Secure Boot Violation Error at Startup | Official Support | ASUS (from the ASUS website, but also worked for my HP laptop) and now I have my secure boot enabled and the Microsoft 2023 keys again in the database.
My lesson was: never mess with the BIOS, as I did, unless you know what you're doing.

I haven't seen it written elsewhere, but the Windows devs responsible for Secure Boot made a presentation at an UEFI conference.
Evolving the Secure Boot Ecosystem

If Windows cannot detect the 2023 Certificates in DB_DEFAULT, Windows update will place a 2011 KEK signed SecureBootRecovery.efi application immediately after Bootmgfw.efi in the boot order carrying a 2011 KEK signed 2023 Production CA
•This ensures the system continues to boot Windows if Secure Boot Keys are accidently cleared

Click to expand...