There’s a relatively new GUI front-end to the command line-based CHIPSEC project, called CHISPEC_GUI. This GUI for chipsec 1.2.5 provides a fairly simple design but lets you select each module that you want to run. It is made with PyQt4. It is getting updated to Chipsec 1.3.0 with the appropriate module additions written into the GUI. It was originally written in Persian by Emad Helmi, and translated to English by Alex Floyd of PreOS-Security.

English version:

Forked from Persian version:

CHIPSEC 1.3.0 released

New/updated modules:
* tools.uefi.whitelist – The module can generate a list of EFI executables from (U)EFI firmware file or extracted from flash ROM, and then later check firmware image in flash ROM or file against this list of [expected/whitelisted] executables
* tools.uefi.blacklist – Improved search of blacklisted EFI binaries, added exclusion rules, enhanced blacklist.json config file
* tools.smm.rogue_mmio_bar – Experimental module that may help checking SMM firmware for MMIO BAR hijacking vulnerabilities described in “BARing the System: New vulnerabilities in Coreboot & UEFI based systems” ( by Intel Advanced Threat Research team at RECon Brussels 2017
* tools.uefi.uefivar_fuzz – The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size.

New/updated functionality:
* Debian packaging support
* Compiling in and automated loading of chipsec.kext kernel module on macOS
* Internal Graphics Device support including software DMA via Graphics Aperture
* Improved parsing andsearch within UEFI images including update capsules
* Export of extracted EFI firmware tree in JSON format
* Export of CHIPSEC results in JSON format via –json command-line argument
* EFI (de-)compression ported from uefi-firmware-parser project
* Decompression to macOS helper to parse Mac EFI firmware images
* Support of command-line arguments in
* SMI count command
* Improved platform dependent Flash descriptor parsing
* ReadWriteEverything helper to work with RWE driver
* map_io_space to improve SPI read performance on Linux
* Native (OS based) access PCI, port I/O and CPU MSR to Linux helper
* Improved unit testing

See full announcement for list of bugfixes.


CHIPSEC gets new MMIO BAR module

Experimental module that may help checking SMM firmware for MMIO BAR hijacking
vulnerabilities described in the following presentation:
`BARing the System: New vulnerabilities in Coreboot & UEFI based systems <;`_ by Intel Advanced Threat Research team at RECon Brussels 2017
  “chipsec_main -m tools.smm.rogue_mmio_bar [-a <smi_start:smi_end>,<b:d.f>]“
– “smi_start:smi_end“: range of SMI codes (written to IO port 0xB2)
– “b:d.f“: PCIe bus/device/function in b:d.f format (in hex)
    >>> -m tools.smm.rogue_mmio_bar -a 0x00:0x80
    >>> -m tools.smm.rogue_mmio_bar -a 0x00:0xFF,0:1C.0


CHIPSEC gets new UEFI Whitelist command

CHIPSEC already has a Blacklist command. Now there is a UEFI whitelist command.

McAfee on CHIPSEC, post Vault7

“EFI firmware malware is a new frontier for stealth and persistent attacks which may be used by sophisticated adversaries to penetrate and persist within the organization’s and national infrastructure for very long time. Use open source CHIPSEC to defend from this threat and stay safe.”

UEFI lab at Cascadia IT Conference in Seattle March 10th

[DISCLAIMER: FirmwareSecurity is my personal blog. I work at PreOS Security.]

PreOs Security is offering a half-day training lab for System Administrators, SRE/DevOps in the Seattle area at Cascadia IT Conference, for those interested in learning about UEFI/ACPI/BIOS/SMM/etc security. Here’s the text for the training:

Defending System Firmware

Target audience: System administrators, SRE, DevOps who work with Intel UEFI-based server hardware

Most enterprises only defend operating system and application software; system and peripheral firmware (eg., BIOS, UEFI, PCIe, Thunderbolt, USB, etc) has many attack vectors. This workshop targets enterprise system administrators responsible for maintaining the security of their systems. The workshop is: an introduction to UEFI system firmware, an overview of the NIST secure BIOS platform lifecycle model of SP-(147,147b,155) and how to integrate that into normal enterprise hardware lifecycle management, and an introduction to the available open source firmware security tools created by security researchers and others, and how to integrate UEFI-based systems into the NIST lifecycle using available tools, to help protect your enterprise. It will be a 3.5 hour presentation, and at the end, you can optionally can run some tests on your laptop: Intel CHIPSEC, Linux UEFI Validation distribution (LUV-live), FirmWare Test Suite live boot distribution (FWTS-live), and a few other tools. Attendees trying to participate in the lab will need to have a modern Intel x86 or x64-based (not AMD), UEFI-based firmware, running Windows or Linux OS software. That means no AMD systems, no Apple Macbooks, no ARM systems. Any system used in the lab must have all data backed up, in case some tool bricks the device. Attendees should understand the basics of system hardware/firmware, be able to use a shell (eg, bash, cmd.exe, UEFI Shell), and able to use Python-based scripts.

CHIPSEC gets UEFI variable fuzzer

The module is fuzzing UEFI Variable interface. The module is using UEFI SetVariable interface to write new UEFI variables to SPI flash NVRAM with randomized name/attributes/GUID/data/size. Note: this module modifies contents of non-volatile SPI flash memory (UEFI Variable NVRAM). This may render system unbootable if firmware doesn’t properly handle variable update/delete operations.
    “chipsec_main -m tools.uefi.uefivar_fuzz [-a <options>]“
    “[-a <test>,<iterations>,<seed>,<test_case>]“
    – “test“        which UEFI variable interface to fuzz “(all, name, guid, attrib, data, size)“
    – “iterations“    number of tests to perform (default = 1000)
    – “seed“        RNG seed to use
    – “test_case“    test case # to skip to (combined with seed, can be used to skip to failing test)
    All module arguments are optional
>>> -m tools.uefi.uefivar_fuzz
>>> -m tools.uefi.uefivar_fuzz -a all,100000
>>> -m tools.uefi.uefivar_fuzz -a data,1000,123456789
>>> -m tools.uefi.uefivar_fuzz -a name,1,123456789,94


IGD command added to CHIPSEC

The igd command allows memory read/write operations using igd dma.
>>> chipsec_util igd
>>> chipsec_util igd dmaread <address> [width] [file_name]
>>> chipsec_util igd dmawrite <address> <width> <value|file_name>
>>> chipsec_util igd dmaread 0x20000000 4
>>> chipsec_util igd dmawrite 0x2217F1000 0x4 deadbeef

CHIPSEC gets efi_compressor

(I haven’t looked at this patch yet, but I hope it’s a Python native version, since CHIPSEC used Linux/Windows/UEFI native versions of external compress/decompress tools, and it would be nice to have a pure Python version, compression and decompression. If you want to better trust CHIPSEC,in addition to reviewing it’s source code, you also have to deal with the compress/decompress blobs and CPython for UEFI blobs that it ships, and have to build your own versions. I think I noticed a few Microsoft Windows Win32 .exe files embedded inside that UEFI CPython release, which should not be there.)


CHIPSEC talk at OPCDE 2017

Exploring Your System Deeper
 Oleksandr Bazhaniuk – Intel – United States

You wanted to explore deep corners of your system but didn???t know how? System boot firmware, ROMs on expansion cards, I/O devices and their firmware, microprocessors, embedded controllers, memory devices, low-level hardware interfaces, virtualization and hypervisors. You could discover if any of these have known vulnerabilities, configured insecurely or even discover new vulnerabilities and develop proof-of-concept exploits to test these vulnerabilities. Ultimately, you can verify security state of platform components of your system and how effective are the platform security defenses: hardware or virtualization based TEE, secure or trusted boot, firmware anti-tampering mechanisms, hypervisor based isolation… Or maybe you just want to explore hardware and firmware components your system has. CHIPSEC framework can help you with all of that. Since releasing it three years ago at CanSecWest 2014 significant improvements have been made in the framework – from making it easy to install and use to adding lots of new security capabilities. We’ll go over certain representative examples of what you can do with it such as finding vulnerabilities in SMM firmware, analyzing UEFI firmware vulnerabilities, testing hardware security mechanisms of the hypervisors, finding backdoors in UEFI images and more.

CHIPSEC v1.2.5 published!

This version has packaging, which I think was originally introduced by the GRR fork of CHIPSEC. This means you can do “pip install chipsec” on some systems. It will require a compiler toolchain to build and install the kernel driver, which is a bit more than you’d expect from a normal pip Python package install… 🙂

Unclear of all the other changes yet:

CHIPSEC ported to ARM??


Intel CHIPSEC is — or at least was —  Intel-specific. Actually it may be called McAfee CHIPSEC now? Anyway, it did not work on ARM. Via Linaro, ARM Ltd. was in the process of porting LUV (Linux UEFI Validation) distro to AArch64, and LUV includes CHIPSEC, so that was on the list, but AFAIK Linaro had not yet started to port CHIPSEC to ARM yet.

So the above screenshot is news to me, and very exciting. I hope we get more news about this soon!! AND a source check-in (currently nothing in repo)… 🙂



CHIPSEC gets QEMU VirtIO device detection

“Just added detection of QEMU VirtIO devices by @mikhailgorobets & @c7zero. Use “ vmm virtio” command”

new CHIPSEC test for Xen XSA-188

Proof-of-concept module for Xen XSA-188 (
CVE-2016-7154: “use after free in FIFO event channel code”
Discovered by Mikhail Gorobets
This module triggers host crash on vulnerable Xen 4.4
“ -m tools.vmm.xen.xsa188“

Alex leaves Intel ATR!

Wow, Alex Matrosov is leaving Intel Advanced Threat Research (ATR).

As I understand it, he is one of the CHIPSEC team. I hope the project can handle his loss.

It is unclear what he’ll be doing next. Maybe he’ll be joining Apple?  They are hiring all the great researchers…)