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

Pimping your Wireshark on OSX

Pimping your Wireshark on OSX

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

Embedded Trust (P1): Beginning to trust my BeagleBone

I plan to have a series of posts outlining my curiosity with embedded development and trust. Let's start with poking around where my (our) trust lies when deciding on a SoC for embedded development, using the BeagleBone [SRM] as an example. In this post we'll move trust from CircuitCO's (the Bone manufacture) included bootloaders, Angstrom Linux kernel, and Angstrom development environment to your own compiled bootloaders, kernel, and OS.

Read More

How To: DIY (Improved) Inexpensive Fog Screen

How To: DIY (Improved) Inexpensive Fog Screen

Last month we built an improved version of the DIY Fog Screen found here.

We call it "improved" since we managed to create a thinner sheet of fog, maintain the projection longer (a fog machine is bursty), and thicken the sheet. We use the same technique of creating a laminar flow. Instead of using a window fan we installed 10 120mm [17] computer fans with a variable speed controller [20] to optimize the flow, since we did not know the fog density.

Since the original article doesn't explain the steps / tools / resources required to create a DIY Fog Screen, we'd like to take the opportunity and provide a "how to". In a nut shell, the screen needs to distribute "fog machine"-fog from end-to-end, width-wise, and keep the fog flowing downward sandwiched between two flows of air.

Read More

Gelf: L1 Emulation, L2 Tunneling, using an HTTP Client

Gelf: L1 Emulation, L2 Tunneling, using an HTTP Client

Simply: Gelf uses an HTTP client to bridge two or more networks. The iPhone is the primary use case; it has access to both AT&T's mobile network as well as an ad-hoc network. You can bridge the two using Gelf, without running any code on the iPhone, aside from client-side HTML and JavaScript.

This achieves a non-jailbroken, non-rooted, poor-man's network tether. Here's the catch, Gelf needs to run on a device inside each target network. Gelf functions as the L2 tunnel end-points, and the L1 emulation: achieved through an HTTP client.

Read More