Month: January 2019
ASUS_Firmware_Scraper: Fetch all firmware from ASUS Support website
Requirements: 1) node.js. 2) around 45GB of discspace.
https://github.com/Mimoja/asus_firmware_scraper
Evolution of the x86 context switch in Linux
While researching archaic facts about the 80386 hardware context switch last weekend, I remembered that early versions of the Linux kernel relied on it. I was promptly sidetracked for hours reading code I hadn’t seen in years. This weekend, I’ve decided to write down the journey to consolidate all the nuggets of fun stuff I discovered along the way.
http://www.maizure.org/projects/evolution_x86_context_switch_linux/

Formally verified big step semantics out of x86-64 binaries
This paper presents a methodology for generating formally proven equivalence theorems between decompiled x86-64 machine code and big step semantics. These proofs are built on top of two additional contributions. First, a robust and tested formal x86-64 machine model containing small step semantics for 1625 instructions. Second, a decompilation-into-logic methodology supporting both x86-64 assembly and machine code at large scale. This work enables black-box binary verification, i.e., formal verification of a binary where source code is unavailable. As such, it can be applied to safety-critical systems that consist of legacy components, or components whose source code is unavailable due to proprietary reasons. The methodology minimizes the trusted code base by leveraging machine-learned semantics to build a formal machine model. We apply the methodology to several case studies, including binaries that heavily rely on the SSE2 floating-point instruction set, and binaries that are obtained by compiling code that is obtained by inlining assembly into C code.
Firmware-BiosUpgrades: Update BIOS for any make and model (incremental if needed) [using PowerShell]
https://github.com/PowerShellCrack/Firmware-BiosUpgrades
Retro-BIOS: Sources and/or disassembly listings to BIOS and firmware
Sources and/or disassembly listings to BIOS of ex-USSR PC clones and the like. Sources and/or disassembly listings of the DEC Rainbow 100 BIOS (an early PC with VT100/VT102 capability).
3 new research papers on fuzzing
Azure IoT automatic device management helps deploying firmware updates at scale
Automatic device management in Azure IoT Hub automates many of the repetitive and complex tasks of managing large device fleets over the entirety of their lifecycles. Since the feature shipped in June 2018, there has been a lot of interest in the firmware update use case. This blog article highlights some of the ways you can kickstart your own implementation.
Azure IoT automatic device management helps deploying firmware updates at scale
When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs
When a Patch is Not Enough – HardFails: Software-Exploitable Hardware Bugs
Ghada Dessouky, David Gens, Patrick Haney, Garrett Persyn, Arun Kanuparthi, Hareesh Khattri, Jason M. Fung, Ahmad-Reza Sadeghi, Jeyavijayan Rajendran
(Submitted on 1 Dec 2018)
In this paper, we take a deep dive into microarchitectural security from a hardware designer’s perspective by reviewing the existing approaches to detect hardware vulnerabilities during the design phase. We show that a protection gap currently exists in practice that leaves chip designs vulnerable to software-based attacks. In particular, existing verification approaches fail to detect specific classes of vulnerabilities, which we call HardFails: these bugs evade detection by current verification techniques while being exploitable from software. We demonstrate such vulnerabilities in real-world SoCs using RISC-V to showcase and analyze concrete instantiations of HardFails. Patching these hardware bugs may not always be possible and can potentially result in a product recall. We base our findings on two extensive case studies: the recent Hack@DAC 2018 hardware security competition, where 54 independent teams of researchers competed world-wide over a period of 12 weeks to catch inserted security bugs in SoC RTL designs, and an in-depth systematic evaluation of state-of-the-art verification approaches. Our findings indicate that even combinations of techniques will miss high-impact bugs due to the large number of modules with complex interdependencies and fundamental limitations of current detection approaches. We also craft a real-world software attack that exploits one of the RTL bugs from Hack@DAC that evaded detection and discuss novel approaches to mitigate the growing problem of cross-layer bugs at design time.
SPECTECTOR: Principled Detection of Speculative Information Flows
SPECTECTOR: Principled Detection of Speculative Information Flows
Marco Guarnieri, Boris Köpf, José F. Morales, Jan Reineke, Andrés Sánchez
(Submitted on 20 Dec 2018)
Since the advent of SPECTRE, a number of countermeasures have been proposed and deployed. Rigorously reasoning about their effectiveness, however, requires a well-defined notion of security against speculative execution attacks, which has been missing until now. We present a novel, principled approach for reasoning about software defenses against SPECTRE-style attacks. Our approach builds on speculative non-interference, the first semantic notion of security against speculative execution attacks. We develop SPECTECTOR, an algorithm based on symbolic execution for automatically proving speculative non-interference, or detecting violations.
We implement SPECTECTOR in a tool, and we use it to detect subtle leaks — and optimizations opportunities — in the way major compilers place SPECTRE countermeasures.
[AMD] SEVered attack: Extracting Secrets from Encrypted VMs
Extracting Secrets from Encrypted Virtual Machines
Mathias Morbitzer, Manuel Huber, Julian Horsch
(Submitted on 7 Jan 2019)
AMD SEV is a hardware extension for main memory encryption on multi-tenant systems. SEV uses an on-chip coprocessor, the AMD Secure Processor, to transparently encrypt virtual machine memory with individual, ephemeral keys never leaving the coprocessor. The goal is to protect the confidentiality of the tenants’ memory from a malicious or compromised hypervisor and from memory attacks, for instance via cold boot or DMA. The SEVered attack has shown that it is nevertheless possible for a hypervisor to extract memory in plaintext from SEV-encrypted virtual machines without access to their encryption keys. However, the encryption impedes traditional virtual machine introspection techniques from locating secrets in memory prior to extraction. This can require the extraction of large amounts of memory to retrieve specific secrets and thus result in a time-consuming, obvious attack. We present an approach that allows a malicious hypervisor quick identification and theft of secrets, such as TLS, SSH or FDE keys, from encrypted virtual machines on current SEV hardware. We first observe activities of a virtual machine from within the hypervisor in order to infer the memory regions most likely to contain the secrets. Then, we systematically extract those memory regions and analyze their contents on-the-fly. This allows for the efficient retrieval of targeted secrets, strongly increasing the chances of a fast, robust and stealthy theft.
Latest S2E released, adds QEMU v3 support
S²E is a platform for writing tools that analyze the properties and behavior of software systems. S²E comes as a modular library that gives virtual machines symbolic execution and program analysis capabilities. S²E runs unmodified x86, x86-64, or ARM software stacks, including programs, libraries, the kernel, and drivers. Symbolic execution then automatically explores hundreds of thousands of paths through the system, while analyzers check that the desired properties hold on these paths and selectors focus path exploration on components of interest. S²E is now commercially supported by Cyberhaven. It is free for non-commercial use. S²E was a research project of the Dependable Systems Lab at EPFL in Lausanne.
http://s2e.systems/docs/DesignAndImplementation/KvmInterface.html
Keegan Ryan: Spectre on a Television
This past January, I ordered a new TV. […] The TV was manufactured by Sceptre Inc. (note the ‘C’ and ‘P’ switch) and was covered in SCEPTRE branding. My goal for this project was to perform a hardware-level attack against the TV and change the branding to SPECTRE as an homage to the microarchitectural attack. This project has nothing to do with exploiting speculative execution, but instead it demonstrates several common techniques NCC Group uses when analyzing embedded systems.[…]

