Exploring Universal Flash Storage (UFS) Write Protection on the HiKey960

This post explores the potential of a do-it-yourself root of trust on the HiKey960 using UFS hardware write protections. The 960 version has an onboard Universal Flash Storage (UFS) devices, the future of MMC, and much faster! UFS as a standard has existed since 2011, but seems only since 2017 they were generally obtainable. Support in Linux has experienced very-recent updates (4.15+).

The unfortunate news is I have not found a way to implement an open-source/do-it-yourself Root of Trust on the HiKey960. I will explain why during this post, but this post will focus more on UFS write-protection.

Read More

Online filesystem or disk changes on embedded hardware

This is a tiny log of my experience expanding an `ext4` filesystem on an embedded system that had no alternate boot option. This situation is very nuanced. If you are here because you need to make filesystem or disk changes your best course of action is to boot from a LiveUSB/CD.

I moved very fast when making theses changes. There may be an easier and more efficent method, if you know one, please reach out to me!

Goal: Unmount the root filesystem and make structural changes without rebooting.

Read More

DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey

DIY Root of Trust using ARM Trusted Firmware on the 96Boards Hikey

This is a series of notes designed to be a walkthrough on how to configure the HiKey Kirin 620 to boot securely with ARM Trusted Firmware's Trusted Board Boot. This does not use any proprietary settings or vendor-specific details about the SoC. Instead, the secure boot path relies on the SoC's BOOT_SEL configured to boot solely from the eMMC. With this configuration there should be no way to interrupt or bypass the root of trust via runtime changes.

Pay special attention to the should as this is not speaking from authority but rather from suspicion and research.

The Root of Trust (ROT) begins in the BL2 programmed to the eMMC's boot0 partition. The bootrom must execute the HiKey's l-loader.bin and ARM-Trusted-Firmware's (ATF) bl2.bin written to this alternate boot partition. The eMMC's extended CSD register 173 (BOOT_WP) is written to permanent write-protect this content. This is a 1-time program operation that has the potential to brick the device.

Read More

Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4

Exploring secured boot on the Sabre Lite i.MX6S (v1.3) SBC and NXP HABv4

This document is a linear review of my notes taken while exploring the Sabre Lite single-board-computer. It is a mildly expensive ($200 from Boundary Devices) SBC but it has a well documented secure boot implementation rooted in silicon ROM. It is a very good example of a vendor proprietary firmware verification mechanism. The goal of this article is purely an overview of notes, nothing here is novel or groundbreaking and it is not intended to be a tutorial.

Read More

Hands on Introduction to ARM Firmware using the 96Boards HiKey

Hands on Introduction to ARM Firmware using the 96Boards HiKey

This ARM Cortex-A53, 8-core, 2GB DDR3, board is amazing! I'm an entry-level ARM security enthusiast and this board feels like the perfect starting place for TrustZone and a secure/verified boot research.

Hikey supports the ARM Trusted Firmware and OP-TEE reference specifications so we can *clone* from Github, compile, and flash rather effortlessly. We can write the secure 'ROM', secure world operating system, and the non-trusted firmware executing in the normal world.

Read More

Minnowboard Max: Enable the firmware (TXE) TPM 2.0

Minnowboard Max: Enable the firmware (TXE) TPM 2.0

This next step will detour a bit and provide a walkthrough of UEFI platform code modifications. Pre-built firmware updates for the Minnow, in binary form, can be downloaded on it's firmware page-- as of January 10th 2016 the latest is version 0.84. The 64-bit image does not enable the TPM 2.0, whereas the 32-bit image will. I remember reading a mention in the 0.82 release notes that the 64bit disablement was related to either export controls or a licensing conflict.

Perfect! Let's use this limitation as an opprotunity to build a UEFI firmware volumn to flash onto the Minnow's SPI chip. In our volumn we will use the lastest-supported 64bit TianoCore EDKII code, the (also provided) Minnow FSF package, and enable the TPM 2.0. Unfortunately the Minnow's firmware is not 100% open but the process for slip-streaming the required binary objects is well-documented. One of the Minnow's purposes is to be a development and test platform for the UEFI EDK2 so we should assume as much TianoCore code as possible will be used in our source-built firmware.

Read More

Minnowboard Max: Booting Linux Securely

Minnowboard Max: Booting Linux Securely

Newish desktops, laptops, and other systems, might come with Secure Boot enforcement enabled; those system owners can install Ubuntu and get 'for free' a more-or-less verified boot starting with their UEFI firmware and extended all the way to their kernel. I say 'more-or-less' because there are tons of places where the verification can be subverted. Unfortunately, if you start examining the implementation and configuration details of the streamlined Secure Boot support, you'll find plenty of bypasses.

Let's talk briefly about each bypass and conclude with a simple way to use Secure Boot and enforce a signed kernel execution on Ubuntu. To be clear, there are no vulnerabilities here as there is no documented intention (e.g.,BUG/1401532) to boot Linux securely, only to support a Secure Boot and boot Linux.

Read More

Minnowboard Max: Quickstart UEFI Secure Boot

Minnowboard Max: Quickstart UEFI Secure Boot

This is the first of a collection of posts related to Intel's Minnowboard MAX development board. It begins with a barebones quick start leading to the simplest UEFI-based secure boot and paves the way towards a Secure Root of Trust Measurement (SRTM), where the "root" is the UEFI platform code.

By the end of the article the Minnowboard MAX will boot a Ubuntu 14.04 operating system using a signed shim bootloader, signed GRUB stage 2 bootloader, and signed Linux 3.xx kernel. The UEFI platform code will not be changed, meaning the out-of-the-box firmware will remain (no flashing), and any kernel modules or Linux executables will remain unsigned and unmeasured. 

Read More

Beautifying your Wireshark on macOS

Beautifying your Wireshark on macOS

Need to do some fast and crazy Wireshark hacking? Or are you using Wireshark everyday on OSX and hate the ugly default GTK styling? Let's rice Wireshark!

Step 1: Change your GTK 2.0 Theme

We'll use DG09's Lion Theme for GTK 2.0. I've made two minor changes for Mavericks.

[Preview: http://dg09.deviantart.com/art/Lion-Theme-Beta-207837762]
[Download: https://static1.squarespace.com/static/.../DG09-LionGTK.mod.tgz]

Read More

A Compendium to UEFI Hacking

A Compendium to UEFI Hacking

There are quite a few operating/execution environments running below or before an Operating System's kernel. Computer science calls protection domains "Rings" and an Operating system's kernel is called "Ring 0" or "Supervisor mode". Researchers have called the lower-level environments Ring -1 (Hypervisor mode), and Ring -3 ("system management mode"), and they are fairly apt-names. I like to bundle all of these into a scary-but-funny-and-fitting name subzero, dun dun dun!

Intel and the UEFI (Universal Extensible Firmware Interface) forum embody a really awesome subzero concept highlighted in the UEFI acronym-expansion. That is, applying standards to highly-privileged protection domains allows software engineers and vendors to take advantage of each other's development and security improvements. Never-the-less, standards and their implementation-specific variations attract security researches too!!

Read More