The PDFs from the recent UEFI Forum plugfest’s presentations have been uploaded. Hopefully soon the videos will also show up on Youtube.

https://uefi.org/learning_center/presentationsandvideos

ReFirm Labs has an updated version of Centrifuge out, which includes UEFI support. They also have BinWalk Pro.

https://markets.businessinsider.com/news/stocks/refirm-labs-announces-spring-2019-release-of-centrifuge-platform-updates-with-uefi-support-launches-binwalk-pro-1028133957

https://www.prweb.com/releases/refirm_labs_announces_spring_2019_release_of_centrifuge_platform_updates_with_uefi_support_launches_binwalk_pro/prweb16263527.htm

https://www.refirmlabs.com/binwalk-pro/

I just had the first request to remove a blog post about a project of theirs. There are multiple broken links on this blog, where Github projects have disappeared. This is the first blog post that I’ve taken down.

If you don’t want to have people see your project, maybe you should not post it on Github to be publicly-viewable. If you’re concerned about privacy issues about your name being associated with a project, perhaps you should not use your name on that Github account. Many of my posts are based on watching Github for new projects, which is how I found the <now-deleted-project>:

https://github.com/search?o=desc&q=UEFI&s=updated&type=Repositories

This guide takes a look at vetting an embedded system (An ASUS RT-AC51U) using AFL, angr, a cross compiler, and some binary instrumentation without access to the physical device. We’ll go from static firmware to thousands of executions per second of fuzzing on emulated code. (Sorry no 0days in this post). Asus is kind enough to provide the firmware for their devices online. Their firmware is generally a root file system packed into a single file using squashfs. As shown below, binwalk can run through this file system and identify the filesystem for us.[…]

Re: https://firmwaresecurity.com/2019/01/21/blackhat-asia-modern-secure-boot-attacks-bypassing-hardware-root-of-trust-from-software/

Slides are avaiable:

Click to access BHASIA2019_matrosov_final.pdf

A new Rust library:

https://github.com/mizkichan/uefi-unifont

Relies on:

A new Rust-based tool:

https://github.com/MOZGIII/rebootinto

[…]Last week at Google Cloud Next ’19, we announced the general availability of Shielded VM—virtual machine instances that are hardened with a set of easily configurable security features that assure you that when your VM boots, it’s running a verified bootloader and kernel. Shielded VM can help you protect your system from attack vectors like: Malicious guest OS firmware, including malicious UEFI extensions,
Boot and kernel vulnerabilities in guest OS, and Malicious insiders within your organization.[…]

https://cloud.google.com/blog/products/identity-security/shielded-vm-your-ticket-to-guarding-against-rootkits-and-exfiltration

https://cloud.google.com/shielded-vm/

Defence Industries has an article that describes Secure Boot, Trusted Boot, Measured Boot, and Verified Boot. And Intel Boot Guard. It seems they didn’t cover the latter one, but the article was focused on Windows systems…

https://www.defence-industries.com/articles/explanation-of-secure-system-startup-processes-concurrent-technologies-processor-boards

https://github.com/jslegendre/ACPIPatcher

https://arxiv.org/abs/1904.05572

René Mayrhofer, Jeffrey Vander Stoep, Chad Brubaker, Nick Kralevich
(Submitted on 11 Apr 2019)

Android is the most widely deployed end-user focused operating system. With its growing set of use cases encompassing communication, navigation, media consumption, entertainment, finance, health, and access to sensors, actuators, cameras, or microphones, its underlying security model needs to address a host of practical threats in a wide variety of scenarios while being useful to non-security experts. The model needs to strike a difficult balance between security, privacy, and usability for end users, assurances for app developers, and system performance under tight hardware constraints. While many of the underlying design principles have implicitly informed the overall system architecture, access control mechanisms, and mitigation techniques, the Android security model has previously not been formally published. This paper aims to both document the abstract model and discuss its implications. Based on a definition of the threat model and Android ecosystem context in which it operates, we analyze how the different security measures in past and current Android implementations work together to mitigate these threats. There are some special cases in applying the security model, and we discuss such deliberate deviations from the abstract model.

