In my Hardwear.io training ["x86-64 Intel Firmware Attack & Defense"] and OpenSecurityTraining2 [Arch4001] class, as we deep-dive into how an OS-resident attacker can attempt to rewrite the SPI flash chip where the UEFI BIOS lives, we stop at the Intel Memory Mapped Input/Output (MMIO) interface;a special memory range containing registers which if poked in just the right way, causes reads and writes to the SPI flash chip to magically happen. But wouldn't it be nice to see what's behind the magic, and sniff the actual SPI commands that are issued on the SPI bus by the Intel hardware to the SPI flash chip? In this workshop we go down to that level!
In this class we'll use Saleae logic analyzers to connect to the SPI flash chip and see
Seating for this class is limited due to a limited number of Saleae logic analyzers. But if you bring your own Saleae you're much more likely to be admitted. There will also be a limited number of observation-only seats available at the back of the class.
For this class you will need to bring two systems: one to run the logic analyzer software on, and the target system that will have its SPI transactions analyzed. The target system must either be running Windows or be capable of running a UEFI shell, as those will be the only supported environments for issuing SPI MMIO reads/writes. A recommended target system is noted in the below sign up survey, which will make the class go more smoothly for you. The recommended system also has the bonus that it is vulnerable to the Positive Technologies CSME exploit that unlocks CSME JTAG debugging, incase you want to play with that in the future (which may be a future hardwear.io workshop as well.)
Xeno began leading Windows kernel-mode rootkit detection and defense research projects at MITRE in 2009, before moving into research on BIOS security in 2011. His team's first public talks started appearing in 2013, which led to a flurry of presentations on BIOS-level vulnerabilities up through 2014. In 2015 he co-founded LegbaCore. And after presenting a firmware worm that could spread between Macs via Apple's EFI-based BIOS and Thunderbolt Ethernet adapters, he ended up working for Apple. There he worked on securing all the lesser-known firmwares on Macs and peripherals - everything from 3rd party GPUs to SecureBoot for monitors! He worked on the x86-side of the T2 SecureBoot architecture, and his final project was leading the M1 SecureBoot architecture - being directly responsible for designing a system that could provide iOS-level security, while still allowing customer choice to trust arbitrary non-Apple code such as Linux bootloaders. He left Apple in Dec 2020 after the M1 Macs shipped, so he could work full time on OpenSecurityTraining2.