commit 0e27b9e1b05c3df6e8564c7e21a6f38106f20091
parent b13dad6fde3f7b56ae23e29b3c59c9f6d7bff22b
Author: Alex Balgavy <alex@balgavy.eu>
Date: Tue, 16 Nov 2021 12:14:10 +0100
Update hwsec notes
Diffstat:
7 files changed, 258 insertions(+), 0 deletions(-)
diff --git a/content/hwsec-notes/_index.md b/content/hwsec-notes/_index.md
@@ -5,3 +5,5 @@ title = 'Hardware security'
# Hardware security
1. [DRAM (physical memory)](dram-physical-memory)
2. [CPUs](cpus)
+3. [Embedded systems](embedded-systems)
+4. [Firmware](firmware)
diff --git a/content/hwsec-notes/embedded-systems/i2c-electrical-signal.png b/content/hwsec-notes/embedded-systems/i2c-electrical-signal.png
Binary files differ.
diff --git a/content/hwsec-notes/embedded-systems/index.md b/content/hwsec-notes/embedded-systems/index.md
@@ -0,0 +1,164 @@
++++
+title = 'Embedded systems'
++++
+# Embedded systems
+Pervade nearly every aspect of modern life, and their state of security often lags behind.
+
+Embedded system: special-purpose computing system, running software tightly coupled to hardware, as part of a larger system
+
+May have: no/specialized user interfaces, low power consumption and computational power, interfaces to physical world, non-customizable software, non-Avon Neumann architecture
+
+## Core components
+### Memory
+Non-volatile: data persists even if power is removed. holds code, static data, config. Examples are NAND/NOR flash.
+
+Volatile: holds runtime data (stack, heap) and code (copied from NV memory). Examples are DRAM and SRAM (info stored in transistor logic, no refresh needed)
+
+### Peripherals
+Input/output devices, typically interfaced via memory-mapped IO (MMIO)
+
+On-chip: shares chip with processing unit, directly interfaces. Example is a timer.
+
+Off-chip: physical separation from processing unit, connected via bus. Example is WiFi chipset.
+
+### Processing unit
+Generally have workload specific instruction set architecture.
+
+Variants:
+- microcontroller: IC containing also memory and peripherals
+- system-on-chip: IC containing full computing system
+- digital signal processor: microprocessor specialized for digital signal processing
+- coprocessor: microprocessor supporting main processor for specialized tasks
+
+## Inspection tools
+Multimeter: measures voltage, current, resistance. Can be used to see if two pieces of metal on circuit are connected to each other.
+
+Logic analyzer: like a debugger, lets you measure and visualize digital signals. May even provide a decoder.
+
+Oscilloscope: measures and visualizes analog signals over time
+
+## Protocols & interfaces
+### Universal asynchronous receiver/transmitter (UART)
+Used for serial comms between two components
+
+Separate receive (RX) and transmit (TX) lines.
+
+Configurable data format and transmission speeds, agreed beforehand.
+
+- When idling, typically sends high signal.
+- On start, change signal from high to low
+- Data bits sent, 0 is low and 1 high
+- Stop means sending high again.
+
+
+
+Options and common choices:
+- baud rate (bits per second): 2400..115200
+- data bits in word (between start and stop): 5..8
+- parity bit (to check for transmission errors): none, even, odd
+- stop bit (how many high bits for stop): 1, 1.5, 2
+- bit order: LSB first, MSB first
+
+Discovering UART ports:
+1. Consult datasheet if possible
+2. Locate promising headers
+3. Identify grounded pins: continuity test
+4. Identify TX pin: if data transmission enabled, fluctuating voltage observable
+5. Identify RX pin: may require connection to all possible RX pins
+
+### Serial peripheral interface (SPI)
+Synchronous serial bus protocol, connects two or more components on a bus.
+
+Controller/peripheral architecture, with four lines:
+- 2 for data
+- 1 for clock
+- 1 for chip select
+
+
+
+Multi-peripheral configurations:
+- independent: each peripheral has connection to SPI controller, controller has several chip select pins
+- daisy chained: one chip select line, CIPO (controller in peripheral out) of one peripheral goes to the COPI (controller out peripheral in) of the next one
+
+
+
+Discovering SPI flashes:
+- typical device on SPI bus is flash memory, e.g. where BIOS is stored
+- most often visible by eye, likely has manufacturer and part ID on chip
+- open source tooling for SPI flash dumping available, e.g. [https://trmm.net/SPI_flash](https://trmm.net/SPI_flash)
+
+### Inter-integrated circuit (I2C)
+Synchronous serial bus protocol, connects two or more components on a bus.
+
+Multi-controller/multi-target architecture, with two lines:
+- serial data (SDA)
+- serial clock (SCL)
+
+Uses messages:
+- start condition (S):
+ - signalizes begin of message
+ - SDA pulled low while SCL high
+ - from here, SDA only allowed to change when SCL low
+- Address (7 or 10 bits)
+ - determines target to communicate with
+- Read/write bit (RW):
+ - 1: read from target
+ - 0: write to target
+- ACK/NACK bit (A):
+ - transmitter releases SDA
+ - receiver pulls line low
+ - transmitter reads stable low → ACK. if not, NACK.
+- Data (8 bits):
+ - actual payload
+ - for each frame, acknowledgment sent/received
+ - can be arbitrary amount of frames
+- Stop condition (P)
+ - end of message
+ - SDA pulled high while SCL high
+
+
+
+Multi-target architectures:
+- single controller: uses address to see if it should respond with ACK
+- multi-controller: each controller checks if lines are free
+
+Discovering I2C bus:
+1. If available, consult datasheet, look for part IDs on components
+2. Find likely I2C pins, use multimeter to test connection between components
+3. Attach logic analyzer/oscilloscope, check for characteristic I2C comms
+
+### Joint test action group (JTAG)
+Standardized debugging interface, present on almost every prototyping board, and sometimes on production.
+
+Defines:
+- stateful protocol
+- presence of instruction register and data registers
+
+JTAG test access port (TAP)
+- at least 4 lines:
+ - TDI: test data in
+ - TDO: test data out
+ - TCK: test clock
+ - TMS: test mode select
+ - TRST: target reset
+- devices arranged in a chain
+
+JTAG state machine
+- driven by TMS signal
+- two primitive operations: scan DR, scan IR
+- data registers:
+ - boundary scan register (BSR): main data register
+ - BYPASS: used to bypass JTAG logic of specific device
+ - IDCODE: has device-specific information
+- used data register is dependent on current instruction
+
+Discovering JTAG ports:
+- consult datasheet
+- locate promising headers
+- try bypass scan:
+ 1. guess pin configuration
+ 2. continuously send 1s on assumed TDI
+ 3. send BYPASS instruction to TAP
+ 4. wait to receive 1s on assumed TDO
+ 5. if not successful, repeated with other pin configuration
+- automated discovery tools (special boards) exist, such as JTAGulator, JTAGenum, Glasgow
diff --git a/content/hwsec-notes/embedded-systems/spi-multi-peripherals.png b/content/hwsec-notes/embedded-systems/spi-multi-peripherals.png
Binary files differ.
diff --git a/content/hwsec-notes/embedded-systems/spi-signal.png b/content/hwsec-notes/embedded-systems/spi-signal.png
Binary files differ.
diff --git a/content/hwsec-notes/embedded-systems/uart-signal.png b/content/hwsec-notes/embedded-systems/uart-signal.png
Binary files differ.
diff --git a/content/hwsec-notes/firmware.md b/content/hwsec-notes/firmware.md
@@ -0,0 +1,92 @@
++++
+title = 'Firmware'
++++
+# Firmware
+Low-level code driving the system. Application-specific, with direct hardware interactions.
+
+Stored in non-volatile memory, e.. EEPROM, flash memory.
+
+Types of firmware:
+- type-1: general purpose OS-based
+ - popular OS retrofitted for embedded system
+ - hardware interaction abstracted by kernel
+ - example: Linux on a router
+- type-2: embedded OS-based
+ - custom OS for embedded systems
+ - created to solve custom challenges
+ - reduced functionality compared to traditional OS, e.g. no MMU/virtual memory
+- type-3: no OS abstraction
+ - can be entirely custom
+ - may include "OS-library" with OS functions
+ - system and app code compiled together, with no strict kernel/user separation
+
+ARM (Advanced RISC Machine) instruction set family:
+- Cortex-A (application processor): highest performance, optimized for rich OSes
+- Cortex-R (real time): fast response, optimized for hard real-time apps
+- Cortex-M: smallest/lowest power, optimized for microcontrollers
+
+32-bit ARM assembly:
+- registers:
+ - r0-r12: general purpose
+ - r13: stack pointer
+ - r14: link register (return address of last call)
+ - r15: program counter
+ - cpsr: current program status register (has flags)
+- mov instruction reserved for moving things from one register to another
+- no classical push/pop instructions
+
+Memory maps
+- type 2/3 firmware typically has no need or resources for virtual address spaces
+- instead have single physical address, everything mapped at predefined addresses
+
+Firmware programming models:
+- super-loop architecture
+ - single loop for everything: IO, calculations. never returns, or only on error.
+ - simple logic
+ - hard to scale for comms between subsystems, interrupts, and starved inputs.
+- ROTS (real time operating system)
+ - different tasks for different subsystems
+ - primitives for inter-task comms
+ - scheduler can enforce real-time constraints, may use timer interrupts
+
+Interrupts (IRQs)
+- events requiring attention from CPU
+ - generated by hardware or software
+ - processing may be disabled (masked)
+- typically associated with numbers, optionally with priorities
+
+Interrupt vector
+- determines how to handle incoming interrupts
+- maps interrupt numbers to callbacks - interrupt service routines (ISR)
+- reprogrammable during runtime
+
+Interacting with peripherals:
+- interrupts (channel from peripheral to CPU)
+- direct memory access (DMA) allows direct data transfer between memory and peripheral, CPU only needed to initiate the transfer
+- memory-mapped IO (MMIO) - directly interfaces via memory, organize in registers
+ - register types: status, data, control
+- port-mapped IO - not present in ARM, IN/OUT instructions on x86
+
+Typical peripheral accesses:
+- configuration: firmware initialization, before and after peripheral usage
+- status: after configuration for confirmation, to check operationality
+- data: when data to be sent/received
+- reading data:
+ - IRQ-based:
+ - when data arrives, raise interrupt & read and store data in ISR
+ - data arrival is ensured, but async processing ads complexity, and might starve main firmware task due to many interrupts
+ - polling-based
+ - when data expected, loop over status register to check availability, and if available, read data register
+ - so, no sudden changes of control flow, and data only received when desired. but arrival can easily be missed, and lots of time spent polling.
+
+Firmware file formats
+- no standard, usually code and data interleaved
+- unpacking: restoring sections and files from binary firmware image
+
+Firmware extraction:
+- firmware updates: may be downloadable from vendor website, device initiated retrieval is sniffable
+- on-device dump: complex devices may contain flash storage accessible from software, and/or debug shell. for shell, probably need to find UART ports. Once shell access is gained, dump using e.g. `dd` or `xmodem`.
+ - for bootloaders, there might be a bootloader mode. you might need hardware access for that. but may allow to re-flash firmware and to read firmware.
+- debugging interfaces: usually can read memory, a wide-spread interface is JTAG
+- flash dumping: frequently requires soldering, e.g. removing the chip or adding wires to pins of the chip.
+- fault injection: altering intended behavior via faults, could be used to force outputs to be longer, or to skip readout protection checks. most prominent techniques are voltage fault injection and electromagnetic fault injection. likely needs removal of electronic components.
