SafeBreach-Labs / WindowsDowndate

A tool that takes over Windows Updates to craft custom downgrades and expose past fixed vulnerabilities
BSD 3-Clause "New" or "Revised" License
603 stars 80 forks source link

Doesn't work on EFI files in the ESP partition #3

Open subvert0r opened 2 months ago

subvert0r commented 2 months ago

I tried to use this tool on EFI files in the ESP partition by first mounting it using

mountvol x: /s

Then setting

    `<UpdateFile source="%CWD%\examples\EFI_Downgrade\UpdateFiles\bootmgfw.efi" destination="X:\EFI\Microsoft\Boot\bootmgfw.efi" />`

But it gives the following error:

[INFO] Starting Windows-Downdate
Traceback (most recent call last):
  File "windows_downdate.py", line 327, in <module>
    main()
  File "windows_downdate.py", line 306, in main
    update_files = parse_config_xml(args.config_xml)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "windows_downdate.py", line 222, in parse_config_xml
    update_file_obj = UpdateFile(source_file, destination_file)
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "windows_downdate.py", line 46, in __init__
    raise FileNotFoundError(f"The file to update {self._destination_path_obj.full_path} does not exist")
FileNotFoundError: The file to update X:\EFI\Microsoft\Boot\bootmgfw.efi does not exist
[8904] Failed to execute script 'windows_downdate' due to unhandled exception!

Anyway to make it work with downgrading EFI files in the ESP partition?

Note that the file %CWD%\examples\EFI_Downgrade\UpdateFiles\bootmgfw.efi does exist, and X: is accessible, but it still gives this error.

0xDeku commented 2 months ago

Hey :) With files residing in the EFI system partition, there is a need to add to the Pending.xml what is called an Advanced Installer. This installer makes sure to mount and un-mount the partition during the update process. Currently Windows Downdate does not natively support advanced installers.

After mounting though you can overwrite the ESP boot manager by using the "copy" command, that should work as the ESP boot manager is not Trusted Installer enforced AFAIK, and also is not loaded in the system. Post overwriting, un-mount with committing changes and your boot manager should be the one used in the next boot.

Alternatively, if you know the right advanced installer for the boot manager you can craft the Pending.xml and then feed it into the pend_update function directly.

Let me know if there is anything else I can help with.