Firmware exploitation with PNF Software’s JEB

PNF Software has a series of blog posts on how to use their JEB product to reverse firmware:

Firmware Exploitation with JEB:

In this series of blog posts I will show how JEB’s MIPS decompiler 1 can help you find and exploit software vulnerabilities in embedded devices. To do so, we will use Praetorian’s Damn Vulnerable Router Firmware (DVRF) written by b1ack0wl. DVRF is a custom firmware made to run on a Linksys E1550 router containing a bunch of memory corruption vulnerabilities. The goal of the DVRF is to serve as a playground to learn exploitation on the MIPS architecture. As far as I know, there are no write-ups of the challenges on the Internet. For the readers interested in testing the challenges by themselves, I suggest to follow the DVRF tutorial, and getting a complete MIPSEL Debian QEMU image as it allows the usual exploit development workflow on Linux, without any limits on the available tools.[…]





PyREBox is a Python scriptable Reverse Engineering sandbox. It is based on QEMU, and its goal is to aid reverse engineering by providing dynamic analysis and debugging capabilities from a different perspective. PyREBox allows to inspect a running QEMU VM, modify its memory or registers, and to instrument its execution, by creating simple scripts in python to automate any kind of analysis. QEMU (when working as a whole-system-emulator) emulates a complete system (CPU, memory, devices…). By using VMI techniques, it does not require to perform any modification into the guest operating system, as it transparently retrieves information from its memory at run-time. Several academic projects such as DECAF, PANDA, S2E, or AVATAR, have previously leveraged QEMU based instrumentation to overcome reverse engineering tasks. These projects allow to write plugins in C/C++, and implement several advanced features such as dynamic taint analysis, symbolic execution, or even record and replay of execution traces. With PyREBox, we aim to apply this technology focusing on keeping the design simple, and on the usability of the system for threat analysts.



Alex updates smmtestbuildscript for Fedora 26 and QEMU 2.9

A while ago[1], Alex Floyd of PreOS Security wrote a shell script to help codify this wiki article[2] by Laslo Ersek of Red Hat, setting up a UEFI SMM/OVMF testing environment for Fedora-based systems. Recently, Alex updated this script to work with the recently-released Fedora 26. Quoting email from Alex on the changes in this release:

The build script has been updated for Fedora 26 support. It now uses the native QEMU 2.9 library from Fedora 26 and no longer builds a snapshot of QEMU 2.9 which makes some new testing possibilities available.


[1] https://firmwaresecurity.com/2017/04/19/shell-script-for-laszlos-smm-test-environment-article/

[2] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt



UEFI/SMM stability and performance improvements in QEMU 2.9 and edk2/OVMF git 296153c5, included with Fedora 26

Fedora 26 just released, and it ships with QEMU v2.9 and an updated OVMF, which adds SMM security improvements. Quoting email from Laszlo Ersek of Red Hat:

QEMU 2.9 is part of Fedora 26. The full changelog for QEMU 2.9 is here:


The broadcast SMI feature is just one tiny line in the huge list (and it only mentions the generic negotiation feature, not the specific broadcast one):

“The q35 machine type offers SMI feature negotiation to interested guest firmware.”

QEMU v2.9 is important for running the SMM driver stack of edk2 — more precisely, machine type “pc-q35-2.9” is important — because it offers negotiable SMI broadcast, i.e., where one VCPU writes to ioport 0xB2, and the SMI is raised synchronously on all VCPUs. See:

https://bugzilla.redhat.com/show_bug.cgi?id=1412313 [ovmf]
https://bugzilla.redhat.com/show_bug.cgi?id=1412327 [qemu]

QEMU v2.10 — more precisely, machine type “pc-q35-2.10” — will bring another SMM-related improvement, although not as critical as SMI broadcast. (And I guess it will be available in Fedora 27.) We call it “extended TSEG”, and it allows the QEMU user to specify more than 8MB SMRAM on the cmdline. This is important if you have a huge number of VCPUs, or huge guest RAM (into the TB range) because those things have a linearly growing SMRAM footprint (albeit with small constant factors). See:

https://bugzilla.redhat.com/show_bug.cgi?id=1447027 [qemu and ovmf, both committed]
https://bugzilla.redhat.com/show_bug.cgi?id=1469338 [libvirt, under design]

The patches (qemu and ovmf) committed for BZ#1447027 above solve the “many VCPUs” question. The “huge guest RAM” question needs more platform code in OVMF; the patch for that is on edk2-devel, pending review:

https://bugzilla.redhat.com/show_bug.cgi?id=1468526 [ovmf, pending review]

More info:


VM escape – QEMU case study on Phrack


I wish more people wrote articles for Phrack.


Shell script for Laszlo’s SMM test environment article

Laszlo Ersek of Red Hat wrote a wiki article on tianocore.org[1], showing how to setup the EDK2 with QEMU/OVMF for testing SMM code using Fedora.

Recently, Alex Floyd of PreOS Security wrote a shell script to codify this wiki article[2].

Laszlo’s wiki is dense, I expect this script will be useful for some UEFI firmware engineers and security researchers.

According to Alex, “some things needed tweaking to get to work, and the Windows portion of the tutorial is not included in the script.”

[1] https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt

[2] https://github.com/gencymex/smmtestbuildscript