VxHunter: A ToolSet for VxWorks Based Embedded Device Analyses. The firmware analyze tool is plugins written in Python, mainly used for analyze firmware loading address, fix function name with symbol table and etc.[…]
“DeathMetal is a suite of tools that interact with Intel AMT…a foray into a world filled with intrigue & reversing puzzles with useful results. Since this is super serious, tools are named after Metalocalypse characters.” Good stuff @coalfirelabs https://t.co/ZDt0d3RPjW
[…]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.
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.
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.[…]
[…]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.[…]
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…
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.[…]
I'm proud to release my first blog post, paper, and code repository since joining Duo Security. The paper is entitled "Examining Personal Protection Devices – Hardware & Firmware Research Methodology in Action"
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.
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.
“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.