Redfish-JSON-C-Struct-Converter: Convert Redfish JSON resource to C structure and vice versa

[…]Redfish-JSON-C-Struct-Converter is a C client library which used to convert Redfish resource in JSON text format to C structure and vice versa. The functions in Redfish-JSON-C-Struct-Converter library provides the C language friendly structure which can be easily utilized in C programs. Bindings also provided on top of C source/header files for different computer languages and build environments, such as UEFI EDK2 environment or akin to the bindings for Java and Python in libredfish library. Each C file is a converter for the specific version of Redfish schema released by SPFM. For example, ServiceRoot.v1_2_0.c under /ServiceRoot/ServiceRoot.v1_2_0 provides functions to convert ServiceRoot.v1_2_0.ServiceRoot property to predefined RedfishServiceRootV1_2_0_CS C structure. It also provides functions to convert RedfishServiceRootV1_2_0_CS C structure to JSON text file. All C files under /src are built into a single library. Other programs which built with Redfish-JSON-C-Struct-Converter library must links with this library and invokes the conversion functions as it needs.[…]

https://github.com/changab/Redfish-JSON-C-Struct-Convertor

 

PCILeech3 and Memory Process File System released!

Targets 64-bit Intel systems running Windows.

http://blog.frizk.net/2018/03/memory-process-file-system.html

https://github.com/ufrisk/pcileech

Cutter 1.3 released

https://github.com/radareorg/cutter/releases/tag/v1.3

http://rada.re/r/

http://rada.re/gsoc/2018/ideas.html#title_1

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:

https://blog.fpmurphy.com/

 

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

http://openxt.org/

 

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

MicroPython for UEFI - Stack Overview

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/

Xbox-Console-Set by Evan-Amos

 

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

Exynos 4 Dual 45nm

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

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

 

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:

 

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