[…]Security begins with the modular components of the system. The first requirement for a secure module is a secure boot. No unauthorized party should be able to tamper with the software while the processor is starting up—something that cannot just be bolted on. A secure boot starts with an initial phase loaded from on-chip masked ROM, so it must be built into the microprocessor silicon. Numerical cryptokeys that authenticate, decrypt, load, and start additional levels of encrypted software are stored in this secure memory. A secure ICS must be able to start up and to decay in a secure state. Intentional or unintentional power cycling must not degrade the level of cyber protection and cybersecurity. A secure boot of every system-wide microprocessor is essential to meeting this requirement.[…]
I am not sure, but I think this Apple support document was created or updated in the last few days.
This article contains references for key product certifications, cryptographic validations, and security guidance for the Secure Enclave Processor (SEP): Secure Key Store. In addition to the general certificates listed here, other certificates may have been issued in order to demonstrate specific security requirements for some markets.[…]
I am not sure, but this might be something interesting:
Potential new signing strategies ( for example signing grub, fwupdate and vmlinuz with separate certificates ) require shim to support a vendor provided bundle of trusted certificates and hashes, which allows shim to “whitelist” EFI binaries matching either certificate by signature, or hash in the vendor_db. Functionality is similar to vendor_dbx ( vendor blacklist ).
There are probably many other more interesting checkins to this important codebase:
This Insyde-specific Linux driver has been around for a year:
This is version 0.0.05 of the (GPLv2 licensed) Linux driver required to carry out firmware upgrades on Insyde Softwares UEFI platform, using the H2OFFT-L(x64) utility on GNU Linux. The utility itself is not available here, since it does not seem to be GPL licensed.[…]
There’ve been two sets of checkings: the initial one last year, and a single comment a few minutes ago:
No maintenance: Please note that I (@tomreyn, you may be looking at a fork of the original repo where things may differ) have no intention of maintaining this code. I’m merely making it available here on GitHub for others to fork and hack on it, just in case it goes offline at the original location I copied this GPLv2 code from.[…]
If there was info on this on Insyde’s web site, I missed it. But there is this:
[…]The HydraBus+HydraNFC Shield v2(hardware) with HydraFW (firmware) are used as an open source multi-tool for anyone interested in Learning/Developping/Debugging/Hacking/Penetration Testing for basic or advanced NFC communications.[…]
There are Vagrant/bash scripts to help install half a dozen firmware analysis tools (binwalk, firmadyne, binaryanalysis-ng, firmware-mod-kit, firmwalker, etc.), which is helpful because most security tool authors are not good at writing installers.
Includes updated Redfish support, as well as some changes after security audits.
Below is a list of currently-actively “UEFI hobby operating system”-style projects on Github, defining “active” as updated in last 2 months. Projects which haven’t been updated recently are not listed, but there are a few dozen other projects between above link and below list. Most are barely more than a hello-world bootloader; others are nearly-complete operating systems, some in C a few in Rust, I think one was in C#. List not sorted in any order:
By Alejandro Mera, Bo Feng, Long Lu, Engin Kirda, William Robertson
[…]We present DICE, a drop-in solution for firmware analyzers to emulate DMA input channels and generate or manipulate DMA inputs. DICE is designed to be hardware-independent, and compatible with common MCU firmware and embedded architectures. DICE identifies DMA input channels as the firmware writes the source and destination DMA transfer pointers into the DMA controller. Then DICE manipulates the input transferred through DMA on behalf of the firmware analyzer. […]All our source code and dataset are publicly available.
PS: If someone can find the source code, leave the URL in a Comment, please.
* Find known EFI GUID’s
* Identified protocols which are finding with LOCATE_PROTOCOL function
* Identified functions used as the NOTIFY function
* Identified protocols installed in the module through INSTALL_PROTOCOL_INTERFACE
* Identified functions used as an interrupt function (like some hardware, software or child interrupt)
* Script for loading efi modules to relevant directories upon import in Headless mode
* Sorting smm modules relying on meta information by next folders[…]
Welcome to 2020.
It appears the Intel LUV (Linux UEFI Validation) distribution is no longer active. Last checkin:
The LUV project is not being maintained actively. Update the README accordingly.
Binary analysis is imperative for protecting COTS (common off-the-shelf) programs and analyzing and defending against the myriad of malicious code, where source code is unavailable, and the binary may even be obfuscated. Also, binary analysis provides the ground truth about program behavior since computers execute binaries (executables), not source code. However, binary analysis is challenging due to the lack of higher-level semantics. Many higher level techniques are often inadequate for analyzing even benign binaries, let alone potentially malicious binaries. Thus, we need to develop tools and techniques which work at the binary level, can be used for analyzing COTS software, as well as malicious binaries. One of the most challenging problems in the binary analysis is firmware analysis because of the given inter-dependencies between modules and pipelines inside the device, in most cases, it’s almost impossible to take the binary out of its environment and perform fuzzing on the binary individually. So, dynamic testing or fuzzing of embedded firmware is severely limited by the hardware-dependence and poor scalability, partly contributing to the widespread vulnerable IoT devices. Over the years, researchers found ways around this shortcoming by either emulating the I/O communication of peripherals to perform off-device fuzzing or using some tricks to perform on-the-device fuzzing. In this talk, I’ll cover the state-of-the-art for the firmware fuzzing by going through the history and the evolution of techniques that have been proposed so far and then I’ll go through another idea to perform fuzzing of IoT devices in large scale.
Customize Secure Boot
The goal is to have you own certificate in the Secure Boot db variable.
Then, to sign Linux with your own certificate.
As we have dual boot with Windows, we’ll keep Microsoft and PC manufacturer certificates.
Detect Boot Mode Is Bios Or UEFI
Maybe it’s just me, but it seems a bit scary to think that games need to know about what kind of platform firmware they are booting from. 🙂
[[Update: adding Tweet with announcement:
This new plugin looks powerful!
Alex Matrosov (@matrosov)
Andrey Labunets (@isciurus)
Philip Lebedev (@p41l)
Yegor Vasilenko (@yeggor)
AMD UEFI Inside: What is really behind AGESA, the PSP (Platform Security Processor) and especially Combo PI?
Since there are always questions and some things are often confused, we will give you some insights into AMD-UEFI, what is colloquially called “the BIOS” (although it is no longer correct). I have also broken down the following extremely to remain as simple and understandable as possible. Nevertheless, what happens when the PC starts up is the classic hen-and-egg problem that you simply have to talk about. Software starts hardware, whereas hardware without software does not actually work and software without hardware does nothing. Now what?[…]
In BOTH English and German:
HelloAmdHvPkg is a type-1 research hypervisor for AMD processors. The hope is to help researchers learn implementation required for the operating system start up under AMD-V (SVM: Secure Virtual Machine).[…]
ACPICA and dmicheck updated. Multiple changes to multiple ACPI table checks. New Dmicheck testing. See announcement for long list of features and bugfixes.
see this Comment on that post:
This is the original codebase:
This is a small utility which checks and recomputes sha1 hashes used to validate Lenovo ThinkPad X220/T420 (and probably other Sandy Bridge ThinkPads) firmware integrity. You can hear 5 beeps twice if the firmware fails validation and you have TPM (security chip) turned on, which is pretty common for modified firmwares.[…]
But the one in the previous blog post has had a recent checkin, whereas this one has had no changes in a long time, so the new branch still may be of interest. Change is in this file:
Not to be confused with the Capstone Engine: the ECE Capstone Project: a current project at Oregon State University:
Our goal is to develop a software tool that when supplied with images of a printed circuit board will reverse engineer the netlist for the board. The software will be implemented as a web based service allowing for users to publish the netlist that they generate. This web page will be available to the engineering community for prolonging the life of old equipment as well as documenting systems for repair to reduce waste. Integrating Computer Vision & Deep Learning to the software, this project is aimed to provide precision and reliability without compromises.[…]