Command Line Alias Attacks against Windows

Seeing the below tweet about, I wonder if anyone has done security testing against UEFI’s variables and shell aliases, similar to current attacks against the NT, the successor to OS/2, which also has console APIs (and variables).

Like Windows, UEFI also has command line shell alias command and API (part of the UEFI Shell protocol). UEFI was created back when the state-of-the-art of systems interfaces from Microsoft was OS/2 1.x, and one of the initial EFI developers was previously doing OS/2 1.x console API coding.

ARM adds ACPIView tool to UEFI Shell: dump ACPI tables

For UEFI Shell uers, there is another ACPI diagnostic tool, in addition to CHIPSEC and acpidump. Excerpts of edk2-devel mailing list post and tool manpage below, see full list posting for source code and more info.

ShellPkg: Add acpiview tool to dump ACPI tables
This program is provided to allow examination of ACPI table contents from the UEFI Shell. This can help with investigations, especially at that stage where the tables are not enabling an OS to boot. The program is not exhaustive, and only encapsulates detailed knowledge of a limited number of table types. Default behaviour is to display the content of all tables installed. ‘Known’ table types will be parsed and displayed with descriptions and field values. Where appropriate a degree of consistency checking is done and errors may be reported in the output. Other table types will be displayed as an array of Hexadecimal bytes. To facilitate debugging, the -t and -b options can be used to generate a binary file image of a table that can be copied elsewhere for investigation using tools such as those provided by This is especially relevant for AML type tables like DSDT and SSDT. The inspiration for this is the existing smbiosview Debug1 Shell command. Many tables are not explicitly handled, in part because no examples are available for our testing. The program is designed to be extended to new tables with minimal effort, and contributions are invited.

Display ACPI Table information.

ACPIVIEW [[-?] | [[-l] | [-s AcpiTable [-d]]] [-c] [-v] [-h Highlight]]
-l – Display list of installed ACPI Tables.
-s – Display only the specified AcpiTable type.
AcpiTable : The required ACPI Table type.
-d – Generate a binary file dump of the specified AcpiTable.
-c – Consistency checking (enabled by default).
-v – Display verbose data (enabled by default).
-h – Enable/Disable Colour Highlighting.
Highlight : TRUE/ON enables highlighting;
FALSE/OFF (default) disables highlighting.
-? – Show help.

Formatted display and checking is provided for these signature types:
APIC – Multiple APIC Description Table (MADT)
BGRT – Boot Graphics Resource Table
DBG2 – Debug Port Table 2
FACP – Fixed ACPI Description Table (FADT)
GTDT – Generic Timer Description Table
IORT – IO Remapping Table
MCFG – Memory Mapped Config Space Base Address Description Table
RSDP – Root System Description Pointer
SLIT – System Locality Information Table
SPCR – Serial Port Console Redirection Table
SRAT – System Resource Affinity Table
XSDT – Extended System Description Table


To display a list of the installed table types:
fs0:\> acpiview -l

To parse and display a specific table type:
fs0:\> acpiview -s GTDT

To save a binary dump of the contents of a table to a file in the current working directory:
fs0:\> acpiview -s DSDT -d

To display contents of all ACPI tables:
fs0:\> acpiview

Finbarr’s TPM 2.0 PCR Tool

Finnbarr P. Murphy has a new blog post about a new UEFI-based TPM tool he’s written.

[…]By the way, if you have access to the Intel TXT (Trusted Execution Technology) EFI compliance testing toolkit, the included utility, pcrdump.efi, provides similar functionality to the utility described in this post.[…]

See more of his UEFI Utilities:

FPMurphy on TPM access via UEFI

Finnbarr P. Murphy does not blog often, but each post is usually very well written, and often focused on using some UEFI Shell commands to do some specific task. In the current post, the topic is accessing TPM’s features from the UEFI Shell, and it is called “part 1”, with more to come!

“Why an I writing this series of posts? Because there are few published examples of working UEFI code that interacts with a TPM. Such example code is useful to security researchers and computer forensics practitioners.”

new tool: Visual UEFI for Windows

Alex Ionescu just created a new project to help with Visual Studio / EDK-II integration.

Excerpting from it’s readme, VisualUEFI is 3 things:

1) a Solution and set of Visual Studio 2015 Project Files to allow building the official EDK-II without the use of inf files, Python and 50 other build tools, a custom dependency tracker and build system, and twenty other custom pieces of code. The EDK-II is present as a submodule, directly from the official TianoCore Tree, and no changes are done to it.
2) a Solution and couple of Visual Studio 2015 Project Files to show two UEFI sample components: A UEFI Application, and a UEFI Boot Driver. The code is 100% EDK-II compatible, but built with VisualUEFI instead.
3) a working copy of QEMU64 2.3 for Windows, with a fairly recent UEFI 2.5 OVMF Secure Boot ROM. These will updated on an ongoing basis as needed. This is integrated with the Visual Studio 2015 Sample Solution so that pressing F5 will spin up the instance for testing.

You should be able to open the EDK-II.SLN file and build without any issues in Visual Studio 2015. WDK or other 3rd party installations are not needed. Once the EDK-II libraries are built, you should be able to open the SAMPLES.SLN file and build the two samples, which will create UefiApplication.efi and UefiDriver.efi.

