Targets 64-bit Intel systems running Windows.
http://blog.frizk.net/2018/03/memory-process-file-system.html
https://github.com/ufrisk/pcileech
Month: March 2018
Cutter 1.3 released
SSTIC 2018
Many interesting presentations at this conference, including:
Subverting your server through its BMC: the HPE iLO4 case
Risques associés aux signaux parasites compromettants : le cas des câbles DVI et HDMI
WooKey: USB Devices Strike Back
Point d’accès Ruckus : Analyse du firmware, rétro-ingénierie MIPS et élévation de privilèges
Attacking serial flash chip: case study of a black box device
Sandbagility : un framework d’introspection en mode hyperviseur pour Microsoft Windows
A Practical Guide to Differential Power Analysis of USIM Cards
https://www.sstic.org/2018/news/
https://www.sstic.org/2018/programme/
Finbarr’s UEFI-Utilities-2018
Finbarr Murphy has updated UEFI Utilities again. Earlier it was GNU-EFI based, now it is EDK2 based, and uses VS2018.
https://github.com/fpmurphy/UEFI-Utilities-2018
Maybe not finished migrating yet, but there are more tools in the older version than this, so don’t ignore the old tools.
https://github.com/fpmurphy/UEFI-Utilities-2016
And sometimes it seems the latest tools are only available the HTML of recent blob posts, so look there as well:
simple-bootsplash: displays the UEFI Logo during initramfs stage
simple-bootsplash
displays the UEFI Logo during initramfs stage
depends on fbv, xrandr, awk, lzop
UEFIoverclockMonitor.efi: Monitor TSC, default and overclocked CPU frequencies
Written in FASM.
Measure TSC, default and overclocked CPU frequencies.
https://github.com/manusov/UEFIoverclockMonitor
UEFI topics in Paul’s Security Weekly 550-551
Episode 550 has AMI, and 551 has Phoenix
https://securityweekly.com/subscribe/
https://wiki.securityweekly.com/Episode550
https://wiki.securityweekly.com/Episode551
Sorry can’t find URL to the 551 video, leaving that as ‘an exercise for the reader’. 🙂
https://securityweekly.com/subscribe/
OpenXT: adding anti-evil maid support, using UEFI and Xen in place of TXT
[…]In this PR OpenXT is extended to allow booting under UEFI while maintaining current security properties.,Changes to Measured Launch,,Booting OpenXT under UEFI introduces significant changes to the Measured Launch system of OpenXT by switching to the use of SRTM PCRs. Performing DRTM with TXT when booting under UEFI is not supported but can be implemented at a later date. OpenXT under UEFI relies on the shim EFI application to perform necessary measurements of critical boot components of OpenXT. OpenXT’s static PCR list is extended to include PCR4, PCR5, PCR7 and PCR8. Specific to OpenXT’s context, PCR4 holds the measurements of the shim, Xen and the dom0 kernel while PCR8 holds the measurements of openxt.cfg, the dom0 initrd image and the XSM policy. Any change in these components, selecting a boot entry other then the one used when Sealing took place and/or booting any application before the shim will result in the Measured Launch system tripping.[…]
https://github.com/OpenXT/xenclient-oe/pull/828
MicroPython for UEFI
https://twitter.com/DevZoneBlog/status/971860129946611712
[…]my team investigated several options to support Python 3.x in UEFI boot services. Because firmware is a constrained environment compared to OS runtime, we evaluated porting MicroPython to UEFI. MicroPython is a Python 3 variant designed for microcontrollers, with memory and size optimizations that make it ideal for pre-OS applications. […] Supporting Python 3.x & MicroPython in open source creates new opportunities for the TianoCore community to validate robust firmware solutions.[…]
https://software.intel.com/en-us/blogs/2018/03/08/implementing-micropython-as-a-uefi-test-framework
Deconstructing the Xbox Boot ROM
[…]I recently wanted to do a bit of reverse-engineering and so I decided to deconstruct the boot ROM to better understand the Xbox security system. In this article, I will present the high-level boot flow of the system, the disassembled ROM code, pseudocode for the disassembly, along with some thoughts. It should be known that there is essentially no new information presented in this article. The many flaws of the Xbox security system have already been well documented years ago by some really smart people. That said, I am not aware of a similar disassembly of the ROM, so perhaps this article will serve as a guide for others who are interested.[…]
https://mborgerson.com/deconstructing-the-xbox-boot-rom/
LLVM 6.0.0 Released, includuing Spectre variant2 mitigations
This release is the result of the community’s work over the past six months, including: retpoline Spectre variant 2 mitigation, significantly improved CodeView debug info for Windows, GlobalISel by default for AArch64 at -O0, improved scheduling on several x86 micro-architectures, Clang defaults to -std=gnu++14 instead of -std=gnu++98, support for some upcoming C++2a features, improved optimizations, new compiler warnings, many bug fixes, and more.
https://llvm.org/releases/download.html#6.0.0
https://llvm.org/releases/6.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://llvm.org/releases/6.0.0/tools/lld/docs/ReleaseNotes.html
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-announce
Emulating Exynos 4210 BootROM in QEMU
[…]This project allows to debug BootROM dynamically with GDB. It has been helpful for analyzing secure boot mechanism that loads and authenticates the next stage from flash memory.[…]
Nicely-written. Includes coverage of U-Boot and U-Boot Secure Boot.
https://www.fredericb.info/2018/03/emulating-exynos-4210-bootrom-in-qemu.html#emulating-exynos-4210-bootrom-in-qemu
https://github.com/frederic/qemu-exynos-bootrom
PS: I just learned about this blog. Catching up, there are some interesting older posts, eg:
Amlogic S905 SoC: bypassing the (not so) Secure Boot to dump the BootROM
https://www.fredericb.info/2016/10/amlogic-s905-soc-bypassing-not-so.html#amlogic-s905-soc-bypassing-not-so
Debian and FWTS
Re: https://firmwaresecurity.com/2017/11/28/fwts-added-to-debian/
It looks like Canonical’s FWTS is having a hard time staying in Debian repos. 😦
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748783
UefiDiskBenchmark.efi: Mass storage benchmark for UEFI (written in FASM)
UefiDiskBenchmark: Mass storage benchmark, based on EFI_BLOCK_IO_PROTOCOL EFI Byte Code (EBC) application.
Output parameters and flags:
“#” Device number in the list
“Revision” Revision of UEFI API EFI_BLOCK_IO_PROTOCOL.
“Media” Media ID
“RM” Removable Media flag, for example CD or USB flash
“MP” Media Present
“LP” Logical Partition
“RO” Read Only
“WC” Write Cache
“Block” Block size, bytes
“Align” Required alignment for memory buffer, bytes
“Size” Available size of mass storage device
Known bug: maximum 10 devices supported, include aliases.
https://github.com/manusov/UEFIdiskBenchmark
UefiUsbScan.efi: Scan USB host controllers and connections, written in FASM
UefiUsbScan: Scan for USB host controllers and connections, current version use direct PCI/MMIO hardware access. Only xHCI controllers supported yet, not supports UHCI, OHCI, EHCI.
docker-edk2-uefi: Docker container for Tianocore EDK2 dev
Container to build Tianocore EDK2 MdeModules and OVMF and run in OVMF with qemu using X over ssh
UEFI EDKII Development Environment
This docker container can be used to build projects based on the Tiano EDKII UEFI project. It is possible to selected the branch of the EDKII project to be used and compiled at container creation as well as the target architecture. Build Tools are compiled on first ssh login triggered in bashrc. qemu can be run with X over ssh. Scripts are included to build MdeModulePkg and OVMF. Script included to create base for OVMF qemu environment and start qemu (script only for x86/64 right now).[…]
https://hub.docker.com/r/geneerik/docker-edk2-uefi/
Somewhat related, I also found these UEFI/Docker options:
https://hub.docker.com/r/rojuinex/edk2-uefi/~/dockerfile/
https://hub.docker.com/r/michas2/edk2-test/~/dockerfile/
PS: Wondering what he’s been messing with UEFI on:
US Homeland Security: Threat to Network Infrastructure Devices
https://twitter.com/RidT/status/970877316602658816
https://twitter.com/RidT/status/970880435411709952
Threat to Network Infrastructure Devices
The Increasing Threat to Network Infrastructure Devices and Recommended Mitigations
Click to access ar-16-20173.pdf
Kotlin-native-UEFI: A UEFI Application made by kotlin-native
It appears that there *might* be some Kotlin support for UEFI target. There is a new project that hints of this, but project is too new, no docs/comments, looks to not be ready for use yet.
https://github.com/youta1119/kotlin-native-uefi
I suspect this is part of the same person’s KotlinOS project:
https://github.com/youta1119/koslin-os
Qubes: Anti Evil Maid (AEM): improved TPM support
Anti Evil Maid is an implementation of a TPM-based dynamic (Intel TXT) trusted boot for dracut/initramfs-based OSes (Fedora, Qubes, etc.) with a primary goal to prevent Evil Maid attacks. In short, AEM relies on TPM and a feature found in Intel’s vPro CPUs (TXT) to detect tampering of various boot components.
Even if you don’t use Qubes, this is a good read:
[…]To recap — you need to fully trust:
* CPU (Intel, since we’re depending on TXT)
+ sometimes over-optimizes for performance at the cost of security, see eg. Meltdown/Spectre, cache attacks against SGX enclaves, …
* TPM (various vendors)
+ few known attacks sniffing and injecting commands on the LPC bus; differential power analysis; buggy RSA key generation code
+ note that any potential TPM exploits (should) have no means of compromising your system directly — a TPM under attacker’s control can only be used to hide the fact that a compromise has occurred (ie. defeating the whole AEM feature)
* BIOS (a few vendors)
+ it’s full of holes!
* that the attacker cannot get physically inside your laptop without you noticing (see the glitter hint above)
[…]
https://github.com/QubesOS/qubes-antievilmaid/commit/da6c1bacfe5f8864e08efcf7903f9867d40629b3
https://github.com/QubesOS/qubes-antievilmaid
https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
Embedded Rust Book seeks firmware contributors
https://github.com/rust-lang-nursery/embedded-wg/issues/56
https://github.com/rust-lang-nursery/embedded-wg
Note that ‘firmware’ does not appear to be in scope of this book, which is sad. In the current Rust future, we’ll still have to use C for firmware, then Rust for the OS-level embedded code.
Firmware Security 
You must be logged in to post a comment.