[…]One may need dedicated tools, like a debugger for a firmware or a baseband, or a disassembler to be able to read the instructions properly.[…]
https://blog.quarkslab.com/quarks-in-the-shell-episode-iv.html
Tag: QuarksLab
QuarksLab: intro to TEE: ARM’s TrustZone
[…]This starts a series of two blogposts discussing hardware technologies that can be used to support TEE implementations:
* TrustZone from ARM
* SGX from Intel
As suggested by the title, this blogpost tells you more about TrustZone.[…]
https://blog.quarkslab.com/introduction-to-trusted-execution-environment-arms-trustzone.html
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
https://github.com/quarkslab/QBDI
https://events.ccc.de/congress/2017/Fahrplan/events/9006.html
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.
https://github.com/dude719/UEFI-Bootkit
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.
Quarkslab announces Epona
“Epona provides advanced software protection using LLVM, an industrial strength toolchain.”
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.[…]
https://blog.quarkslab.com/vulnerabilities-in-high-assurance-boot-of-nxp-imx-microprocessors.html
https://labsblog.f-secure.com/2017/07/19/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.
https://github.com/JonathanSalwan/Triton/milestone/8
https://github.com/JonathanSalwan/Triton
https://triton.quarkslab.com/
https://triton.quarkslab.com/documentation/doxygen/
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.
[…]
Veracrypt security issues
Multiple news sources are reporting issues with TrueCrypt replacement VeraCrypt, a UEFI application. Quoting The Register:
[…] Quarkslab senior security researcher Jean-Baptiste Bédrune and senior cryptographer Marion Videau crawled through the VeraCrypt codebase, focussing on version 1.18 of the platform and the DCS EFI Bootloader 1.18 (UEFI), examining new security features introduced since the April 2015 security audit of TrueCrypt. They report boot passwords in UEFI mode and code length in legacy mode could be retrieved by attackers.[…]
http://www.theregister.co.uk/2016/10/18/veracrypt_audit/
Capsule by Quarkslab
“Two years of development later, Cappsule goes open-source! Enjoy!” –September 21st
https://twitter.com/rootkovska/status/778588193239236608
https://cappsule.github.io/faq/
Triton
“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, a SMT Solver Interface and, the last but not least, Python bindings. Based on these components, you are able to build program analysis tools, automate reverse engineering and perform software verification”
http://triton.quarkslab.com/blog/What-kind-of-semantics-information-Triton-can-provide/
http://triton.quarkslab.com/
Ext4 encryption
QuarksLab has a new blog on encryption support of Linux’s Ext4 file system:
Excerpting the beginning of the post:
Linux 4.1 has arrived with a new feature for its popular ext4 filesystem: filesystem-level encryption! This feature appears to have been implemented by Google since they plan to use it for future versions of Android and Chrome OS. Android filesystem encryption currently relies on dm-crypt. Google’s motivations for pushing encryption to ext4 seem:
* To avoid using a stacked filesystem design (for better performance?).
* To encrypt data with integrity.
* To allow multiple users to encrypt their files with different keys on the same filesystem.
More Information:
http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html
Also see this article from April:
https://lwn.net/Articles/639427/
UPDATE: See-also this recent talk from Google at the 2015 Linux Security Summit:
Encrypting Android Devices
Paul Lawrence and Mike Halcrow, Google
Firmware Security 