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).[…]
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.[…]
So far, the only info are these tweets:
Microsoft Defender has been a Windows-cenric AV tool. Recently, Microsoft has ported it to Android and Linux. Recently, Microsoft also started adding UEFI scanning to Defender. So maybe now Android and Linux users can use Defender to scan for UEFI vulns?
CHIPSEC has been the main option for UEFI scanning. It works only on Intel systems. It works as an OS-level app (“OS-present”) on Mac, Windows, and Linux. And runs on UEFI. The OS-level scanners from Apple and Microsoft now both cover UEFI. Will either scan non-Intel systems: ARM64 and AMD64?
AMD issued an update last week saying that it will provide an actual update in a few weeks, and sarcastically advises vendors to stay “up-to-date”…
AMD is aware of new research related to a potential vulnerability in AMD software technology supplied to motherboard manufacturers for use in their Unified Extensible Firmware Interface (UEFI) infrastructure and plans to complete delivery of updated versions designed to mitigate the issue by the end of June 2020.[…]AMD has delivered the majority of the updated versions of AGESA to our motherboard partners and plans to deliver the remaining versions by the end of June 2020. AMD recommends following the security best practice of keeping devices up-to-date with the latest patches.[…]
We thank Danny Odler for his ongoing security research.
Full announcement paragraph:
No news here:
AGESA status page:
just kidding, there is no such page, only AMD clients get AGESA status updates under NDA.
I wonder if the Apple macOS or Microsoft Defender UEFI scanners will be updated to catch this on AMD systems. CHIPSEC can’t, it does not work on AMD systems.
[The main branch is 9 months old, but there’s another branch that has just been updated…]
Tools to check and cryptographically sign UEFI firmware images found in ThinkPads. This will resolve the issue where your ThinkPad lets out two groups of five beeps before continuing to boot (the error indicating an invalid signature). These tools are written in Python 3 and rely on the “pycryptodome” library.[…]
By: Nidhi Rastogi, Sharmishtha Dutta, Mohammed J. Zaki, Alex Gittens, Charu Aggarwal
Malware threat intelligence uncovers deep information about malware, threat actors, and their tactics, Indicators of Compromise(IoC), and vulnerabilities in different platforms from scattered threat sources. This collective information can guide decision making in cyber defense applications utilized by security operation centers(SoCs). In this paper, we introduce an open-source malware ontology – MALOnt that allows the structured extraction of information and knowledge graph generation, especially for threat intelligence. The knowledge graph that uses MALOnt is instantiated from a corpus comprising hundreds of annotated malware threat reports. The knowledge graph enables the analysis, detection, classification, and attribution of cyber threats caused by malware. We also demonstrate the annotation process using MALOnt on exemplar threat intelligence reports. A work in progress, this research is part of a larger effort towards auto-generation of knowledge graphs (KGs)for gathering malware threat intelligence from heterogeneous online resources.
Firmware Command and Control will create an agile embedded response capability foundational with baselined firmware and behaviors with bi-directional sharing of threat to upstream energy security operations
* Embedded devices control the most critical functions on the electric grid with little to no insight into the firmware or ability to mitigate from cyber attacks.
* The adversaries have ‘raced to the bottom’ hiding access in embedded devices
* Firmware will be baselined to detect changes with advanced ML similarity with constraints
* Embedded host agile response
* Structured threat sharing between the device and upstream security
* Firmware C2 will monitor and mitigate previously unmonitored devices controlling the most critical functions in the electric grid.
* Baselined embedded firmware with all constraints for setting changes
* Low-impact cyber operations protected/hidden from adversaries
* Structured Threat: Visual, Sharable, Actionable, and Implementable (IT/OT)
* Firmware C2 uses recent ML concepts to baseline firmware to detect unexplained changes, described in structured threat for bi-direction upstream energy security operations actions and awareness.
Forescout selected by U.S. Department of Energy to Participate in Firmware Project Under Grid Modernization Lab Consortium
FirmWare Test Suite’s ACPI tests are improving. It sounds like they are acpica-dump compatible now, and FTWS dumps more than acpidump!
[PATCH 1/2] doc: add new –dump-acpi-from-sysfs option
[PATCH 0/2] make the acpi logs from fwts can be used acpica debugging
“-dumpfile=acpidump.log: load ACPI tables from output generated from acpidump or from sudo fwts –dump. The latter is preferred as fwts –dump is able to dump more tables than acpidump.[…]