Why Invalid Commands Are Useful Evidence in Firmware Testing

In secure system design, a device should do what its specification says it

does and nothing else. That should be simple, right?

WiFi router with firmware update timeline graph.

Most firmware testing is built around expected behaviour. A tester sends a valid command, observes the response, compares it against the specification, and confirms whether the device behaves correctly. This is necessary for compliance and functional validation, but it does not answer a more security-relevant question: what happens when the device receives a command it was never supposed to understand?

Invalid commands are often treated as uninteresting. If the command is not in the specification, the expected response is simple: reject it, return an error, and resume normal operation. But that rejection path is part of the implementation, and implementation details matter. A device may return an error while still executing meaningful code before it does so.

That is why invalid commands are useful evidence in firmware testing. They help establish what genuine rejection looks like inside a specific target. Once that baseline exists, other commands that return the same visible error can be compared against it.

If they behave the same way, they are likely being rejected by the same firmware path. If they behave differently, the error response is not the whole story.

The Error Response Is Not Enough

Consider a device receiving commands over UART, CAN, Ethernet, SPI, RS-232, or an AT-style command interface. The control flow is familiar: a message arrives, the firmware parses the input, checks whether the command is recognized, and either routes it to a handler or rejects it.

A valid command usually executes more code than an invalid command. It may touch different memory, invoke specific routines, activate peripherals, allocate buffers, perform authentication checks, update configuration, or write state. A genuinely invalid command should follow a much shorter and more consistent path: parse, reject, return.

At the protocol level, those differences may be invisible. A command that is partially processed, recognized by an undocumented handler, or gated behind a diagnostic condition can still return ERROR. A conventional test harness may record that as a rejection and move on.

PowerFuzzer challenges that assumption. It does not treat the protocol response as the only evidence. Instead, it combines the command sent to the target, the response returned by the target, and a synchronized side-channel measurement that reflects how the target behaved while processing the command.

That additional evidence matters because processor activity consumes power. Different execution paths consume power differently. If two commands both return ERROR but produce different power traces, the firmware likely did not handle them the same way.

The device said “error.” The power trace may show that something else happened first.

From Command-Response Testing to Command-Response-Power Testing

PowerFuzzer extends firmware fuzzing by collecting a richer data tuple for each interaction:

	Command + Response + Power Trace

The command is the input sent to the target. The response is the visible answer returned over the interface. The power trace is a synchronized side-channel measurement that reveals how the target behaves while it processes the input and prepares its response.

This creates a more useful basis for classification. Commands can be grouped by implementation behaviour, not only by response text. Two different commands that return the same error may belong to different execution paths. Two different commands that produce similar traces may be handled by the same path, even if their syntax differs.

For black-box firmware validation, this is significant. In many supply chain settings, the tester does not have source code, schematics, firmware images, or internal design documentation. The purchaser may have only the finished device, the communication interface, and the supplier’s specification. PowerFuzzer provides another observable channel for assessing whether the target’s behaviour matches what the interface appears to report.

The practical question becomes more precise: when this command was sent, did the target behave like it genuinely rejected the command, or did it follow a different execution path?

Why a Command Like BOGUS Is Valuable

A known invalid command is not merely a negative test case. It is a reference measurement.

Suppose PowerFuzzer sends:

BOGUS

The command is not expected to exist. The device returns:

ERROR

PowerFuzzer records both the response and the power trace. That trace becomes a behavioural reference for the target’s ordinary rejection path.

Now suppose PowerFuzzer sends:

ATFOOBAR

The device again returns:

ERROR

A conventional test may classify both commands as invalid. PowerFuzzer can compare the two behaviours. If ATFOOBAR produces the same trace as BOGUS, the command was likely rejected through the same implementation path. If the trace is different, the command deserves attention. It may be a deprecated command, a diagnostic command that performs internal logic before rejection, an undocumented feature, a hidden interface, or a command inserted to support unauthorized access.

The visible response did not change but the behavioural evidence did.

Invalid commands can now make genuine rejection measurable, and once genuine rejection is measurable, deviations from it become visible.

Silent Commands and Hidden Firmware Behaviour

