Universal Chip Programmer for Security Purposes (2023-24)

Chip programmers are an essential tool for developers to load their firmware into a chip. However, what else is part of the debug protocol implemented in a chip? Are there hidden backdoors for proprietary purposes? Experience shows that quite often, such undocumented debug commands exist at a chip level, resulting in catastrophic security flaws. To investigate the security of chip-level debug protocols, we need to implement a universal chip programmer. Such programmers can also be found "in the wild" and are often used for: vintage computing/archival purposes, chip tuning in the automotive industry, fuzzy testing of the debug protocol as part of a security analysis, etc. The goal of this project is to implement one or more chip-level debugging protocols, rediscover previously known flaws, and possibly to find new interesting results.

Objectives

Based on a given hardware platform, deliver a universal chip programmer that is able to leverage existing chip-level debug weaknesses, in addition to investigating new chips of related chip families. Together, we will select the chip for which the debug commands are going to be implemented.

Motivations

Chip programmers are typically for a relatively small group of knowledgeable developers. Therefore, some manufacturers invest limited resources to develop the corresponding protocols and programmers. Often enough, the documentation describing the chip programmers contain inconsistencies, or flaws, or simply deviate from what is actually implemented. This led to interesting findings in the past, such as race conditions or hidden commands, that could be used to circumvent security objectives of the chip designers.

Qualifications

Minimum Qualifications:

Two hardware platforms will be offered:

  • Option 1: Glasgow Explorer. This requires a strong background or a substantial effort to learn Amaranth HDL (similar to Verilog/VHDL but derived from Python). For a GUI-like control interface, a Jupyter notebook needs to be developed. Operating system for the development: Linux
  • Option 2: NI myRIO 1900. This requires a strong background in LabView or a substantial effort to learn LabView while having an FPGA in mind. The GUI will be part of LabView. Operating system for the development: Windows
  • Relevant for both options:
    • Curiosity and strong interest in Microcontroller/FPGA security
    • Some familiarity with embedded protocols, such as I2C, SPI, UART (or others)
    • Previous development experience for embedded systems is strongly recommended, i.e., general flow of developing a firmware and debugging it on a chip by setting a hardware break point
    • Knowledge of KiCAD
  • MacOS, in particular Apple Silicon, is not supported for this project (cf. recommended laptop specifications provided by the College of Engineering); if you have a Mac with Apple Silicon, then this is the wrong project for you.

Preferred Qualifications:
  • Experience with a Logic Analyzer is a big plus
  • Understanding how JTAG or other common debug protocols work
  • Strong understanding of microcontroller architecture (interrupts, exception handling, etc.)
  • Previous security-related experience such as reverse-engineering (software or hardware)


Details

Project Partner:

Vincent Immler

NDA/IPA:

No Agreement Required

Number Groups:

1

Project Status:

Accepting Applicants

Keywords:
PythonFPGAOpen SourceMicrocontroller
Card Image Capstone