
Moving from Common-Sense Knowledge About UEFI to Dumping UEFI Firmware - zdw
https://labs.sentinelone.com/moving-from-common-sense-knowledge-about-uefi-to-actually-dumping-uefi-firmware/
======
matthewfcarlson
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.

~~~
non-entity
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.

~~~
matthewfcarlson
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](https://microsoft.github.io/mu) if you're
curious about

------
peter_d_sherman
>"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.”"