Palitronica frames PowerFuzzer around an important class of risk: silent commands in firmware. A silent, hidden or undocumented command does not need to announce itself. It may return a generic error, produce an ordinary-looking response, or appear to have no effect at all. The risk is that the command remains reachable and performs some useful action under specific conditions.

For a malicious actor, this is attractive because the command can hide inside normal interface behaviour. It may read memory, write configuration, change access controls, enable a diagnostic mode, alter internal state, or prepare the device for a later sequence. For an engineering team, the same pattern may also arise unintentionally through leftover developer functionality, incomplete feature removal, or undocumented supplier changes.

In both cases, conventional validation can miss the issue. A specification-based test will not send commands that are not in the specification. A functional test will confirm that the intended use case still works. A compliance test will focus on documented behaviour. Even standard fuzzing may understate the significance of a command if the response looks like rejection.

PowerFuzzer treats the response as only one part of the evidence. If a command appears to be rejected but produces a trace inconsistent with genuine rejection, it is no longer invisible.

Invalid Commands Can Reveal Firmware Drift

Invalid-command testing is also useful for detecting firmware drift across versions, lots, or suppliers.

Suppose a purchaser qualifies a device running firmware version 1. During qualification, the command ATDEBUG returns ERROR and produces a power trace consistent with the known invalid command BOGUS. The conclusion is reasonable: ATDEBUG is not implemented, or it is rejected through the ordinary rejection path.

Months later, a supplier ships a new batch. The same command still returns ERROR. From the protocol response alone, nothing appears to have changed.

But if the power trace is different, the firmware behaviour has changed. The command may now be parsed differently, routed through a new handler, checked against a new condition, or affected by an implementation change that was not communicated to the purchaser.

This does not automatically indicate malicious activity. Firmware can drift for legitimate reasons: bug fixes, component substitutions, manufacturing updates, library changes, toolchain changes, or supplier-side revisions. The issue is not that every change is hostile. The issue is that an undocumented change can affect qualification status, configuration management, cyber risk, interoperability, field reliability, and safety assumptions.

For the purchaser or integrator, the supplier controls the implementation, but the system-level risk remains with the organization that integrates the device. If a device behaves differently from the one previously qualified, that is evidence worth acting on.

Invalid commands help expose this problem because they provide stable behavioural anchors. If the rejection path changes, the firmware changed in a way that deserves review.

Why This Matters for Supply Chain Assurance

Modern electronics supply chains depend on commercial devices, modules, boards, radios, controllers, sensors, and power systems that purchasers often cannot fully inspect. This enables speed and scale, but it also creates an assurance gap. The integrator may not control the firmware, may not receive complete change notification, and may not know whether undocumented functionality exists inside the product.

Traditional incoming inspection can confirm labels, part numbers, visible damage, hardware revisions, documentation, and basic function. It may also confirm that expected commands still return expected responses. But it often cannot answer a more important question: does this device still behave like the one we qualified?

That question is central to zero-trust supply chain assurance. A trust-based model relies on supplier process, reputation, and documentation. An evidence-based model tests the product itself.

PowerFuzzer supports that model by making firmware behaviour observable through side-channel measurement. It performs black-box assessment of devices where the tester knows the communication interface but does not need source code or firmware access. It explores the target with known, generated, replayed, and mutated commands, then evaluates both the visible response and the physical behaviour associated with that response.

Invalid commands are central to this process because they define what genuine rejection looks like. Once “nothing happened” has a measurable signature, “something happened” becomes detectable.

Invalid Commands Are Valuable Evidence

The most common blind spot in firmware validation is stopping at the visible answer. A device that returns ERROR may have rejected the input cleanly, or it may have executed meaningful logic before returning that error. Without additional evidence, those cases collapse into the same test result.

Invalid-command testing separates them.

It helps identify undocumented functionality during supplier qualification. It can reveal firmware changes between batches. It can flag configuration drift before components are integrated into higher-value systems. It can support regression testing by confirming that rejection behaviour remains stable across firmware releases. It can also expose command-handling behaviour that deserves deeper security review.

Valid commands tell us whether documented functionality works. Invalid commands tell us whether undocumented behaviour exists, whether rejection is consistent, and whether firmware has changed beneath an unchanged interface.

That makes them more than just negative test cases; they are valuable evidence.