VxHunter: firmware analysis tool for VxWorks-based embedded devices, supports Ghidra and IDA

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.[…]

https://github.com/dark-lbp/vxhunter

PS: See also an ICS security tool by the same author, based on Routersploit:

https://github.com/dark-lbp/isf

The Death Metal Suite: a toolkit designed to exploit Intel AMT’s legitimate features

[…]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.[…]

https://github.com/Coalfire-Research/DeathMetal/blob/master/README.md

https://www.coalfire.com/The-Coalfire-Blog/April-2019/The-Death-Metal-Suite

EfiPy: Python Library for accessing UEFI BIOS internal function by protocol

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.

http://efipy.blogspot.com/2019/02/get-ipv4-information-via.html

https://sourceforge.net/projects/efipy/

https://sourceforge.net/projects/efipy/files/

PyKVM – a tiny KVM hypervisor written in Python

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.

https://pypi.org/project/pykvm/
https://github.com/S2E/pykvm
http://groups.google.com/group/s2e-dev
http://s2e.systems/

MicroPython for UEFI and Intel MicroPython-based UEFI test framework released

Re: https://firmwaresecurity.com/2018/03/20/intel-implementing-micropython-as-a-uefi-test-framework/

MicroPython for UEFI systems is available, see Brian’s edk2-devel list posting and the Tianocore wiki for more details:

https://lists.01.org/pipermail/edk2-devel/2018-August/028339.html

https://github.com/tianocore/edk2-staging/tree/MicroPythonTestFramework

https://github.com/tianocore/edk2-staging/tree/MicroPythonTestFramework/MicroPythonPkg

https://github.com/tianocore/edk2-staging/tree/MicroPythonTestFramework/MpyTestFrameworkPkg

https://micropython.org/

Intel seeks BIOS/UEFI Tools Developer

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.[…]

https://jobs.intel.com/ShowJob/Id/1573600/BIOS%20UEFI%20Firmware%20Tools%20Engineer

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.

 

Intel: Implementing MicroPython as a UEFI test framework

https://software.intel.com/en-us/blogs/2018/03/08/implementing-micropython-as-a-uefi-test-framework

MicroPython for UEFI - Stack Overview

MicroPython for UEFI

[…]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

UEFI Python: CPython 3.x or MicroPython 3.4?

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:

https://firmwaresecurity.com/2017/11/01/proposal-for-cpython-v3-x-for-uefi/

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…

https://micropython.org/
https://github.com/micropython/micropython

Differences between CPython and MicroPython:
http://docs.micropython.org/en/latest/pyboard/genrst/index.html
https://pypi.python.org/pypi?%3Aaction=search&term=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!!

MicroPython Logo

 

EternalRed0’s Unicorn Engine tutorial

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.[…]

http://eternal.red/2018/unicorn-engine-tutorial/

http://www.unicorn-engine.org/

https://github.com/unicorn-engine/unicorn

Duo Labs releases: IDAPython, Coretex M Firmware and Amnesia modules

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.

https://duo.com/blog/examining-personal-protection-devices-hardware-and-firmware-research-methodology-in-action

https://github.com/duo-labs/idapython

Proposal for CPython v3.x for UEFI

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):
https://lists.01.org/pipermail/edk2-devel/2017-November/016805.html

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) [1] 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 [2]. This port then evolved to 2.7.2 which is still defined as the reference port [3]. In 2015, another port was added of Python 2.7.10 in parallel of 2.7.2 [4]. 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 [5];
2) Add the edk2module.c [6] to handle platform-specific functionalities, similarly to the posixmodule.c;
3) Add the build configuration file [7] 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.

[1] https://github.com/tianocore/edk2
[2] https://github.com/tianocore/edk2/commit/006fecd5a177b4b7b6b36fab6690bf2b2fa11829
[3] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonReadMe.txt
[4] https://github.com/tianocore/edk2/commit/c8042e10763bca064df257547d04ae3dfcdfaf91
[5] https://gist.github.com/tweksteen/ed516ca7ab7dfa8d18428f59d9c22a3e
[6] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/Efi/edk2module.c
[7] https://github.com/tianocore/edk2/blob/master/AppPkg/Applications/Python/PythonCore.inf

 

new book on Apple reversing/debugging

Advanced Apple Debugging & Reverse Engineering
Explore code through LLDB, Python and DTrace, to discover more about any program than you ever thought possible.

https://store.raywenderlich.com/products/advanced-apple-debugging-and-reverse-engineering?_ga=2.129698885.852507492.1502412840-255700375.1502412840

 

microparse

“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.

https://github.com/ddcc/microparse

 

Click to access 2014_paper_microcode.pdf