Tracing Software Through Power Consumption

The aim of this project is to provide a non-intrusive tool to determine the program trace of a deployed embedded device; in particular, a device that no longer contains hardware or software instrumentation for the purpose of tracing or debugging. Potential applications for this tool include debugging — a particularly hard task when faulty behaviour is observed on the device at production or deployment stage; device tampering/malware detection — in a sense, an Intrusion Detection System (IDS) for embedded devices; Intellectual Property (IP) protection or copyright enforcement, and others.

The fundamental principle on which the technique is based is that of exploiting the relationship between operations being executed by the processor (MCU or CPU) and the power consumption as a function of time. To overcome the difficulties in determining operations as a function of instantaneous power consumption, we make use of statistical pattern recognition techniques, along with digital signal processing techniques to determine sequences of executed statements from observed power traces (a “plot” or a captured segment of power consumption as a function of time). The idea being, given a segment of a power trace, the pattern recognition system determines the most likely fragment of the source code that would have produced the given power trace.

To this end, the system requires a profiling or training phase, where the source code is processed and split into fragments. These fragments are executed and their corresponding power traces are captured and stored in a database of training samples. During operation, a given power trace segment is classified as one of the fragments of source code based on similarity / proximity to samples in the training database.

Operation also involves the tasks of splitting the (single and continuous) power trace into segments that correspond with the fragments of source code being detected, and synchronizing or aligning these fragments with the actual execution. That is, the system has to first determine the times at which the relevant segments start as well as where in the source code the current execution correspond (since operation of the system starts asynchronously after the device has been operating), and then maintain synchronization with the actual execution.