Moving from Common-Sense Knowledge About UEFI to Dumping UEFI Firmware | Hacker News Reader

Moving from Common-Sense Knowledge About UEFI to Dumping UEFI Firmware

labs.sentinelone.com

63 pointszdw7 comments

UEFI Firmware Engineer here. Always happy to see the domain get a bit more mainstream exposure. The part of this article that stuck out to me was the off-hand comment about the number of people who could raise their hand that have experience with UEFI firmware. It is an incredibly small industry with some huge players. You go to firmware conferences sponsored by Intel, ARM, IBM, Microsoft, Apple, among others and it's the same few hundred people just switching companies.

I've tried to get in UEFI development before but it was such a pain. Specifically, trying to read the edk2 docs was a pain as they seem to not be updated (the most accessible docs were referencing rather old Ububtu and gcc versions and I was even finding references to Visual Studio 2003). I also managed to find a bug in the project scaffolding tool they provide but I couldn't find a way to report bugs and I didn't bother fixing a submitting a PR because the last commit was 8 years old and there wasn't a sign that anyone else had ever done so.

> You go to firmware conferences sponsored by Intel, ARM, IBM, Microsoft, Apple, among others and it's the same few hundred people just switching companies.

Can't speak specifically to UEFI firware stuffm, but my experience with similar domains (that have a small number of really smart, but primarily professional members) is that they don't tend to be very "welcoming" to beginners.

Yeah the docs have been a sort of pain for quite a few folks. We had some new team members join our team and revealed how much of our process is focused on being next to someone to ask questions while you're trying to figure out how to make your project boot. Part of the problem comes from the fact that until fairly recently, UEFI didn't have a great emulated platform so you could build stuff but unless you had the exact hardware (that often comes with NDA code that can be hard to get a hold of), tutorials are not very helpful/rewarding.

Yah, lots of communities have established rules and even as a relative newcomer myself, getting something into EDK2 is a long and somewhat arduous process. They don't accept PRs, it's all over mailing lists.

https://microsoft.github.io/mu if you're curious about

Serious question.

Why are we still using UEFI?

From an end-user perspective, Coreboot+$PAYLOAD >> UEFI.

Do most people have to go through all of this ceremony or is there typically a JTAG port on a motherboard that will do the trick?

Depends on the context.

If you want direct access to the hardware, you'll typically attach IC hooks to the SPI chip itself, and read/write with flashrom. It's almost always a chunky soic-8 package.

https://libreboot.org/docs/install/c201.html#installing-libr...

>"The first in a series of posts for researchers on how to emulate, debug and fuzz UEFI modules, we begin with a refresher on how to dump SPI flash memory."

[...]

>"Because of the low-level nature of the infection, LoJax had a rather unique degree of persistence: it could survive OS reinstallation, hard-drive replacement, and most other techniques IT personnel typically use to clean infected machines.

To be able to perform the infection, LoJax first had to dump the contents of the UEFI firmware, patch it with its malicious payload, and then flash it back. Based on this description, it is quite clear that

we can acquire our own firmware simply by following the path LoJax delineated for us.

(PDS: And clean it, if it is present...)

Below is the relevant excerpt from section 4 of the whitepaper, outlining the process:

“The tool’s … task is to retrieve the BIOS region base address on the SPI flash memory as well as its size. This information is contained in the SPI Host Interface register “BIOS Flash Primary Region”. All SPI Host Interface registers are memory-mapped in the Root Complex Register Block (RCRB) whose base address can be retrieved by reading the correct PCI Configuration Register. ReWriter_read obtains this address by using RwDrv IOCTL 0x22840 and reading the correct offset (0xF0 in our case). Once the BIOS region base address and size are known, the dump tool reads the relevant content of the SPI flash memory and writes it to a file on disk.”"

Reply on news.ycombinator.com