Quarks Lab: dumping flash chips, blog series

Quarks Lab has a 2-part blog series on dumping flash chips:

First part of a blog post series about our approach to dump a flash chip. In this article we describe how to desolder the flash, design and build the corresponding breakout board. This blog post series will detail simple yet effective attacks against embedded devices non-volatile memories. This type of attack enables you to do the following:
* read the content of a memory chip;
* modify the content of a memory chip;
* monitor the accesses from/to a memory chip and modifying them on the fly (Man-In-The-Middle attack).

In particular, the following topics will be discussed:
* Desoldering of a flash chip;
* Conception of a breakout board with KiCAD;
* PCB fabrication and microsoldering;
* Addition of a breakout board on an IoT device;
* Dump of a SPI flash;
* Dump of a parallel flash;
* Man-in-the-Middle attacks.




QBDI – QuarksLab – dynamic binary instrumentation framework for Intel/ARM Linux/Mac/Android/iOS/Windows




QuarkslaB Dynamic binary Instrumentation (QBDI) is a modular, cross-platform and cross-architecture DBI framework. It aims to support Linux, macOS, Android, iOS and Windows operating systems running on x86, x86-64, ARM and AArch64 architectures.




UEFI-Bootkit docs updated

Re: https://firmwaresecurity.com/2016/11/04/uefi-bootkit/

Aidan Khoury of Quarkslab has updated UEFI-Bootkit. Only change to the project in the last year was update to readme, with more info. It is worth reading the USRT review of this bootkit, in the above URL.


UEFI-Bootkit: A small bootkit designed to use zero assembly. Make sure to compile the driver as an EFI Runtime driver (EFI_RUNTIME_DRIVER) or else the bootkit will be freed once winload.efi calls ExitBootServices! Thanks to pyro666, dreamboot, and VisualUEFI.

alt text



Quarkslab’s vulnerabilitries in NXP i.MX secure boot


Vulnerabilities in High Assurance Boot of NXP i.MX microprocessors
By Guillaume Delugré Iván Arce

This blog post provides details about two vulnerabilities found by Quarkslab’s researchers Guillaume Delugré and Kévin Szkudłapski in the secure boot feature of the i.MX family of application processors [1] built by NXP Semiconductors. The bugs allow an attacker to subvert the secure boot process to bypass code signature verification and load and execute arbitrary code on i.MX application processors that have the High Assurance Boot feature enabled. These bugs affect 12 i.MX processor families. The vulnerabilities were discovered and reported to the vendor in September 2016 and the technical details included in this blogpost were disclosed in a joint Quarkslab-NXP presentation at the Qualcomm Mobile Security Summit 2017 [2] in May 19th, 2017. National computer emergency response teams (CERTs) from 4 countries were informed about the issues in March, 2017. NXP has issued an Engineering Bulletin and two Errata documents (EB00854, ERR010872 and ERR0108873 respectively) [3] providing a brief description of both vulnerabilities, the list of affected processor models along with resolution plans and possible mitigations. In the rest of the blogpost we describe the relevant features in i.MX processors and the vulnerabilities affecting them.[…]InversePath, vendor of USB Armory [6], an affected device confirmed the vulnerabilities and developed proof of concept programs to demonstrate them.[…]


Break your own product, and break it hard



Triton 0.5 released

Triton is a Dynamic Binary Analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings.


Triton's architecture


USB Armory: High Assurance Boot (HABv4) bypass

Security advisory: High Assurance Boot (HABv4) bypass

The NXP i.MX53 System-on-Chip, main processor used in the USB armory Mk I board [1] design, suffers from vulnerabilities that allow bypass of the optional High Assurance Boot function (HABv4). The HABv4 [2] enables on-chip internal boot ROM authentication of the initial bootloader with a digital signature, establishing the first trust anchor for further code authentication. This functionality is commonly known as Secure Boot [3] and it can be activated by users who require authentication of the bootloader (e.g. U-Boot) to further maintain, and verify, trust of executed code. Quarkslab reported [4] to NXP, and subsequently to Inverse Path, two different techniques for bypassing HABv4 by means of exploiting validation errors in the SoC internal boot ROM [5], which are exposed before bootloader authentication takes place. While the two vulnerabilities have been initially reported for the i.MX6 SoC, Inverse Path evaluated that both issues also apply to the i.MX53 SoC, used on the USB armory Mk I.
Technical details under embargo until July 18th, by mutual agreement between
reported and NXP.