| Episodes | 223 |
| Mentions | 383 |
| Cited here | 105 |
| First — last | #9 — #726 |
| Top guests | Alvaro Prieto, Matt Liberty, Jeff Keyzer |
| Related | microcontroller · fpga · oscilloscope · usb · firmware update |
Firmware is software stored in and bound to a hardware product, spanning the whole stack from bare-metal bootloaders up to network services, and hardware built without it has no function.[336] Because functionality that can be changed after shipping is worth more than functionality fixed in the board, product teams now typically employ several firmware engineers for every hardware engineer.[219] On a typical embedded project the firmware effort runs at least twice as long as the hardware effort, and unlike the hardware its scope tends to keep growing after the board is frozen.[368] Firmware also carries commercial weight: capabilities of shipped hardware are routinely enabled, licensed, withheld or revoked through firmware alone.[65][72][339]
Role in product development
Product team composition has shifted away from hardware: where a design once needed several hardware engineers, teams now run closer to one hardware engineer to four firmware engineers to five software engineers, because functionality that can be changed after shipping is worth more than functionality fixed in the board.[219] Below roughly ten engineers a company tends to field generalists who do both hardware and firmware; beyond that size dedicated firmware staff appear, while the electronics team increasingly consists of combined electrical and firmware designers doing system-level work.[505] In a small vehicle team one engineer may write the firmware for both the drivetrain and the braking system, so a change in one subsystem can be traded against its effect on the other directly, whereas large organisations split those subsystems across teams and mediate the same trade through specification and meetings.[134] Demand for firmware engineers in Silicon Valley has persistently exceeded supply, with recruiters unable to fill roles and hiring managers reporting difficulty finding merely competent candidates rather than exceptional ones.[363]
Firmware once required an electrical engineering background, an understanding of computer architecture and habits suited to severely constrained resources; larger memories and frameworks that provide a working foundation have since made it practical for software teams to take on embedded projects, leaving board support packages, driver development and power optimisation as the specialist remainder.[556] The baseline expectation for a hardware engineer is the ability to write the firmware for their own board, treating C or C++ as a basic tool of the trade with a scripting language such as Python as glue for quick instrumentation and data handling.[355]
Published time breakdowns from one open-hardware manufacturer put firmware at only about five percent of engineering effort, against 2.5 percent each for board design and breadboarding and ten percent for revising and reworking prototypes; writing libraries consumed roughly three times as much time as firmware, because the library work is what makes subsequent firmware quick.[219] Even so, a product that looks simple from outside can spend six months in firmware after the hardware is finished, and USB in particular carries far more implementation work than its presence in a specification suggests.[462] Getting a fabricated chip to the point of being characterised requires a board, assembly, wire bonding, probing and firmware, and that supporting software effort is comparable in size to the chip design itself.[483] Hardware consulting work arrives in discontinuous blocks because each board must be fabricated and assembled before the next task exists, whereas firmware work is continuous, so a consultant who adds firmware to their offering smooths both schedule and income.[601]
Allocation of function between firmware, hardware and host
Test instruments split their processing between firmware, which is fast enough for real-time work but inflexible, and a host or embedded PC running the user interface where sophisticated post-processing is practical; higher-end instruments often carry both a PC for the interface and a separate processor for number crunching.[117] The same trade appears in radio equipment: moving frequency tuning from the host into device firmware removes one USB round trip per tuning command, which is what makes a fast sweep across a six gigahertz range practical where a host-driven loop is limited by USB latency.[352] On Linux-class systems the question recurs as which side loads a coprocessor’s firmware: under the newer remoteproc driver the kernel loads it, whereas the older UIO driver left that to a userspace application, with memory-mapping and shared memory still available beneath either.[378]
Keeping a sensor node’s firmware to acquisition and light reduction while running the complex algorithm on a server makes the firmware much simpler and lets the algorithm be re-run over an existing data set a thousand times instead of requiring a download, flash and wait cycle for each change.[511] The same logic underlies running a single static firmware load on a sensor node’s microcontroller whose only job is translating wireless commands into I2C or SPI transactions, with the sensor drivers kept on the Linux host; putting the drivers on the microcontroller instead makes dynamic sensor swapping impractical because a small part cannot hold every driver.[723] Layering an embedded system means keeping the firmware to a small, always-correct function such as listening for a signal and switching a relay, and placing policy that changes often at a higher level; writing scheduling logic that will be adjusted daily into C on a microcontroller is what makes such systems unmaintainable.[654] Replacing a fixed command set with a publish-and-subscribe model implemented in the device firmware, where the host sends topics and values that the device dispatches individually, removes the need to define a new message every time a control is added.[607]
A general-purpose USB peripheral is really three coupled deliverables — the device firmware, the host-side library, and the protocol over USB that joins them — and designing the protocol to keep the device general rather than special-casing each use is the hard part.[318] Moving from an external USB-to-serial bridge to a microcontroller with an integrated USB peripheral removes the protocol overhead that made bulk operations slow, but transfers responsibility for the USB device stack into the firmware.[125] Bluetooth Low Energy is a different protocol from classic Bluetooth and has no serial port profile, so any product wanting a serial-like link over BLE must construct one over its attribute protocol.[516]
Building a soft processor on an FPGA with a custom peripheral inverts the usual selection problem: rather than hunting for a microcontroller with the right mix of interfaces and then writing intricate firmware that leans on DMA to fake a missing peripheral, the missing peripheral is implemented in fabric and the firmware becomes trivial.[423] Where a microcontroller has fewer hardware PWM channels than the design needs, the shortfall is made up in software, which consumes processor time and is a common reason a part ends up tapped out.[330] Electromagnetic compatibility problems can often be resolved in firmware rather than by respinning the board, which is one reason understanding EMC makes an engineer better at firmware as well as at layout.[472] For power-constrained remote devices, resolving configuration at build time and reflashing when requirements change costs less energy than carrying a general runtime-configurable implementation.[723]
The most effective low-power firmware pattern is to wake, complete the work quickly and return to sleep, rather than leaving the processor active while waiting on sensors; gating individual peripherals within an active burst usually saves so little that a single power-up and power-down per operating mode is the better trade.[527] Battery life is dominated by firmware behaviour rather than by the cell: failing to shut down a peripheral or to enter sleep swamps the design’s nominal budget, which is why measuring the current profile against a battery emulator is what connects the power-measurement specialist and the firmware author.[640] Characterising a cell by discharging it at varying currents and recording the voltage under load reconstructs its internal resistance at each state of charge, and driving that curve from a battery emulator rather than a real pack is what makes firmware power optimisation repeatable.[640]
Some systems depend on non-standard infrastructure firmware rather than on commodity equipment: low-power devices that harvest their link from ambient radio require a modified access point whose firmware transmits continuously at the full one watt rather than in the usual duty-cycled bursts.[253] Configuration-driven firmware generators build a device image from a declarative description of the attached hardware, which is supportable because the space of valid configurations is known; once a user edits the underlying C or C++ directly, a later refactor of a component will break those local changes and the maintainers cannot support the result.[657]
Memory and resource constraints
Shipping a product whose firmware only just fits the available memory is a serious mistake, because any later bug fix or feature must then displace existing code; selecting the part with headroom, such as a 128 kB device rather than a 64 kB one, is cheaper than the assembly-language optimisation the alternative eventually forces.[296] Running out of program space converts every later fix into an optimisation exercise: one defect correction had to be paid for by shrinking existing code, and a desirable diagnostic feature showing the firmware revision at power-on could not be added at all.[403] A firmware update can change a shipped instrument’s behaviour, but making the behaviour user-selectable requires holding both implementations; on one meter there was insufficient program memory to carry both, so the choice had to be made for the user.[690] Choosing the processor before the firmware exists fixes the memory budget by guesswork, so the firmware team inherits a hard constraint they had no input on and must reconcile it with a delivery date, usually by cutting features late.[363]
Bootloaders and field updates
A field-updatable device typically holds a small bootloader in flash that runs first at every boot, checks the application image for validity and only then transfers execution to it; the application in turn provides a way to re-enter the bootloader so a new image can be accepted.[212] The transport used to deliver an update is incidental to the bootloader design: CAN, USB or a plain UART all work, and the choice follows whatever communication path already exists in the product; in vehicles CAN is used because the modules cannot be removed and reprogrammed through their JTAG headers.[212] Vehicle over-the-air update works through a gateway that receives images and distributes them over the internal bus to each of the many microcontrollers, which listen for the update addressed to them; the same modules can also be programmed individually on the bench when they are out of the vehicle.[662]
A safe over-the-air update needs a second image slot: the new firmware is downloaded into the spare region, checksummed and verified there while the running image remains intact, and only then is control handed over, after which the old slot becomes the spare for the next update; overwriting in place generally works exactly once.[364] Enabling a new update transport in a shipped product usually requires modifying the bootloader itself, which is the one component that cannot be safely changed by the update mechanism it implements.[364] Bootloaders must be exceptionally reliable because a failure is unrecoverable in the field, and the compensating advantage is that they generalise well: most of a bootloader, particularly the higher-level update protocol, can be shared across every component in a system with only platform-specific adaptation.[518] A wireless module carrying a vendor Bluetooth stack can accept a bootloader alongside it so that new firmware is delivered over the air or over USB device firmware update, which is what allows a product to be sealed in its case and still be updated.[510]
The programming and update story for a connected product has to be decided early, because it determines the firmware architecture, the security model for getting images onto the device and what backend is needed to serve them; deferring it risks omitting something as simple as a device firmware update button that cannot be added later.[526] Not every deployed product needs a network update path: where field technicians already visit the equipment, an update carried on removable media is sufficient, and a device programmed once with information that never changes needs no update mechanism at all.[526] For connected consumer products the firmware flashed at the factory is a gold master burned three to four months before the unit reaches a customer, so the only requirements on it are that it boots, reaches the backend and successfully takes an update; the feature set can then land on day zero rather than at manufacture.[363]
A defective field-update path can brick the device it is meant to service: one 3D printer had a known bug in which attempting a firmware update erased the part, and recovery required disassembling the machine and reprogramming the microcontroller directly through its in-circuit header.[230] Adding a second processor to a design adds a second firmware image to maintain, and updating it in the field usually requires the main processor to relay code to it; a power loss during that relay can leave the secondary device unprogrammed, which is why a slower single-processor design talking over SPI is often preferred.[187] Where a per-unit secret is stored in the same flash as the application, field updates become impossible, because reprogramming erases the secret along with the code; the firmware must therefore be correct at first programming.[599]
Regulatory pressure has made secure boot and a safe over-the-air upgrade cycle, including a power-on self-test of the image, a requirement rather than an option for general-purpose microcontrollers; all of it rests on a high-assurance initial boot stage, which is where the silicon design effort concentrates.[687] A root of trust boots an otherwise untrusted system in stages, with a first-stage bootloader in unchangeable ROM verifying the next stage and so on up the chain; the same component subsequently validates firmware updates and signatures, so that a malicious image is rejected rather than merely a corrupted one.[693] Products shipped without an over-the-air update path and without documentation of their firmware are the ones most exposed to new regulatory requirements, particularly where support obligations extend for years past the end of a product’s sale.[720]
On platforms where the operating system is developed separately from the hardware, an upstream release cannot reach a device until the handset maker integrates it with the low-level firmware specific to that model and republishes it, so update latency and fragmentation are a structural consequence of the split rather than a defect of any one vendor.[56]
Production programming and manufacture
Production programming is best done from a single manufacturing image that contains the bootloader, the application firmware and any per-unit data such as a unique identifier, so the factory performs one programming operation per board rather than a sequence of separate loads.[125] Ordering microcontrollers pre-programmed from the distributor is the standard answer for boards with no in-circuit programming header, which is common on small packages where every pin is committed; the designer sends the firmware file and the parts arrive ready to place.[243] High-volume consumer products are often built from parts programmed before assembly, because the package is too small to carry a programming header, so the firmware must be finished earlier than for low-volume equipment where a connector allows programming just before shipment.[363] Over-the-air update does not remove the need for an initial programming step at manufacture, and there is no update mechanism for that first load, which makes it the one irreversible point in a product’s software lifecycle.[544]
Connected appliances are typically programmed at the factory with a bootstrap firmware carrying manufacturing test routines, so that an operator with no product knowledge can confirm the motors and indicators work; the device then connects over the network on first use to fetch its current firmware.[692] A production test can be reduced to loading test firmware, running it once and reading a pass or fail result, provided the measurement circuitry needed to reach that verdict, including temperature and supply monitors, is designed onto the board itself.[483] Semihosting lets target firmware call file operations that are executed on the host running the debugger, so the embedded code can open and read a file that exists only on the development machine; combined with GDB’s scripting, this is what makes the debugger a practical engine for factory test jigs.[356]
Mask-ROM parts make firmware changes destructive to inventory: because the code is fixed at manufacture, any change scraps existing stock, which is why distributors and manufacturers are reluctant to hold mask-programmed devices.[377] In a configurable multi-die part, the interconnect behaviour is determined by firmware held in one-time-programmable memory rather than by the base silicon, so different products share masks while differing in that stored configuration and in the cheaper metallisation layers.[499] Semiconductor vendors also sell fixed-function parts that are ordinary microcontrollers with firmware preloaded; Microchip’s MCP2200 USB-to-serial device is a PIC18F14K50 programmed at the factory, which lets the vendor create a proven, documented product from existing stock without a new silicon design.[30]
Bootloaders that rely on a microcontroller’s internal oscillator can fail on particular silicon revisions where that oscillator is not stable enough to hold the serial bit rate, a defect that only appears once boards are being programmed in volume.[125]
Development practice
Bring-up of a complex board starts at the power supplies before any attempt to run code, and only then moves to the debug interfaces; on a board carrying DDR3, an FPGA, a USB transceiver and a separate power-sequencing microcontroller, that sequencing part is itself the first firmware target.[469] A Zynq-class part boots differently from a plain FPGA: the ARM cores come up first and are responsible for bringing up the fabric, so bring-up runs JTAG to the ARM side, then routes a debug UART out through a companion microcontroller over USB, then ports U-Boot into the boot flash, and only then attempts to boot Linux.[469]
Committing early to a real board rather than a breadboard mock-up means the eventual production layout is largely finished and the firmware has been developed on the final platform, so neither has to be redone; the counter-argument, that hardware must be proven before committing to a PCB, is usually a budget constraint rather than a technical one.[110] Bringing up a new chip on a development platform and exercising it with real commands produces working driver code that can be handed straight to the firmware effort, so the evaluation step doubles as the first increment of the product’s firmware.[110] Modern evaluation-kit software generates the register initialisation sequence for a part, so a customer can blue-wire the new device into a previous-generation product, tune it through the kit’s interface, dump the resulting settings and hand that configuration to the firmware engineer to implement.[270] Firmware can be written and self-tested against a schedule before the board returns from manufacture, so that bring-up starts from complete code rather than from nothing; this is the standard answer to the software team idling while hardware is fabricated.[230]
The most common failure in embedded projects is beginning to code before the design is settled and documented; systems of around a thousand lines can be coded directly, but at hundreds of thousands or millions of lines that is untenable.[489] Formal code review, performed before testing rather than after, is the cheapest available route to quality code; the inspection process devised by Michael Fagan in 1976 remains the reference method, and the knowledge that review is coming changes how the code is written.[489] A sole developer with no colleagues to review their code should substitute distance for a second reader: set the code aside for several days or a week before testing it, on the assumption that the code will still be read in twenty years.[489] A consultant’s firmware deliverable includes its documentation, not merely the binary; treating documentation as part of the product is the first step in bringing firmware work up to the quality-control discipline that hardware deliverables already have.[492] Contract work inside an established organisation supplies mutual review between the incoming engineer and the resident staff, whereas being the sole engineer at a small company removes that check entirely, and reviewing one’s own work repeatedly reliably fails to catch the defect that matters.[492]
Electronics engineers entering the workforce now routinely do firmware as well as hardware, so they encounter Git regardless; putting hardware design into the same version control system is therefore an alignment with a tool the same people already have to learn.[505] Maintaining forty separate firmware builds that originated as copies of one another means a single defect must be found and corrected in several of them independently; the remedy applied in one power-supply organisation was moving from Subversion to Git with a continuous integration pipeline so the variants share history rather than being duplicated.[522] Two products with different radio front ends were kept in a single firmware repository in the HackRF project, so one clone of the tree builds the image for either board.[352] Two engineers compiling the same firmware source can produce different binaries when their toolchains differ, so building in a shared container or on a build service and distributing that image is what makes the output reproducible across a team.[654]
Vendor-supplied peripheral stacks can carry licence terms that permit use but forbid redistributing the source, which forces an open project to keep the vendor code in a separate tree and ship an incomplete source release that will not compile in one step.[125] An integrated development environment’s build console shows the actual compiler invocation and its flags, so an engineer can learn what the toolchain is doing without assembling it by hand; that visibility is what makes the difference between following a vendor’s clicks and being able to diagnose a build.[470] Extending MicroPython means adding a C source file to the open-source tree and marking its functions with macros that declare how they are exposed to the interpreter, then compiling the whole tree to a binary image that is flashed to the board; the REPL that results is itself part of that firmware rather than a layer above it.[323]
Simplified beginner environments stop scaling at the point where real debugging is needed, so an engineer moving into firmware seriously has to leave them.[479] Firmware is not organised as a discipline in the way computer science is; it is “a collection of lore over 30, 40 years”, largely defined by what silicon vendors have shipped, so there is no mathematically grounded best way to do a given thing, only a peripheral, its registers and its exceptions.[479] The characteristic difficulty of learning firmware is that a failing procedure gives the beginner no way to tell whether the instructions are wrong or their execution of them was; an embedded target is a complete system of parts and memories in which many things can break through no fault of the person following the steps.[479] Stepping code in a debugger and inspecting the peripheral registers afterwards is what distinguishes a wrong assumption from a wrong implementation; a register believed to be configured may turn out to be untouched because the wrong page was selected, which no amount of print-based debugging reveals cleanly.[479]
Continuous integration, testing and simulation
Continuous integration for firmware requires attached target hardware, a programming path and an automated agent that compiles each commit, installs it and runs a test procedure, which makes it substantially harder to set up than for a pure software project; its value is that a change that breaks something is caught immediately rather than a month later.[161] The target state is that any commit, however small, is compiled, flashed to a board mounted in a test stand and run through the whole test suite, producing a report; the reason to run every test rather than a selected subset is that the cost of running them is low compared with the cost of an escaped regression.[505] Hardware-in-the-loop testing has been run in practice by having a build server push each new firmware build to a machine that then exercises its full range of motion and confirms it does not crash; what makes this harder than software testing is that the assertions depend on real-world measurements and instrumentation.[505] The gap most firmware teams stall in is between building an image automatically and doing anything with it; closing it means having the build system flash a real device and run tests against it, so a failing push is reported as a regression rather than as an unopened artefact.[537] System-level automated tests go beyond unit tests by exposing a lightweight command shell on a serial port, having the test rig issue single commands such as turning on a heater, and measuring the physical result through an analogue input or an external probe, so the assertion covers the hardware as well as the code.[537]
Simulating a board means instantiating a scripted description of the platform and then loading the same firmware binary that would be flashed to real hardware, so the artefact under test is unchanged and the setup collapses to a few lines of scripting.[519] Recording a physical test run once with a logic analyser and replaying it against a simulator turned forty test cases of two to three minutes each into a suite that completed in five seconds, taking the edit-to-result cycle for a firmware change from roughly half a day to seconds.[599] Because a custom chip takes about nine months to return from the fab, the validated RTL can be ported to an FPGA with wrappers mapping the design’s signals to the FPGA’s pins, and the microcontroller firmware that will eventually drive the chip developed against that FPGA, so the interface between them is debugged before silicon exists.[721]
Language-model assistance on embedded work is effective once the hardware is already up and the device tree and drivers are resolved, where it can build application-level structures such as a menu system; it remains unhelpful for the earlier problem of getting a sensor working at all.[713] Machine assistance on firmware is currently strong at localised bug fixes and weak at architecting whole systems, so the return depends on recognising early which of the two a task is; the risk is spending longer steering the tool than the work would have taken directly.[722]
Failure modes and diagnosis
Engineers blame the silicon roughly ten times for every one occasion the silicon is actually at fault; the usual resolution is an error in their own firmware, and the most common genuine field failure reported against a part is not the part at all but oscillator start-up caused by wrong crystal load capacitors on the customer’s board.[485] A single incorrect configuration bit in a firmware change can produce a plausible but wrong measurement: flipping the line-frequency setting used for an integration period made readings come out at five sixths of their correct value, an error small enough to survive casual inspection.[533] Firmware that blocks waiting for a peripheral to respond will prevent the whole product from booting whenever that peripheral is unpowered; a device that ran correctly on USB failed to start on battery because the five volt rail the sensor needed was only present when USB was connected.[623]
Bring-up work sits at the boundary between disciplines: when code will not run, the person doing it must read the schematic with an electrical engineer and confirm the rails come up and the layout is right, because faults such as inverted DRAM line polarity or misrouted battery signals present as firmware failures.[556] Diagnosing a production line failure means separating four candidate causes — the hardware, the firmware, the test station itself and intermittent behaviour — and narrowing that down requires the hardware skill set as much as the software one.[556] Part numbering can hide an architecture change: GigaDevice’s GD32F103 is a register-level match for the STM32F103 and is an ARM device, while the GD32VF103 differs by a single letter and is RISC-V, so firmware and toolchain assumptions carried over from the part number will be wrong.[462]
Maintenance, obsolescence and revision
Component obsolescence is far more disruptive than in the discrete-logic era: replacing a 74-series part meant accepting a logic change, whereas replacing a modern integrated part invalidates firmware and the software layered on top of it, so the engineering change propagates through the whole system.[126] When a board is revised, keeping the connector and pin assignments compatible is only half the job; if the firmware also diverges between revisions the maintenance burden multiplies, because every subsequent change must be made and tested in each variant.[207] Substituting a sensor because the original is unobtainable branches the firmware as well as the bill of materials, so a board with many revisions ends up with a matching tree of firmware builds that must be tracked and loaded correctly per unit.[573] Repeated board spins driven by part availability leave a long tail of firmware conditionals, one per substituted component, and the resulting maintenance cost outlasts and can exceed the immediate cost of the more expensive parts that forced the changes.[577]
Separating the hardware description from the operational logic, as a device tree does, is what makes changing microcontroller affordable; where pin mappings and controller configuration are embedded directly in the source, unpicking them for a new part is expensive and generates corner-case defects.[711] Some organisations genuinely cannot change processor: without the source for the existing firmware there is no way to produce a functional equivalent, so the decision to migrate has to be taken while the code is still understood.[536] A late architecture change discards prototype work wholesale: a multimeter design that had reached working prototypes on a PIC24F was scrapped when the manufacturer standardised on ARM, and the firmware was rewritten from scratch after roughly nine months of work.[536]
A vendor support page for discontinued vector network analysers carried application notes, manuals, calibration kit definitions and firmware images with per-version change logs; when it was removed, web archiving preserved the pages but not the firmware images themselves, so that material is effectively lost to owners of the instruments.[613] Decompiling a shipped firmware image well enough to locate and correct a defect, and to return a working replacement image, is achievable without access to the hardware or the source, which makes released images a maintenance resource as well as a disclosure risk.[380] For long-lived installed products, the design separates into parts that are physically hard to change and must last the full service life, and parts deliberately made field-swappable so that software platform changes over many years can be absorbed by replacing a module rather than the installation.[487]
Security
Extraction and analysis
The usual objective of hardware attack work is to convert a hardware problem into a software one: get the firmware off the device, understand it, and from then on operate entirely in software to make the device do something it was not intended to do.[346] Attacks are chosen by cost rather than sophistication: network fuzzing, opening the case for debug headers, extracting firmware from flash, and silicon-level side-channel or decapping attacks each carry very different cost, time and skill requirements, and the cheapest route wins; the cheapest route of all is frequently downloading the firmware image from the vendor’s own website.[346] Opening an arbitrary consumer device typically reveals several immediately accessible attack surfaces, such as an exposed firmware image or a live JTAG or debugger interface, and the tools to exploit them are inexpensive, though the security of off-the-shelf products improved measurably over a five-year window of hands-on training work.[346] A sealed consumer sensor built around a Bluetooth microcontroller is generally open to anyone with physical access: reaching the JTAG pads allows the firmware to be dumped for analysis and replaced with the owner’s own.[543]
Smart-card piracy worked by physically opening the card and dumping its firmware so the behaviour could be emulated on a different card, producing functional clones without ever obtaining the original source code.[303] Undocumented memory access commands are a common entry point into a radio chip’s firmware: given a peek command and a sixteen-bit address space, sweeping the full range from zero to 65535 and disassembling the result recovers the firmware without any physical attack.[450] Where no image is published, a foothold of code execution can be used to shift the remaining firmware out one bit at a time through an LED or GPIO line, after which the work moves to a disassembler such as Hopper, IDA or Ghidra.[463] A device that returns a buffer over a bus can be induced to leak its own firmware by corrupting the length field of the transfer, so that the read runs past the buffer and continues through memory into the region where the firmware is mapped.[552]
Extracting a device’s secret does not require reading its firmware: a side-channel attack on a chip that holds a key, including the bitstream-decryption keys used by FPGA vendors, can recover the key from a part that contains no application code at all.[239] Readout protection on an STM32 has been defeated by fault injection that downgrades the part from RDP level 2 to RDP level 1, which restores debug access limited to RAM; that is sufficient because during a firmware update the private data is copied into RAM to protect it, and can be read there.[575] Hardware wallet firmware has been attacked version by version: one published attack against version 1.7.3 exploited a USB overflow triggered by electromagnetic fault injection, and a separate fault-injection route into the same device was closed in version 1.8, so the security posture of such a product is tied to a specific firmware revision rather than to the model.[575] A vehicle key fob built on a CC13xx or CC26xx wireless microcontroller had its firmware extracted using side-channel analysis and glitching with an open fault-injection platform, and the image was then reverse engineered with Ghidra.[582] Firmware stored in an eMMC device can be recovered and modified by removing the package from the board, reading and rewriting it externally, and reballing the BGA to reattach it, a physically destructive route used where no software path to the image exists.[698] A device’s protocol can alternatively be recovered without extracting its firmware at all, by probing the bus between the microcontroller and the radio, recording the traffic and then driving the radio chip directly from a substitute microcontroller.[363]
Disassembly tooling spans a wide cost range: the free version of the dominant commercial disassembler is limited and a licence covering obscure targets costs a thousand dollars or more, while Radare 2 is free but command-line and steep to learn, and Ghidra, released in 2019, provides a graphical alternative at no cost.[450] Reverse engineering firmware proceeds from known anchors outward: identify a byte whose meaning is known from an API call, find where the code compares or writes it, then follow cross-references to that address to infer the purpose of neighbouring code, with each identification constraining the next.[450] Analysing an unfamiliar connected appliance starts with determining whether it runs Linux or a bare microcontroller, because that decides every subsequent technique; the next question is always whether the firmware can be extracted, after which the system can be unravelled piece by piece.[698]
Firmware committed to unchangeable memory can still be made patchable if it is structured for it, by routing behaviour through indirection points that a later soft patch can redirect; reading how commercial devices do this is a practical source of technique.[450]
Threat models and countermeasures
The security requirements for firmware follow the threat model rather than the product category: a device kept behind guarded physical access can treat physical attack as out of scope, whereas a device carried by users and liable to be lost or stolen cannot, and the two lead to different design choices.[418] Security has to enter at component selection: firmware written for a part with no cryptographic accelerator leaves the implementer performing those operations in software, which is the wrong place for them, and no amount of later software work recovers what the hardware choice gave away.[418] USB-C did not reduce the attack surface: any cable or adapter doing more than basic USB contains a microcontroller, and such devices are frequently shipped with direct firmware update left enabled, so an adapter can have its firmware dumped and replaced by whoever holds it.[346] Making the boot key unique per device changes the economics of extraction rather than the physics: decapping and fault injection may still recover a key, but the attacker has likely destroyed that unit and gained access to only that one device’s firmware, with no leverage over the rest of the fleet.[687] One low-cost RISC-V microcontroller’s debug interface is not a protocol for memory operations but a small scratchpad: the host writes code into it and issues a command, the processor halts the running program and executes that code, and flashing and memory writes are all implemented as short routines sent this way — which a controlling processor can also use to write code into every peripheral device’s RAM at each wake-up, removing the configuration-tracking problem of version-matching a separate firmware image in each satellite chip at the cost of the load time.[667]
Commercial and regulatory significance
Where an instrument’s bandwidth grade is set in firmware rather than in hardware, the difference between models is a licensing decision, and a price cut that equalises the two grades makes the firmware modification pointless because the higher-bandwidth unit costs the same.[72] Where a vendor sells extra instrument bandwidth as a licence key, the underlying hardware is already capable and the restriction is a bit set in firmware, so the same physical unit can be unlocked by modifying that state.[339] Instrument capabilities held back for market-segmentation reasons can later be released as a firmware update to hardware already in the field; Agilent added arbitrary waveform generation to its 3000 series oscilloscopes this way roughly nine months after the feature had been withheld to protect its function generator line.[65] Delivering a new capability as a firmware update to hardware the customer already has removes the largest obstacle to evaluation, because the customer is not asked to change their board.[728] The argument for a digitally controlled power converter is that behaviour lives in firmware: an issue found during validation or after the product is in the field can be addressed by a firmware patch supplied to the customer, whereas the analogue equivalent requires a new silicon spin.[566]
A platform vendor that wants third parties to build add-on boards can still reserve for itself the accessories that require changes to the platform firmware, such as camera interfaces, because those cannot be supported without coordinated firmware releases.[97] The Raspberry Pi HAT specification requires an EEPROM on the add-on board describing the mechanical form and how the pins are used, so that platform firmware reads it at boot and configures the interface automatically rather than requiring the user to declare the hardware.[235] The closed portion of the Raspberry Pi platform firmware has shrunk over the years to little more than clock and power management, with the graphics side opened and more support moved upstream into the kernel; what remains closed is third-party silicon IP the vendor is not free to publish.[648] Sub-gigahertz radio gateways need region-specific firmware because the licensed band differs by territory: 915 MHz in the United States and Australia against 868 MHz in Europe, and a stock build compiled for one region will not simply work in another.[393]
Emissions and safety compliance can be defeated in firmware rather than in hardware: Volkswagen shipped code that detected when the vehicle was on a test cycle and changed behaviour accordingly, an approach that is invisible to inspection of the hardware and was applied across roughly half a million vehicles.[269] Agricultural equipment can enforce authorised repair through firmware at the individual component level: a replacement part that the owner has already bought and installed will not operate until a dealer representative approves it, so the constraint is a software interlock rather than a mechanical or electrical one.[341] Vehicle safety modules can likewise be serialised to the car in firmware, so a physically identical replacement part does not function until it is programmed to that vehicle, and a mechanical repair becomes a dealer software operation.[662]
In automotive supply, a subsystem supplier may ship physically identical hardware to competing vehicle makers with entirely different firmware and communication rules, because each maker writes the rules for its own subcontractors and deliberately avoids a shared standard that would permit a second source.[631] A contract manufacturer building a branded instrument may insist on retaining firmware maintenance itself rather than handing it to the brand owner, because the code becomes reusable across its other products; the brand owner’s contribution is domain expertise in specification, test and debug.[362] Hardware can be copied but the accumulated firmware and software cannot, so products carrying substantial software development attract clones of the board without direct functional competitors; the same logic applies to functionality held in an FPGA bitstream.[532] Industrial controllers are trusted for process control because their firmware is a small, heavily vetted operating system written for one task, unlike a general-purpose computer carrying code bloat, driver problems and forced updates; the practical expectation is that such a controller does not lock up.[612] In a regulated product, moving a classifier from a phone application into the device firmware removes the mobile application, the data transfer path and their security review from the certification scope, so the way to reduce testing burden is to shrink what the system contains rather than to lower the standard applied to it; the cost is pushed back into runtime and battery life on the device.[711]