When a clock glitch changes a neural network's answer
A camera can use a neural network to recognise a face or detect an object. On an embedded device, that prediction depends on the processor running the model correctly. An attacker with access to the hardware could try to disturb that execution and change the answer. That matters when a system acts on the prediction, for example to grant access.
My BSc thesis investigated clock glitches: brief disturbances in the clock signal that controls the processor’s timing. I wanted to see how they affected a neural network running on real hardware, and whether skipping instructions in a debugger could reproduce those effects.
Hardware experiments need specialised equipment and careful timing. If a software simulation could reproduce the same faults, it could make testing vulnerabilities cheaper and easier to repeat. The comparison was a way to check whether the simple instruction-skipping model actually represented the hardware behaviour.
I adapted an existing C implementation of a small neural network trained to recognise handwritten digits from MNIST, and ran it on the ARM microcontroller of a ChipWhisperer-Lite. Its capture board generates the clock glitches; the target board runs the model.

I added triggers around the hidden-layer calculations and swept the glitch timing and width. Some glitches changed the output scores; a few changed the predicted digit. In one test, an image of a zero was classified as a five.
MNIST input

Inside the hidden-layer loop
trigger_high();
h[j] += w[j * X + i]
* input[i];The harder part was explaining what happened inside the processor. I used GDB to step through the assembly instructions and read the processor’s cycle counter. Starting at the trigger, I tried to match the delay of a successful glitch to the instruction running at that moment. I then advanced past selected instructions and compared the resulting values with the hardware measurements. The assumption was that a clock glitch could be modelled as skipping an instruction.
That timing was difficult to pin down. One line of C expands into many instructions, including library routines for floating-point arithmetic. Some instructions take multiple clock cycles, so a glitch can land partway through one. The processor also overlaps stages of instruction execution in a pipeline, which complicates the timing further. ChipWhisperer adds a delay between receiving the trigger and issuing the glitch. Skipping instructions in GDB did not reproduce the measured results, and I could not verify exactly which instructions the glitches affected.
The project produced a working setup for injecting faults and inspecting their effects on the network. The mismatch suggests that treating a clock glitch as a clean instruction skip may miss what the processor actually does.