You can press F5 (Run/Debug) from within the Sample Solution, which should spin up the QEMU instance with 512MB of ram, and your release directory as a virtual file system accessible through “fs0:”. You can then try loading the driver with “Load fs0:\UefiDriver.efi”. You can verify its presence by using the Drivers or DevTree commands.

Visual UEFI looks like a nice improvement to Microsoft’s Visual Studio IDE. Thanks, Alex!

(This is the kind of thing I kept expecting the UEFI Forum to release, as an Eclipse plugin, like Yocto and some related projects have done.)


[UDPATE: comment from a smart reader:
AMIDebug technology is not useful for end users and researchers because it’s support should be specifically compiled in in a special DEBUG build. The AMI DebugRX hardware part is OK to get port 80h codes via USB, mediocre source-level debugging. Intel XDP or Arium-ITP are similar to AMIDebug, both nice products, and don’t require any firmware changes or special build modes.
BTW, I don’t know why Comments don’t show up on blog web site, working on trying to fix that… ]

Earlier this week AMI announced USB3 support for their AMIDebug for UEFI product.

Apparently AMI has 3 versions of this: 1) AMIDebug for UEFI software for Aptio V, 2) the AMIDebug Rx handheld USB debug device, and 3) Aptio V UEFI Firmware from AMI.

Press release excerpts:

American Megatrends, Inc. (AMI), a global leader in BIOS, remote management, network data storage products and solutions for the Android(TM) operating system, is pleased to announce support for USB 3.0 controllers in the latest release of its AMIDebug(TM) for UEFI debugging solution for Aptio(R) V UEFI Firmware.

AMIDebug for UEFI from American Megatrends is a powerful software-based solution for debugging UEFI projects based on Aptio or the UEFI Shell, offering source-level symbolic (C and Assembler) debugging without the need for expensive JTAG hardware debug tools.

The latest AMIDebug for UEFI release, developed specifically for the company’s flagship Aptio V UEFI Firmware, adds support for USB 3.0 debug among other important features. These newly-added features signify a key development in the evolution of this debug software, since many chipsets now only support USB 3.0 (XHCI) and in many cases no longer incorporate older USB standards (EHCI) in their hardware designs, such as the Intel(R) Atom(TM) x5-Z8300 series processors.

What remains unchanged in AMIDebug for UEFI is its ability to facilitate firmware development for AMI OEM and ODM customers in unprecedented ways thanks to its deep integration into the entire UEFI development ecosystem. AMIDebug for UEFI continues to offer standard debugging features like Break, Step, Step Over, Step Into, Step, run to cursor and set next statement, in addition to UEFI-specific debugging features like Stop at Driver Name Entry, Stop at PEIM Name Entry, Stop at CheckPoint, Stop at beginning of PEI/DXE, SMM Debugging and disassembly view. Moreover, many different firmware development viewers are supported including memory, CPU registers, PCI Bus, call stack, I/O and Indirect I/O.

Sigh, I wish these were available for UEFI ISVs and UEFI Security Researchers, not just restricted to AMI’s UEFI OEM/ODMs! I want one. 😦

More Information:

CHIPSEC v1.2.0 Released

The Intel CHIPSEC team just posted the latest version of CHIPSEC, 1.2.0. Release notes excerpt below, see the full text on the github site, with known issues:

New/updates modules:
* Merged common.secureboot.keys module into common.secureboot.variables module
* Updated tools.secureboot.te module to be able to test PE/TE issue on Linux or UEFI shell
* Updated tools.smm.smm_ptr module

* Added the *controls* abstraction. Modules are encouraged to use “get_control“ and “set_control“ when interacting with platform registers. This permits greater flexibility in case the register that controls a given feature or configuration changes between platform generations. The controls are defined in the platform XML file. At this time, only a small number of controls are defined. We plan to move existing modules over to this new mechanism.
* Added XML Schema for the XML configuration files
* Support for reading, writing, and listing UEFI variables from the UEFI Shell environment has been added.
* Added support for decompression while SPI flash parsing via “decode“ or “uefi decode“ commands in Linux
* Added basic ACPI table parsing to HAL (RSDP, RSDT/XSDT, APIC, DMAR)
* Added UEFI tables searching and parsing to HAL (EFI system table, runtime services table, boot services table, DXE services table, EFI configuration table)
* Added DIMM Serial Presence Detect (SPD) ROM dumping and parsing to HAL
* Added “uefi s3bootscript“ command parsing the S3 boot script to
* Added virtual-to-physical address translation function to Linux/EFI/Windows helpers
* Added support of server platforms (Haswell server and Ivy Town) to

More Information:

Ruby for UEFI

In addition to UEFI Shell scripts, Python, and Lua, you can also use Ruby to write code for UEFI.

Mruby is the Ruby compiler that was ported to UEFI. “mruby is the lightweight implementation of the Ruby language complying to (part of) the ISO standard. Its syntax is Ruby 1.9 compatible.

Mruby on EFI Shell is a mruby port to the UEFI Shell, ported by Masamitsu Murase. With mruby.efi, you can call UEFI BootTime and RunTime Services, and access UEFI data structures. For some nice examples, look at the home page of the project.

To build mruby for EFI Shell, look at the readme on the sources, you need to create a new subdirectory in the EDK-II AppPkg for it. Once built, you need to copy mruby.efi onto your UEFI System Partition (ESP) so you can access it via the UEFI Shell. From the UEFI Shell, sample usage is:

    mruby.efi hello.rb

This has been around for about 3 years, but I only noticed it a few weeks ago.

More Information: