[…]Death Metal is a toolkit designed to exploit AMT’s legitimate features, as the AMT framework’s functionality, designed for innocent system administration purposes, inadvertently allows these features to be used by hackers for surreptitious persistence. This is because many of the legitimate features violate the expectations of sysadmins and endpoint protection software. I liken AMT to “lolbins,” which is a short form of “living off the land binary,” but instead of operating at a software level, Death Metal operates from a hardware level. With the Death Metal suite, we are essentially misusing and abusing mainstream commercial functionality in unexpected ways. Within the information security community, attacks against AMT itself are not news; however, Death Metal will introduce new ways to begin attacking the AMT framework in a practical, red-team fashion.[…]
I just noticed this project, and it’s been around for years, and I’ve been using UEFI and Python for years, sigh. 😦 It appears the developer is Max Wu of Phoenix. There is a blog, in addition to the tool. The blog has also been around for a long time, last post was last month, on UEFI topic not scoped to EfiPy.
EfiPy is a Python Module on UEFI shell which can access UEFI BIOS kernel interface:
– System Table
– Runtime Services
– Boot Services
pAnalyzer package –
Tracing UEFI protocol calling flow
Output protocol flow to screen or file with XML format
CorePy (assembly package) –
Simple Assembly code in Python environment.
EfiPy Shell package-
Simple uefi shell program coded with EfiPy library to prove EfiPy workable
EfiPy leverage these open source packages – ctypes, CorePy.
Can be used to parsing the following payload: (Include but not limit):
* Microcode Payload
* Capsule Payload
A GUI Test Tool comparing JSON with SPEC using excel
Vitaly Chipounov has released PyKVM on the S2E-dev mailing list:
It is my pleasure to announce PyKVM, a tiny KVM client written in
Python. PyKVM lets you efficiently symbolically execute binaries that
don’t interact with the OS and don’t need virtual hardware. There is no
hardware to emulate and no OS to run, which removes all the unnecessary
overhead. You can also reuse your Python-based program analysis tools,
which can easily access the concrete state of the VM. Finally, you can
get a better understanding of how KVM works in very little code.
This client is compatible with the KVM extensions for symbolic execution provided by S2E. In other words, you can symbolically execute programs with PyKVM.
MicroPython for UEFI systems is available, see Brian’s edk2-devel list posting and the Tianocore wiki for more details:
Intel has created Python bindings for their Persistent Memory SDK.
BIOS-UEFI Firmware Tools Engineer
As BIOS-UEFI Firmware Tools Engineer you will develop tools and scripts needed for build and test automation infrastructure that is the backbone of the the Continuous Integration process in Intel’s Data Center UEFI firmware BIOS team.[…]
PS: I need to figure out a way to get some swag/etc from jobs that’re filled via this blog. ;-(
PS: Intel HR: spaces in URLs is generally frowned upon.
[…]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.[…]
In the beginning, Intel maintained CPython 2.x for UEFI. Current version is 2.7x. It looks like they may have stopped porting it, I am unclear.
In addition to Intel’s CPython 2.7x port, recently Google has proposed updating CPython 3.x to support UEFI, see:
I may’ve missed it, but I not sure Intel is involved with this effort.
At the UEFI Plugfest later this month, Intel is giving a talk about MicroPython for UEFI, “Implementing MicroPython in UEFI”. So I am *guessing* that Intel has chosen MicroPython over CPython. I presume this means that CPython 2.7x port is now abandonware. I hope the CPython 3.x proposal is not dead, because of this MicroPython effort. Hoping both get traction, but will not hold my breath…
Differences between CPython and MicroPython:
Once once of these Python 3.x implementations works, and the CHIPSEC project ports from 2.x to 3.c, I can finally stop using v2!!
Unicorn Engine tutorial
Jan 14, 2018
In this tutorial you will learn how to use Unicorn Engine by solving practical exercises. There are 4 exercises and I will solve the first exercise for you. For the others I am providing hints and solutions, which you can obtain by clicking the spoiler buttons.[…]
Examining Personal Protection Devices: Hardware and Firmware Research Methodology in Action
Todd Manning, Duo Labs
[…]This paper describes a methodology for retrieving device firmware, and for loading firmware into IDA Pro, a common disassembler. This paper focuses on the disassembly of this firmware, and the discussion of a novel approach to defeating readback protection discovered in one ARM Cortex M implementation. During the course of this research, I developed code for IDA Pro to assist in loading and grooming Cortex M firmware images. The IDAPython code is comprised of two modules. The first module annotates Cortex M vector tables, which gives IDA Pro hints about where code exists in the firmware image. The Cortex M module can automatically annotate firmware with a vector table located at the start of a firmware image, or can be tailored by the end user to work with relocated tables. The second module, called Amnesia, uses byte-level heuristics to detect ARM instructions in the firmware. Amnesia also contains heuristics that operate at the ARM instruction level to determine function boundaries based on common ARM function prologues and epilogues.[…]
Cortex M Firmware (cortex_m_firmware.py): This Cortex M Firmware module grooms an IDA Pro database containing firmware from an ARM Cortex M microcontroller. This module will annotate the firmware vector table, which contains a number of function pointers. This vector table annotation will cause IDA Pro to perform auto analysis against the functions these pointers point to. The Cortex M Firmware module also calls into the Amnesia module to automate discovery of additional code in the firmware image using the Amnesia heuristics.
Amnesia (amnesia.py): Amnesia is an IDAPython module designed to use byte level heuristics to find ARM thumb instructions in undefined bytes in an IDA Pro database. Currently, the heuristics in this module find code in a few different ways. Some instructions identify and define new code by looking for comon byte sequences that correspond to particular ARM opcodes. Other functions in this module define new functions based on sequences of defined instructions.
Thiebaud Weksteen of Google posted a message on the UEFI Forum EDK2 and Python development lists, asking for help with an official port of Python for UEFI. Please help out if you can!! Excerpt of his message below, full message (and thread):
UEFI has become the standard for firmware (BIOS) interface. Intel has provided an open source implementation under the name EDK2 (part of the TianoCore initiative)  for some time. This implementation has evolved significantly and now provides the functionalities of a small OS with a standard library similar to POSIX. In 2011, a port of Python 2.7.1 was added to the EDK2 repository . This port then evolved to 2.7.2 which is still defined as the reference port . In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 . Since then, both implementations have diverged from upstream and know vulnerabilities have not been fixed. I would like to bring support for edk2 in the official Python repository to remediate this situation, that is officially support edk2 as a platform. Technically, there would be three main aspects for the on-boarding work:
1) Fix headers and source to resolve definition conflicts, similarly to ABS definition in ;
2) Add the edk2module.c  to handle platform-specific functionalities, similarly to the posixmodule.c;
3) Add the build configuration file  and necessary modifications within Python to handle the edk2 toolchain;
This work would target the master branch (that is Python 3). I would be interested in hearing your thoughts on this idea.
Advanced Apple Debugging & Reverse Engineering
Explore code through LLDB, Python and DTrace, to discover more about any program than you ever thought possible.
meloader is an Intel Management Engine a.k.a Intel ME firmware loader plugin for IDA.[…]
“Microparse: Microcode update parser for AMD, Intel, and VIA processors written in Python 3.x.”
Security Analysis of x86 Processor Microcode
Daming D. Chen, Gail-Joon Ahn
December 11, 2014
Modern computer processors contain an embedded firmware known as microcode that controls decode and execution of x86 instructions. Despite being proprietary and relatively obscure, this microcode can be updated using binaries released by hardware manufacturers to correct processor logic faws (errata). In this paper, we show that a malicious microcode update can potentially implement a new malicious instructions or alter the functionality of existing instructions, including processor-accelerated virtualization or cryptographic primitives. Not only is this attack vector capable of subverting all software-enforced security policies and access controls, but it also leaves behind no postmortem forensic evidence due to the volatile nature of write-only patch memory embedded within the processor. Although supervisor privileges (ring zero) are required to update processor microcode, this attack cannot be easily mitigated due to the implementation of microcode update functionality within processor silicon. Additionally, we reveal the microarchitecture and mechanism of microcode updates, present a security analysis of this attack vector, and provide some mitigation suggestions. A tool for parsing microcode updates has been made open source, in conjunction with a listing of our dataset.
Intel has a new Anaconda Python distribution, built with Intel libs to enhance speed/concurrency to help.
It is registration-required freeware if you download it from Intel. It mentions below that it might also be installable via Anaconda, unclear if registration is required for Anaconda. I’ve not found the source to this project yet, but I could’ve missed it.
A few excerpts from their home page below:
Get up to 97 times faster numerical processing on SciPy stack: NumPy, SciPy, and scikit-learn boosted by the Intel® Math Kernel Library. Speed up data analytics with pyDAAL and parallelize Python workloads with enhanced Intel® Threading Building Blocks (Intel® TBB).
The all-included, out-of-the box distribution accelerates core Python packages including NumPy, SciPy, pandas, scikit-learn, Jupyter, matplotlib, and mpi4py. It integrates the powerful Intel® Math Kernel Library (Intel® MKL), Intel® Data Analytics Acceleration Library (Intel® DAAL) and pyDAAL, Intel® MPI Library, and Intel® Threading Building Blocks (Intel® TBB).
Multithreaded Python workloads can take advantage of multicore architectures from Intel using Intel TBB optimized thread scheduling and efficient communication with the Intel MPI Library.
Installing and managing your Python environment is made easy with the all-in-one installer from Intel or by installing packages from Anaconda Cloud using conda. Third-party packages can be installed with both conda and PIP.
Use the Intel® Distribution for Python powered by Anaconda as a drop-in replacement for your current Python environment to get high performance out of the box. Your Python applications immediately gain significant performance and can further be tuned to extract every last bit of performance using the Intel® VTune™ Amplifier.
The Intel® Distribution for Python is available for free for Python 2.7.x and 3.5.x on OS X*, Windows* 7 and later, and Linux*.
PS: Alas, this does not to appear to be integrated with Intel’s port of CPython to UEFI. 🙂