=

Here’s a new project on Github, an Insyde-specific Linux-specific
driver. I asked Insyde about this, and apparently it is an out-of-date
driver, and they should have a statement about a newer version in the
near future.

https://github.com/tomreyn/isfl

For some time now, I’ve been reverse engineering the firmware of the Broadcom BCM5719 Ethernet NIC chip, so that open source firmware can be produced for it. […] The reverse engineering project, Project Ortega, began in December 2017 and involved reverse engineering proprietary firmware to determine what any open source replacement would need to do. Mainly this involved producing a reverse engineered C codebase from the disassembly of proprietary firmware, then producing a natural-language specification for others to reimplement; the actual reversed code itself is not published. In other words, this is a clean-room reverse engineering workflow. The reverse engineering side is now pretty much done and availability of open source firmware for the BCM5719 is waiting on the completion of a reimplementation effort (thanks to Evan Lojewski). This is a cleanroom implementation and doesn’t share any code with Project Ortega or the proprietary firmware, but is produced using the human-readable specifications delivered by Project Ortega. Once this is delivered, it will be possible to use Raptor’s POWER9 systems with purely 100% free, open source firmware. As far as I am aware, there is no other machine in the same performance class which can make such a claim. The rest of this article describes the entire journey of getting to this point, and briefly discusses the innards of the BCM5719.[…]

https://www.devever.net/~hl/ortega

https://github.com/hlandau/ortega

https://tsc.intel.com/c

I wish I had more information, but nope. Please leave a Comment if you have something. As to whether this is a joke or not, I’ve heard one Intel engineer talk — with a straight face — about using blockchain-based tech to help secure firmware blobs’ supply chain a few months ago, maybe this was what they were talking about… For better or worse, I ignore anything that mentions blockchain technology, maybe I’m missing out in a bunch of legitimate things?

https://www.intel.com/content/www/us/en/security/blockchain-overview.html

efi-loadopt: A tiny utility crate — Rust code — with a sole purpose of deserializing UEFI Boot Manager’s Load Options (EFI_LOAD_OPTION) – see 3.1.3 at UEFI spec.

https://github.com/MOZGIII/efi-loadopt

[…]To root any 2017+ Subaru StarLink head unit, an attacker needs the following to generate valid update images:

1. A Subaru head unit with serial and USB port access.
2. The encryption keys for the update files.
3. An official update. These seem to be available for most platforms in many different ways. Without the official update, the ISO signature check will fail and the install will not continue to the stage where the QNXCNDFS files are written.
4. Physical access to the vehicles USB ports.[…]

https://nvd.nist.gov/vuln/detail/CVE-2018-18203

https://github.com/sgayou/subaru-starlink-research/blob/master/doc/README.md

https://translate.google.com/translate?hl=en&sl=jp&tl=en&u=https://retrage01.hateblo.jp/entry/2019/04/13/121833

https://techbookfest.org/event/tbf06/circle/65580001

https://efi-book.github.io/

https://booth.pm/ja/items/1037661

Excerpting Google Translate of this Japanaese web page:

We will distribute the new edition ” UEFI Reading Book GRUB ” as “Marine Soft Matter” in the technical textbook 6 to be held at Ikebukuro Sunshine City on April 14, 2019. The previously published ” UEFI Reader Basic Edition Linux Edition” will be separated as the basic edition and distributed as ” UEFI Reader Linux Edition”. The placement destination is “U 27”.
UEFI reading book GRUB ed.

” UEFI Reader Basic edition Linux edition” (hereinafter referred to as ” Linux edition”) distributed in the last technical book 5 was read by many people, despite being the first coterie of ocean soft matter I would like to thank you at this place. In ” Linux “, we tracked the boot process on EFI stub at source code level. However, many Linux distributions often use the GRUB bootloader, which has not covered the boot process in a typical Linux environment. So in this document we will look at GRUB startup and Linux startup in a UEFI environment. However, Linux startup itself is not covered here because of space limitations.