Ghidra Analyzer for UEFI Firmware
github.com
github.com
> Moreover, there are a lot of different technical decisions to improve stability, packaging experience, user experience, etc.
Such as?
From my minimal experience with the project, it was obvious that interpersonal conflict existed for some time between some of the R2 hackers, so I guess the charitable interpretation of the fork is that you guys for some reason couldn't stand hacking together with Pancake (the creator). I think that being honest about that would have conveyed more credibility than the shady way the fork was executed, full of corporatey PR-speak and overproduced Web pages.
1. Removal of the unstable, unmaintained code - e.g. WebUI, filesystems mounting (it was based on the ancient GRUB code).
2. Migrating from the copy-pasted code to using Meson subprojects, which made the update easier and packaging effortless.
3. Continuing to use the newshell (tree-sitter-based parser) instead of every command parsing itself manually (old code used giant switch cases that parsed arguments independently for every separate command basically).
4. Not in the FAQ but also the removal of `r_core_cmd()` calls that were calling the commands directly in the code instead of using proper APIs. It's still work in progress but we removed almost a half of such calls and will continue until 99% of them are removed.
5. We also focus on better performance and general ease of use as a library - better code documentation, better APIs, unit and API integration tests.
6. While Projects existed in the original project they were just a sequence of the commands, while Rizin migrated to the completely different concept of snapshot serialization and storing it as a KV (Key-Value) database.
If you compare the code the difference compounded significantly already.
The short version is that, unless you have a corporate contract with Intel, there is so much randomness involved that the time and effort necessary to get it working are probably not worth it.
The main challenge is finding a compatible motherboard. There are three main factors that need to align for a given board to work:
1. The CPU XDP (Extended Debug Probe, includes JTAG) lines need to be routed to the chipset. Because you're actually talking to the chipset via DCI (it's the one that manages the USB ports), if they aren't, you'll only be able to access the chipset in your debugging session (i.e. you'll have no access to the typical debugging stuff that you're probably after), which, without Intel's keys to unlock Yellow and Red mode, isn't super interesting (though I would like to look into it more . . .). It's extremely difficult to guarantee a given board has these routed before getting your hands on it; I wasted some money on a few that didn't. Your best bet is if you can find a schematic buried somewhere on the internet, although even then, this is a part of the board that's likely to change between revisions without notice.
2. You'll want the BIOS to "support" enabling DCI -- In quote marks because I've never encountered one that will just let you do it through the GUI. Instead, most of the time you'll wind up modifying a non-volatile UEFI configuration bank for something called Intermediate Forms Representation (IFR), which is a format that Intel's Firmware Support Package (FSP) uses to store the BIOS configuration options. (Most BIOS GUIs are just skins on top of this.) There are a few options you need to flip in here, so you'll need to use an IFR extractor on your particular BIOS to recover the offsets and such for the appropriate options; once you have them, you'll use something like RU.efi to actually twiddle the bits. It's worth noting that not every BIOS uses this approach. I can't recall who it was, but there was at least one vendor whose BIOS didn't contain any IFR. In that case, you'll likely need to patch the BIOS directly -- an enormously complicated task, worthy of another post. I developed a successful patch once, which would have worked were it not for the third factor . . .
3. The chipset must be configured to serve DCI over a particular USB port. This is the factor I know the least about. There were a few boards I found that were _very_ finicky about which ports they would serve. Obviously, at the bare minimum, you have to connect to a port served _directly_ by the chipset, but it seems that there are factors even beyond that. Perhaps they are configurable in firmware, or maybe they are programmed in eFuses in the chipset -- I'm not sure. In any case, be sure to try all of the available ports, including USB-C. There was one board where I got everything else working, but none of the ports let me in -- absolutely infuriating.
All in all, I evaluated several dozen boards (looking for schematics, downloading and reversing BIOSes) and purchased eight; of those, two worked. The first was a Dell Precision 5520, and the second was a Asus TUF Z370 Plus Gaming. I couldn't get a 8th Gen Intel NUC working (it was behaving as though the CPU wasn't connected, which is odd considering the chipset and CPU are integrated onto one die).
Once you have a board, you'll need Intel System Debugger. (This was previously packaged with Intel's free version of System Studio, but I've heard rumblings that, as of just recently, this is no longer the case.) This part is pretty straight forward -- the documentation should have you covered.
This was definitely one of my favorite projects, but if you're looking for a simple debugging solution, this ain't it.
As an outsider who is interested, what's the best source to read about Intel's Yellow & Red modes, and its toolchain (which I is analogous to AMD's)? I've always felt that this is the level in which "the way things work" goes from being well-documented and google-able to "leet hax0rz", accessible only behind corporate NDAs – very complex, very hard to read about, and rather hidden. Of course, this could be just my ignorance talking – but I want to learn! IME seems complex and hidden enough!
Unfortunately we (the public) know very little about Yellow and Red. (Most of the time it's just called "Red" and "Red Unlock", because Red is a superset of Yellow and most conceivable exploits that could elevate to Yellow would also elevate to Red.)
[1] is a great place to start. It's a tiny bit out of date now (DAL was deprecated a while ago in favor of . . . IPC, I think it's called?). Check out Mark Ermolov's (one of the author's) Twitter [2] for some interesting developments -- he has Red unlock on a Goldmont Atom core via a cool exploit that he published (that has since been patched), leading to microcode (!) readout. (On a side note, I strongly suspect that he has some form of inside information -- there have been times where he knows some facet of the chipset internals that I can't find _any_ reference to online. I don't mean to diminish his work though; it's very cool stuff.)
Another good place to learn is the leak from last summer, referred to as "Ex-confidential lake." It doesn't contain anything damning, but skimming through it, especially the boot/bringup stuff, will help familiarize you with the terminology and also serves as a good reference if you have to dig through a compiled BIOS -- the leak contains the FSP source.
[4], a BlackHat talk, and [5], Intel's response/analysis, are super interesting. You'll definitely have to read them over a few times!
[6] is another great talk from Ermolov that also discusses Red unlock.
Finally, one of my favorite "tricks" is to just google for "<term> "Intel Confidential" filetype:pdf". You'll turn up a surprising amount of internal info that way.
In short, you need to do _a lot_ of research. I spent nearly an entire month just searching the internet for more information. A fun, endless mystery to solve!
(P.S. I'm not sure if you realize this, but it confused me initially: Chipset == Platform Controller Hub (PCH) != Management Engine (ME). The chipset/PCH is the whole piece of silicon that runs the system, whereas the ME is only the small processor core inside of there that performs some higher level operations such as booting and maintaining a root of trust. The PCH has a lot of cool stuff outside the ME!)
(P.P.S. If you're looking for something a bit easier to get started on, but also interesting and impactful, there's a lot of undocumented stuff going on in the PCRs -- the Platform Configuration Registers. It's partially documented in part 2 of the chipset datasheets, but there are a lot of fields that are readable/writable without any description. I wrote some very basic tools relating to it here [7] and here [8]. If you do something interesting with it, I'd love to hear: shoot me an email at my github username at gmail.)
[1]: https://conference.hitb.org/hitbsecconf2017ams/materials/D2T...
[2]: https://twitter.com/_markel___
[3]: https://web.archive.org/web/20190924162111/http://support.pr...
[4]: https://i.blackhat.com/USA-19/Wednesday/us-19-Hasarfaty-Behi...
[5]: https://www.intel.com/content/dam/www/public/us/en/security-...
[6]: https://i.blackhat.com/asia-19/Thu-March-28/bh-asia-Goryachy...
[7]: https://github.com/pcgrosen/pcredit
[8]: https://github.com/pcgrosen/pychipset/blob/master/chipset/pc...