Uncategorized

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.

 

Standard
Uncategorized

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

Standard
Uncategorized

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

Standard
Uncategorized

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

 

Standard
Uncategorized

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

Standard
Uncategorized

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

Standard
Uncategorized

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

 

Standard