TATER: Tamper Analysis via Transient Electromagnetic Response

From Mindworks
Jump to: navigation, search

TATER is a tamper analysis system that monitors deterministic computer programs and detects unauthorized modifications. The TATER system functions when placed in close proximity to the target proessor. It works by capturing and comparing electromagnetic emanations from a target processor by using a correlation algorithm. The value of this project is that it can verify code integrity without requiring modification to the target software or hardware.

Sponsors Client declined to be named
Duration Fall 2017 - Spring 2018
  • Dr. Feng Li
Faculty Advisor
  • Dr. Feng Li
Team Name TATER Tots
Team Members
  • Matt Waltz
  • Roy Cochran
  • Matt Covalt
  • Lydia Engerbretson
  • Hannah Pearson

Problem Statement[edit]


In some situations, it may be impractical to physically modify a system in order to monitor it. Whether due to financial matters or system dependencies, this may worsen the severity of existing vulnerabilities since successful exploitation of these vulnerabilities may not be identified for days, or even years. The goal of TATER is to verify code integrity without requiring modification to the target system. It works in close proximity to the target processor by monitoring electromagnetic signals emanating from the processor and correlating them with an established baseline from code that is "known" to be good.


Our product should not require modification of the target system. It should be sensitive enough to detect relatively small changes in the boot code but flexible enough to allow multiple configurations. It should be possible to update the monitoring system to continue correctly characterizing the boot code if it is updated. Analysis should take no longer than a couple of minutes.


Alternatives and Decisions[edit]

We considered using an FPGA to process signals, but ultimately decided that the best choice for research and development purposes would be to use Linux on a laptop. This is a diagram of our setup design:


Our strategy is to design an antenna to pick up electromagnetic signals emanating from a processor and analyze peaks in the frequency compared with an established baseline to identify modifications in the boot code. Various statistical analysis techniques may be of use in pursuing this goal.

Antenna Design[edit]

Recent developments have shown that our antenna design will be centered around the important data of our signal rather than all of it, with a bandwidth ranging from 1-250MHz. This range of frequencies is difficult to obtain in a cost effective and minimum volume mindset, which translates to what will likely be a homemade antenna.

Previous Antenna Design Considerations[edit]

These antennas were considered along the course of our project, and are being left up to demonstrate the learning process.

Ferrite Rod[edit]


  • High Radiated Resistance
  • Increased Efficiency


  • Not useful at high frequencies
  • Bulky and Heavy
Ferrite Rod Antenna
Pulse Larsen Outdoor Multi Band Antenna[edit]


  • High Isolation
  • 6GB Bandwidth


  • Difficult to implement
  • Expensive
Pulse Larsen Outdoor Multi Band Antenna

Hardware Design[edit]

The hardware setup is in the process of being finalized. When it is complete, the antenna will sit inside a fitted shielding box and send signals through an ADC to a Linux computer.

Electromagnetic Signal Captures[edit]

To the right are figures showing what the data captures look like. Above shows a full sequence, and below shows a very short segment containing one instruction peak, which consists of several smaller peaks and valleys.

In the upper left is a complete capture, compared to a similar capture in the upper right, which contains a segment of modified code that occurs approximately between indices 430,000 and 490,000. Visibly striking memory addressing instructions were used to emphasize the difference and make it visibly noticeable at this scale.

Below is a diagram of two very similar single instruction peaks. Visual inspection can identify the similarity between the peaks, just as correlation does for every peak in the sequence.

Example of Capture Data

Algorithm Design[edit]

We are planning to use cross correlation to align our waveform sequences. We then normalize the data using the highest and lowest values and correlate the capture sequence with an established baseline. This allows us to compare the locations of peaks over time and produce a percentage representing the similarity between the sequences.

At this point, we have created a proof-of-concept program that correctly recognizes when code has been modified by inserting or deleting instructions. Repeated captures over the same sequence consistently produce a correlation of >99%. We are only able to detect single assembly-level instruction changes if they are dissimilar - say an ADD and a MOV, for instance. Replacement of similar instructions with each other, even to the level of an ADD and a MUL, are not detectable. The difference between them is indistinguishable from the normal <1% variation between captures caused by external noise and imprecise equipment.

Data Pre-processing[edit]

At this point, the only pre-processing that is done is aligning the signals to start at the first peak. This was previously done by filtering out all values below a certain level until the first high value occured, recognized as significantly about the average of the first several thousand signals. We are transitioning to using cross correlation to align the sequences, since the sampling rate has been decreased and it is no longer possible to match the locations of the first peaks as closely as necessary.

Cross Correlation for Alignment[edit]
In signal processing, cross-correlation is a measure of similarity of two series as a function of the displacement of one relative to the other.

For cross correlation, the sequences we are correlating are a baseline which we have established using the average of multiple captures from known good boot code, denoted f, and the signals that are being captured from the microprocessor, denoted g. See following equation:


