3 ms·

The author is exaggerating quite a bit. Nothing is intrinsically complicated about writing a UEFI "application" -- UEFI sadly even specifies this. Someone even

The author is exaggerating quite a bit. Nothing is intrinsically complicated about writing a UEFI "application" -- UEFI sadly even specifies this. Someone even ported DOOM. They did it for jiggles -- but it's hardly "completely new forms of software". Easier than writing a native MS-DOS program, for sure. Some company even sold laptops with two CPUs, one that would run some Windows CE while the main Windows was booting. Even that is just gluing a PDA and a laptop together... BIOSes "perverting" sleep behavior? Sleep is precisely what the BIOS handles. E.g. way before Windows would support hibernation natively, laptops with hibernation capabilities would have to do it all on firmware. And it wasn't that fragile, since it would work with everything from MS-DOS to Linux (even the progress bar UI which was some VGA text mode). This is how I learn in the 90s that Windows likes to keep unused pages zeroed while Linux does not: hibernation under Linux would take significantly longer. But it'd work. No one remembers firmware hibernation partitions? I'd guess that many people do, since Intel tried to resurrect that in the 2015s (e.g. https://www.dell.com/support/kbdoc/en-us/000136460/how-to-use-intel-rapid-start-technology-to-improve-system-startup-from-hibernation https://www.dell.com/support/kbdoc/en-us/000136460/how-to-us... ). Wait until you learn that MS has hooks for the firmware to download executables that will run during kernel boot time...

rzzzt 4y ago
Is it the same mechanism that's used by Computrace / Absolute?
- AshamedCaptain 4y ago
  Computrace uses WPBT, which is one of them.
michaelsshaw 4y ago
>Wait until you learn that MS has hooks for the firmware to download executables that will run during kernel boot time... Could you elaborate? Sounds very sinister
- skitter 4y ago
  This might be about ACPI's Windows Platform Binary Table, which allows malware like Superfish to persist across installations.
- mkup 4y ago
  There is WPBT ACPI table which may contain PE executable saved as \Windows\System32\Wpbbin.exe and executed at boot time (supported by Windows 8 and above). Official specification is here: https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-4E2D-A559-4A27CF905A80/windows-platform-binary-table.docx https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-... Also there is an unofficial method of running firmware-initiated VBScript in the all versions Windows starting from Windows 2000. There is a special type of ACPI devices (PNP0C14, "Windows Management Instrumentation Device") which is handled by Windows builtin driver WMIACPI.SYS. This type of ACPI device can export (via ACPI bytecode) various data fields and methods for Windows subsystem WMI/WBEM (think CPU thermal sensors; laptop backlight control; on/off switches for builtin camera/wifi/bluetooth hardware, which can be managed by Windows tray utility supplied by laptop vendor etc), as well as binary MOF which contains WMI metadata for these fields and methods. Besides primary purpose, this binary MOF can be constructed in such way that VBScript code is executed immediately in the MOF parser context (wmiprvse.exe, a builtin Windows service). Windows DDK has various MOF-related tools like compiler, verifier etc; as well as some samples. Binary MOF is compressed, but its format has been reverse engineered (it uses an old compression algorithm from Microsoft DoubleSpace). This method for running firmware-initiated VBScript works for all versions of Windows starting from Windows 2000, including WinPE-based Windows Setup (Vista+). References: https://wiki.ubuntu.com/Kernel/Reference/WMI https://wiki.ubuntu.com/Kernel/Reference/WMI https://raw.githubusercontent.com/microsoft/Windows-driver-samples/main/wmi/wmiacpi/wmi-acpi.htm https://raw.githubusercontent.com/microsoft/Windows-driver-s... https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-... https://github.com/pali/bmfdec https://github.com/pali/bmfdec
  - AshamedCaptain 4y ago
    You mentioned the two methods I had in mind. These days there is a third one, but it seems to require cooperation from Windows Update. MSI (for example) uses it. As far I as can see, they simply create a fake ACPI node for which Windows Update will silently download a "driver", which in turn downloads the crapware.
userbinator 4y ago
Easier than writing a native MS-DOS program, for sure. I'm not so sure about that. Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs. xchg ax. bp mov dx, 107h int 21h ret db "INT 21 forever!",13,10,"$"
- AshamedCaptain 4y ago
  > Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs. Weight that (literally only a couple macros) versus the idea of having to dig out a 16-bit toolchain and/or a DOS extender which also brings its own obtusely indirect APIs with it. In case you decide to do the former, you'll probably have to rewrite big chunks of your program in order to rearchitect it around XMS. In case you decide to do the latter, you'll be able to use a 32-bit toolchain, but you'll have to write your own drivers for high-resolution graphics, sound, and depending on your luck, mouse. All of this UEFI brings for free, and even for recent hardware.
- LiamPowell 4y ago
  You don't need any sort of large toolchain. In short, a UEFI application works like this (from memory so some details may be wrong): The system calls your main function with a parameter for the address of a struct. That struct contains a function pointer which you can call to get other structs known as protocols. Those protocols contain function pointers which you use for everything else (putting images on the screen, setting callbacks for keyboard input, making network requests, etc.). All you need is the function signatures and the constants to lookup the protocols, it's no more than you need to use any other C library. I can tell you from experience that if all you want to do is textual IO you only need a few hundred lines of header files: https://github.com/liampwll/zig-efi-os https://github.com/liampwll/zig-efi-os
  - mananaysiempre 4y ago
    Getting the GNU EFI toolchain to work is somewhat involved. The result is also convoluted for reasons I don’t understand. For example, it uses a perfectly normal GCC that is perfectly capable of defining and invoking __stdcall functions, but instead it has assembly thunks you’re supposed to use to translate to and from __cdecl. AFAICT it shouldn’t be that much harder than a bunch of header files, a freestanding compiler invocation with a custom crt0 and an objcopy to make the PE file (OK, yeah, PE relocations are different from ELF ones, but still), yet the standard C setup you’ll find on OSDev Wiki or similar is, in fact, quite annoying to use.
ntauthority 4y ago
I was personally somewhat hoping the boot-time portion in this article somehow hijacked a UEFI runtime services[1] function called by the OS to draw to the frame buffer set up by the firmware, since this has some provisions for the OS being in charge of the MMU: > An OS may choose to execute in a virtual addressing mode and, as a result, may prefer to call firmware services provided by UEFI Runtime Drivers in a virtual addressing mode. A UEFI Runtime Driver must not make any assumptions about the type of operating system to be booted, so the driver must always be able to switch from using physical addresses to using virtual addresses if the operating system calls SetVirtualAddressMap(). Disappointingly, it's just a 'plain' case of SMM (which is also, funnily, the main target for ACPI callouts to more 'complex' methods, and on ARM has the very fun equivalent called 'SMC/HVC callouts to EL3/EL2 firmware' although that's supposedly a bit better-defined than Intel SMM) and nothing too clever either - an ACPI method hijacking something to then write to the framebuffer? Other than that, the writing style here feels almost.. presumptuous and might've been written for the original audience on the site it's posted on, for example I was left wondering things like 'if the author or their friends have access to a machine with this software on it, why don't they dump the firmware flash storage and decompile the actual images, wherever they might be', though it may be they indeed didn't have access to any such hardware or firmware downloads and are just piecing random puzzle parts together, and the post eventually devolved into a general rant against OEM cleverness that I somewhat skipped. (I'm also mildly torn between 'wow, clever hack' and 'oh lord this would be terrible to diagnose OS boot issues on as you really can't trust OEMs with side effects or long-term maintenance' in this regard) [1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/7_driver_entry_point/711_runtime_drivers https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...

rzzzt 4y ago

Is it the same mechanism that's used by Computrace / Absolute?

AshamedCaptain 4y ago
Computrace uses WPBT, which is one of them.

michaelsshaw 4y ago

>Wait until you learn that MS has hooks for the firmware to download executables that will run during kernel boot time... Could you elaborate? Sounds very sinister

skitter 4y ago
This might be about ACPI's Windows Platform Binary Table, which allows malware like Superfish to persist across installations.
mkup 4y ago
There is WPBT ACPI table which may contain PE executable saved as \Windows\System32\Wpbbin.exe and executed at boot time (supported by Windows 8 and above). Official specification is here: https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-4E2D-A559-4A27CF905A80/windows-platform-binary-table.docx https://download.microsoft.com/download/8/A/2/8A2FB72D-9B96-... Also there is an unofficial method of running firmware-initiated VBScript in the all versions Windows starting from Windows 2000. There is a special type of ACPI devices (PNP0C14, "Windows Management Instrumentation Device") which is handled by Windows builtin driver WMIACPI.SYS. This type of ACPI device can export (via ACPI bytecode) various data fields and methods for Windows subsystem WMI/WBEM (think CPU thermal sensors; laptop backlight control; on/off switches for builtin camera/wifi/bluetooth hardware, which can be managed by Windows tray utility supplied by laptop vendor etc), as well as binary MOF which contains WMI metadata for these fields and methods. Besides primary purpose, this binary MOF can be constructed in such way that VBScript code is executed immediately in the MOF parser context (wmiprvse.exe, a builtin Windows service). Windows DDK has various MOF-related tools like compiler, verifier etc; as well as some samples. Binary MOF is compressed, but its format has been reverse engineered (it uses an old compression algorithm from Microsoft DoubleSpace). This method for running firmware-initiated VBScript works for all versions of Windows starting from Windows 2000, including WinPE-based Windows Setup (Vista+). References: https://wiki.ubuntu.com/Kernel/Reference/WMI https://wiki.ubuntu.com/Kernel/Reference/WMI https://raw.githubusercontent.com/microsoft/Windows-driver-samples/main/wmi/wmiacpi/wmi-acpi.htm https://raw.githubusercontent.com/microsoft/Windows-driver-s... https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-Abusing-Windows-Management-Instrumentation-WMI-To-Build-A-Persistent%20Asynchronous-And-Fileless-Backdoor-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Graeber-... https://github.com/pali/bmfdec https://github.com/pali/bmfdec
- AshamedCaptain 4y ago
  You mentioned the two methods I had in mind. These days there is a third one, but it seems to require cooperation from Windows Update. MSI (for example) uses it. As far I as can see, they simply create a fake ACPI node for which Windows Update will silently download a "driver", which in turn downloads the crapware.

userbinator 4y ago

Easier than writing a native MS-DOS program, for sure. I'm not so sure about that. Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs. xchg ax. bp mov dx, 107h int 21h ret db "INT 21 forever!",13,10,"$"

AshamedCaptain 4y ago
> Especially when AFAIK you need to use a rather large toolchain to access the obtusely indirect APIs. Weight that (literally only a couple macros) versus the idea of having to dig out a 16-bit toolchain and/or a DOS extender which also brings its own obtusely indirect APIs with it. In case you decide to do the former, you'll probably have to rewrite big chunks of your program in order to rearchitect it around XMS. In case you decide to do the latter, you'll be able to use a 32-bit toolchain, but you'll have to write your own drivers for high-resolution graphics, sound, and depending on your luck, mouse. All of this UEFI brings for free, and even for recent hardware.
LiamPowell 4y ago
You don't need any sort of large toolchain. In short, a UEFI application works like this (from memory so some details may be wrong): The system calls your main function with a parameter for the address of a struct. That struct contains a function pointer which you can call to get other structs known as protocols. Those protocols contain function pointers which you use for everything else (putting images on the screen, setting callbacks for keyboard input, making network requests, etc.). All you need is the function signatures and the constants to lookup the protocols, it's no more than you need to use any other C library. I can tell you from experience that if all you want to do is textual IO you only need a few hundred lines of header files: https://github.com/liampwll/zig-efi-os https://github.com/liampwll/zig-efi-os
- mananaysiempre 4y ago
  Getting the GNU EFI toolchain to work is somewhat involved. The result is also convoluted for reasons I don’t understand. For example, it uses a perfectly normal GCC that is perfectly capable of defining and invoking __stdcall functions, but instead it has assembly thunks you’re supposed to use to translate to and from __cdecl. AFAICT it shouldn’t be that much harder than a bunch of header files, a freestanding compiler invocation with a custom crt0 and an objcopy to make the PE file (OK, yeah, PE relocations are different from ELF ones, but still), yet the standard C setup you’ll find on OSDev Wiki or similar is, in fact, quite annoying to use.

ntauthority 4y ago

I was personally somewhat hoping the boot-time portion in this article somehow hijacked a UEFI runtime services[1] function called by the OS to draw to the frame buffer set up by the firmware, since this has some provisions for the OS being in charge of the MMU: > An OS may choose to execute in a virtual addressing mode and, as a result, may prefer to call firmware services provided by UEFI Runtime Drivers in a virtual addressing mode. A UEFI Runtime Driver must not make any assumptions about the type of operating system to be booted, so the driver must always be able to switch from using physical addresses to using virtual addresses if the operating system calls SetVirtualAddressMap(). Disappointingly, it's just a 'plain' case of SMM (which is also, funnily, the main target for ACPI callouts to more 'complex' methods, and on ARM has the very fun equivalent called 'SMC/HVC callouts to EL3/EL2 firmware' although that's supposedly a bit better-defined than Intel SMM) and nothing too clever either - an ACPI method hijacking something to then write to the framebuffer? Other than that, the writing style here feels almost.. presumptuous and might've been written for the original audience on the site it's posted on, for example I was left wondering things like 'if the author or their friends have access to a machine with this software on it, why don't they dump the firmware flash storage and decompile the actual images, wherever they might be', though it may be they indeed didn't have access to any such hardware or firmware downloads and are just piecing random puzzle parts together, and the post eventually devolved into a general rant against OEM cleverness that I somewhat skipped. (I'm also mildly torn between 'wow, clever hack' and 'oh lord this would be terrible to diagnose OS boot issues on as you really can't trust OEMs with side effects or long-term maintenance' in this regard) [1]: https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-guide/7_driver_entry_point/711_runtime_drivers https://edk2-docs.gitbook.io/edk-ii-uefi-driver-writer-s-gui...