Can a computer network in a late-model vehicle be controlled by the introduction of malware into the system? At an undisclosed location here in Washington, D.C., Jack McGinnis and his friend and top-notch technician, Allington Kinsley, investigated a case of a contaminated network on an SUV. We flew out of Cleveland-Hopkins Airport, a car was waiting for us in D.C. and transported us to an FBI garage. We just got in the city and had to go to work for this Easter weekend. Give us a break!

     Becket Blackwater (supervisor, Special Crash Investigations), stared at the oscilloscope pattern as Jack approached, with Vera and Kerry (two wet-behind-the-ears investigators) trailing behind. Al was using his personal oscilloscope--one with a segmented-memory acquisition feature. My friend chose it because it was ideal for looking at packetized serial data; those signals were characterized by long idle times between the low duty cycle pulses and bursts of signal activity.

     "Cool oscilloscope," Vera said, "What's the sample rate?"

     "This particular scope has a 5 gigasamples-per-second rate, so the maximum amount of continuous time that this scope can capture while sampling at its maximum rate is 800 microseconds," I explained to Vera, "Because the maximum memory depth is 4 M points."

     I looked at my friend. "Where are you with this, Al?"

    "I did a segmented memory acquisition and we are ready to view all of the captured waveforms. Do you want them overlaid in an infinite persistence display or individual waveform segments?"

     "Let's go individual for now, Al." (Are you with me on this, reader?)

Al adjusted the scope pattern display. "I set up to trigger on every start-of-frame condition and obviously with the segmented memory acquisition turned on," Al explained to the young investigators. I can tell you, we scrolled through the individual frames, searching for errors or anomalies.

Suddenly, I caught something. It was barely perceptible, but it was there.

"Did you see that, Al?" I asked. After about 2.385 seconds of total acquisition time, I spotted an anomaly on a single frame of data.

"Yeah," Al replied--you're talking about data frame 07F, correct?"

"Yep," I told my friend. We studied the frame for a minute before deciding to change the scope trigger condition to trigger on 07F. I figured we would trigger on error frames. (I hope the reader is with me on this.)

"Yeah, Jack, but since the error frames are intermittent, we need to change the number of segments to capture," Al suggested. "Let's change it to just 100 segments."

So, Al adjusted the scope and we spotted the patterns again as the oscilloscope captured 100 consecutive CAN error frames over a 12.5 second time span. "Look at that," I said to Al.

"What do you guys see?" The inexperienced Vera said. (She lacks experience as a federal investigator--sorry, Vera.)

I pointed to the protocol list on the display. "It looks like the error frames appear to happen at identifiers )7F, )BD and 000."

Al agreed with me and zoomed in on the pattern. "Look at ID 07F now, Jack," Al said.

Al squinted at the pattern. "Do you mean that narrow glitch near the end of the frame?" I asked.

"That's the one, Jack--it's causing error frames to sometimes happen during frame 07F."

(Did I mention the feds were recording all this?)

"It's in the payload of a data frame--did you catch it, Al?" I asked.

"Yeah--that's our anomaly." I reminded Al that the data field was the payload of the data frame. It was the only field in the data frame that did not have a fixed length.

"Look at that cyclical redundancy check field, Jack."

I spotted another anomaly. Now, I knew that the CRC field was 15 bits in duration and the receiving Electronic Control Unit used the value in the CRC field to determine if the data bit sequence in the frame was corrupt during its delivery.

"The other ECU's aren't sending out Error Frames because they're not detecting any of the errors contained in the frames we're seeing," I explained.

We replayed more of the collected CAN data packets. Then I made the discovery. "There it is! The glitches are reducing themselves every time the frames recycle until--"

"Until they disappear," Al said. "This code is designed to obliterate itself and leave no trace."

The feds here couldn't believe a couple of tired old mechanics discovered what their computer experts couldn't. Score one for us mechanics! But the feds wanted to know how the malware could have gotten introduced into this vehicle. As luck would have it, when I powered up the radio with Keep-Alive, a CD was automatically ejected. I grabbed the CD by the edges with my gloved hand. The CD had no label and Becket Blackwater (the supervisor) moved closer.

"Is that a homemade CD?" Beckett asked.

"This could be how the hackers infiltrated the network," I told him.

"Are you telling me that the CD could have malware on it?" Becket asked.

I nodded. "Picture this, Mr. Blackwater: a high-ranking politician here in D.C. is listening to a CD that one of his constituents gave him. Sounds harmless enough, right?

"I'm listening," Beckett said.

"Suddenly, the vehicle is affected by unintended acceleration and then hard, unexpected braking, causing a pileup on the interstate (yes, this actually happened--but not in D.C.)."

I continued. "You see, Mr. Blackater--with the addition of an extra code to a digital music file, the hacker turned a harmless music CD into a Trojan Horse that altered the firmware of the entertainment system. Because the radio is a gateway module--bridging networks together--that means the attack could jump to other data buses that make up the SUV's network."

(Don't know if you know this, but pits in a CD's aluminum and polycarbonate sandwich store binary data which is read by a laser).

"Who could make such an attack?" Vera asked. (I must say, Vera is a bright, 26-year-old with a degree in engineering cyber security--but she's not an experienced mechanic--sorry, Vera).

To my readers: Al and I discovered this malware gets deposited into the system and uses a payload code that it then flashes to the firmware, replacing the existing firmware with a malicious one.

It is almost 11:30, Al and I are tired from flying to D.C., going to work immediately, so I am signing off for the night. It is the Easter weekend and we have to be back at it tomorrow.

Jack McGinnis and Al Kinsley, signing off.