Boot Code Verification Process[edit]
To the right is an diagram of the boot code verification process for our algorithm.
The algorithm is able to detect where a modification occurs by dividing the boot code into segments under a sliding window. By comparing short overlapping sequences of code, the algorithm can precisely identify the location of change if the sequences do not correlate well.
Complications and Challenges[edit]
Due to the nature of configuration changes, they present a unique challenge. Configurations are often associated with peripherals, which take a variable time to load. In addition, instructions produce different electromagnetic emissions when executed at different memory locations and at different times, so the same code will produce different signal sequences depending on where and when it is executed. For these reasons, it is impossible to allow a large number of configurations because every possible sequence would have to be stored and compared against, which would require an intractable amount of memory and analysis time. In addition, this doesn't solve the problem with peripherals.

As agreed upon with the client, configurations need not be supported. Research results and suggestions for future work describing possible approaches to solving this problem will be included in the final deliverable for this project.


Implementation and Testing[edit]

A probe and oscilloscope are used to capture electromagnetic signals emanating from the target processor. Captures from the same sequence of code produce a correlation of >99%, which is excellent. If instructions are added or removed, then this correlation falls significantly and the algorithm can detect these changes. Currently, we are able to detect single assembly-level instruction changes only if the instructions being modified are significantly different - such as replacing and ADD with a MOV. Changing an ADD to a much more similar SUB, on the other hand, is not significant enough for our current algorithm to register the difference. Complications such as background noise picked up along with the legitimate code emissions account for the <1% variation between captures on the same sequence of code, which makes it much harder to identify tiny changes such as replacing an ADD with a SUB as mentioned. Fortunately, most modifications would require multiple instruction changes in order to accomplish the intended purpose.

Testing and Development Setup[edit]

Components involved: (see images below and right)

  • Target board: 1MHz ATmega328p
  • AVR Programmer for board
  • Tekbox H20 EMC Probe (Magnetic Field)
  • Tekbox 20dB Amplifier or 12V - 30dB Amplifier
  • Agilent MSO7034B 350MHz 2GSa/s Oscilloscope
  • Metal box provides shielding from outside EM signals
Testing and Development Setup
Measurement Setup

Test Results[edit]

To the left is an example of signals captured by an oscilloscope. To the right is a graph showing the difference between specific instructions and a NOP instruction.

Oscilloscope Capture
Comparison Between Instructions and NOP


Name Bio Photo
Matt Waltz Matt Waltz is a senior pursuing a Bachelor’s of Science in Computer Engineering from the University of Idaho. He enjoys working with low-level architectures with emphasis on compiler infrastructure, along with secure system design and protections. Wikibio-waltz.JPG
Roy Cochran Roy Cochran is a senior pursuing a Bachelor's of Science in Electrical Engineering from the University of Idaho. He enjoys learning and applying antenna design to real life applications, and implementing additions to printed circuit boards. Cochran.JPG
Matthew Covalt Matthew Covalt is a senior pursuing a Bachelor’s of Science in Computer Engineering from the University of Idaho. He has experience working with embedded systems. He also has recent experience developing and testing bootloader firmware for Solid State Drive devices. Covalt.JPG
Lydia Engerbretson Lydia Engerbretson is a senior at the University of Idaho, pursuing a Bachelor's of Science in Computer Science. She is currently a Software Engineer Intern at Schweitzer Engineering Labs, where she writes software for Protection System relays. Lydia engerbretson.jpg
Hannah Pearson Hannah Pearson is a senior pursuing a Bachelor's of Science in Computer Science and in Mathematics. She is interested in cyber security and cryptography and likes working on CTFs in her free time. Pearson.JPG

Document Archive[edit]

Project Schedule[edit]

Project scedule.JPG

Meeting Minutes[edit]

File:Meeting Minutes 20170906.pdf

File:Meeting Minutes 20170908.pdf

File:Meeting Minutes 20170913.pdf

File:Meeting Minutes 20170914.pdf

File:Meeting Minutes 20170920.pdf

File:Meeting Minutes 20170927.pdf

File:Meeting Minutes 20171004.pdf

File:Meeting Minutes 20171011.pdf

File:Meeting Minutes 20171018.pdf

File:Meeting Minutes 20171025.pdf

File:Meeting Minutes 20171101.pdf

File:Meeting Minutes 20171108.pdf

File:Meeting Minutes 20171115.pdf

File:Meeting Minutes 20171129.pdf

File:Meeting Minutes 20171206.pdf

File:Meeting Minutes 20180110.pdf

File:Meeting Minutes 20180117.pdf

File:Meeting Minutes 20180124.pdf

File:Meeting Minutes 20180130.pdf

File:Meeting Minutes 20180214.pdf

File:Meeting Minutes 20180221.pdf

File:Meeting Minutes 20180302.pdf

Presentations and Monthly Status Reports[edit]






Other Project Documents[edit]