Sail-Arm: Sail version of ARM ISA definition, currently for ARMv8.5-A
Bareflank’s hypervisor: lightweight hypervisor SDK written in C++ with support for Windows, Linux and UEFI
The Bareflank Hypervisor is an open source, hypervisor Software Development Toolkit (SDK), led by Assured Information Security, Inc. (AIS), that provides a set of APIs needed to rapidly prototype and create new hypervisors. To ease development, Bareflank is written in C/C++, and includes support for C++ exceptions, JSON, the GSL and the C++ Standard Template Library (STL).
https://github.com/Bareflank/hypervisor

Debian UEFI Secure Boot changes!
Steve McIntyre has posted an update on Debian’s UEFI Secure Boot status, to the debian-boot and debian-efi mailing lists. Excerpt:
I’ve just pushed changes to a few bits of d-i this weekend to make SB work for amd64:
* build/util/efi-image: […]
* build/config/arm.cfg, build/config/x86.cfg: […]
* debian/control: […]
* grub-installer/grub-installer: […]
The effect of these changes is that the next daily and weekly debian installer images (tomorrow) should Just Work (TM) end-to-end with UEFI Secure Boot. The changes to efi-image also mean that our next live image builds will do SB (for live and installation).
I’ll test all these again in the next couple of days to verify that things have pulled through as I expect, then it’s time to post to d-d-a and write a blog too. We’ve made great progress already. These last changes just tie it all together for end users.
More info:
https://lists.debian.org/msgid-search/20190113192343.qg3ekmtnyepscwxb@tack.einval.com
hdk – (unofficial) Hyper-V® Development Kit
The HDK is an updated version of the HvGdk.h header file published under MSR-LA as part of the Singularity Research Kernel. It has been updated to add the latest definitions, structures and definitions as described in the Microsoft Hypervisor Top-Level Functional Specification (TLFS) 5.0c published June 2018.
UefiLog: logging library for UEFI
“UefiLog is a lightweight log system in UEFI environment“
UEFI-based screen capture tools
I notice that Microsoft’s Project Mu has a PrintScreenLogger tool (Ctrl+PrtScn):
https://github.com/Microsoft/mu_plus/tree/release/201808/MsGraphicsPkg/PrintScreenLogger
and that it is already getting some forks:
https://github.com/vscpp/PrintScreenLogger
Before that, there was RU.EFI command line tool (F12):
and Nikolaj’s CrScreenShotDXE (LeftCtrl+LeftAlt+F12):
And there are probably a few other options I’m not aware of, including by IBVs/ODMs.

You must be logged in to post a comment.