Hi, welcome to our talk, Powerline Truck Hacking, Two Tools for PLC for Trucks.
We're going to talk to you today for about an hour, you know, who are we, what is PLC,
how do you interface with PLC, what are these two tools, PLC for Trucks, GR2497,
how can you adapt what you got onto the PLC connection. We discovered an issue,
we're going to discuss that issue and the impacts, and then we'll show you some future work.
So first up about us, I'm Ben Gardner, I'm a researcher with the National Motor Freight
Traffic Association, previously done embedded systems development, reverse engineering,
I've been an instructor at the Cybertruck Challenge and plan to, when it ever comes back,
I also volunteer at DEF CON and SAE. Hi, I'm Chris Poore, an electrical engineer who has
been hacking things and helping people get away with it for more years than I can count on these
blood-stained hands. I work at Assured Information Security, headquartered in Rome,
New York, with locations all over the U.S. AIS strives to be a driving force for technology and
national security and has the combined professional experience that I believe is rivaled only by the
space program. Contact AIS today. Next slide, please. It's not just a two-person effort,
we're part of a much larger team, a great team that we've been privileged to be a part of,
comprised of Dan Salone, Christopher Poore, who you now know, Eric Thayer, all of AIS,
and myself from the NMFTA. Also, this research would not have been possible without the support
of the Motor Freight Carrier members of the NMFTA, who sponsored us with access to their
facilities and to their equipment, and thank you for that. First up, what is power line
communications? Generally speaking, any time you're putting data onto lines that are intended
for power, you're doing power line communications. You might know some technologies that fall into
this class, such as Green PHY and Home Plug. There's an entire interoperable family of
technologies in IEEE 1901. The technology is found in automotive, most commonly under SAEJ
1772, which is for plug-in electric vehicle charging, and there was some really interesting
work by Baker and Martinovic at USENIX 19, where they showed that they could remotely read traffic
between the plug-in electric connection of a vehicle and the charger. But today, we're not
talking about plug-in electric vehicles, we're talking about trucks. So let's rewind the clock
a little bit, maybe a couple decades, and look at what trucks looked like around 1997. There were
anti-lock braking, ABS systems, on trailers and on tractors, and these ABS systems are quite
important to prevent rolls and reduce braking distance. It's really important
for safety. So at the time, there was only a warning on the side of the trailer that showed
you if the ABS was malfunctioning. There are regulators and fleet safety managers that really
wanted to have some kind of a dash display that would show the driver if there was a problem with
the trailer ABS. And this, of course, would help make sure that ABS is functioning and everyone
would stay safe. Now let's look at how these trailers and tractors were connected. So back
then, and actually as it is today, trailers and tractors are connected with a J560 connector.
Here you can see that green pigtailed cable plugging into a bulkhead jack there. And that's
a seven-way connector. You can also see a red and a blue cable behind the bulkhead here. Those are
actually pressurized air, whereas the green cable here, this is electrical. So back then,
they had this tractor-trailer connector. You can see a breakout here of the J560. It's got
tail lights, right turn, left turn, brake lights, a ground connector, and then this power for ABS
and auxiliary power. So it's a fully populated connector. There's no room for anything else, but
still, regulators and safety managers really wanted to have a way to show the driver when
something was failing. Now an obvious option is to add another connector, but unfortunately,
you know, for fleets, the lifetime of trailer equipment is very long and the cost of retrofitting
is very high. So the industry took it upon themselves to design a technology that would
let them send this ABS fault data up into the tractor without adding a new connector.
And at the same time, there was a lot of other technologies that people wanted to get data from
the trailer into the tractor, and there was things like axle weight, door latch, yaw sensors, and
things like that. So it was hoped that this technology could carry all sorts of information
up from the trailer to the tractor, not just the ABS fault info. Around June 1998, ATATMC actually
approved PLC for trucks. This is the American Trucking Association's Technical Maintenance
Council. They are responsible for making recommended practices in the commercial vehicle
space. And eventually, SAE published J2497 in 2002. And what they did was add high-frequency
signals onto these power lines that run the length of the truck. So they would couple them
onto their either transformer or capacitor, just AC-coupled, and send these high-frequency
signals with enough of a voltage that they would propagate. Now, there was an issue with
PLC for trucks that was patent. It was actually patent incumbent. And at the time that they
started the work on this, they didn't know. Eventually, it became known, and SAE actually,
at one point, just canceled the working group to create J2497. And eventually, it was resolved.
The technology was patented for a long time, and there were royalties that had to be paid, but the
standard did go forward. Now, if you go to SAA meetings or ATATMC meetings like I do,
you've probably seen these patent disclosure and IP statements at the beginning of the meetings.
I've been told that for ATATMC, those passages actually exist because of what happened with
PLC for trucks, whereas with SAE, those statements actually predated the PLC for trucks issue.
So it took the industry a while to get it done. It was quite complicated. There was a lot of tests
that happened over the winter and otherwise. And as I mentioned, there was other technologies
that wanted to get like axle weighing and door sensors and things like that up from the trailer
into the tractor. So they had interoperability tests. And it ended up being... eventually,
it was deployed, but it was quite complicated to get it to that point. So the news media
has been seen to call this technology expensive or complicated. There's a funny quote right here
where someone's saying the most expensive light bulb in history. So it is funny to look at the
technology that way. But it's also important to recognize that the calculus that the fleets were
looking at was whether they would have to retrofit all their trailers, which typically have, you know,
30 year service lifetimes, just to get another light up into the cab. So creating this technology,
even though it seems like it was an expensive light bulb, still, from their point of view,
what they wanted was cheaper. And that's going to be true today as it was back then. The trailers
last for a very long time. The connectors are still the J560 connector. And trying to change
any of that might prove to be more expensive than anyone would want to spend. So now you know a lot
of the history about J2497 and why it came about and why are we sending these high frequency signals
on power lines. Let's talk more about what it is, how it's put together. You can think of J2497
like an alternate physical layer for J1708. And we're not going to go into J17 a lot because
there's another talk that will give you lots of details on it. Suffice it to say that it's a
heavy vehicle network that predates J1939. J2497 has its own arbitration scheme that it
employs around J1708. The PLC for trucks 2497 is always 9600 bauds. And the way it takes these
1708 signals is it'll actually encode them into spread spectrum chirps. So another way to think
about 2497 is by an analogy. You can see a couple analogies that I'm making here. You know J1939
is a lot like J1587. And J1939 can sit on top of high speed or low speed canned buses, twisted or
unshielded. So similarly can J1587 sit on top of either J2497 or just J1708. And you'll probably
have diagnostics or some other applications on top of those. Which if you're not an automotive
person you can think of it by an analogy to DNS which is built on top of UDP. And UDP IP can run
either like ethernet or 802.11 infrared for example. So let's talk a little bit more about
these spread spectrum chirps. The specification of J2497 by SAE actually includes a definition
of the chirp. And they have to sweep from 200 to 400 kilohertz, then from 400 to 100 kilohertz,
and then from 100 to 2 or 3 kilohertz. You can see a picture here of a rendering of a couple
possible chirps. Different possibilities result by how you treat these discontinuities here.
The chirps themselves are about 100 microseconds total. They start and end at value zero so that
they can be concatenated. And when they're transmitted they should be transmitted in
amplitude between 2.5 to 7 volts peak-to-peak according to the spec. Now in practice
the transmitters on trailer equipment tend to send them even higher than 7 volts peak-to-peak
just to make sure that they'll make it from one end of the tractor trailer to the other.
The chirps are put together into frame encodings that will let them actually send
J1708 frames. And the way the frames are encoded is broken up into a preamble and a body.
The purpose of the preamble is there to realize that alternate arbitration method so that if two
PLC devices are trying to talk at the same time there's a way to determine who has the highest
priority and which one should back off. It's very similar to CAN. It involves that very first
byte being sent and the lower byte is the higher priority. So here you can see two renderings of
frames. The first being OA00, the second being OBFF. The OA00 frame and the OBFF frame are the
ADS fault information that we talked about, the impetus for J2497. So in the preamble you can see
that the messages, the actual chirps have delays in between them. And this is because the chirps
are 100 microseconds but the time for the symbols is 104 microseconds, these little gaps. In the
preamble the presence of the chirp indicates, you know, the logic value. So logic 0 means chirp
present, logic 1 is chirp absent. But then when you get into the body it's actually 100
microseconds with no gaps and the encoding is actually determined by phase. So this is phase
shift keying in the body. The phase of logic 0 is arbitrary per device and it's actually given by
the phase that's transmitted here in the amplitude shift keying section. There's a checksum
at the end and then there's all these sync bits you can see in orange and in green.
And some of these sizes are variable so there could be one to two initial symbols and there
could be zero to four gap symbols. So why is it like that? Well J2497 was designed for J1708.
This whole PLC for trucks scheme was actually accomplished by a particular piece of
silicon, the Intelon SSC P485. And this particular chip was designed to take J1708 frames and wrap
them around with some extra information and re-encode them into these spread spectrum chirps.
So the Intelon P485 actually adds, you know, these sync bits and adds all the preamble highlighted
here in orange. It will then send, you know, the actual encoded information in chirps as the body
which matches exactly what you would see on the J1708 line. And then it adds these terminators with
the gaps and the sync bits. So the checksum is actually part of J1708 and part of J2497.
And you can see there's a duplication of MIDs. You can think of MIDs like arbitration IDs
in CAN. It's that first byte. It determines arbitration on the bus and the data is duplicated
twice. It turns out that this information here in the preamble is used for arbitration of the PLC bus
only. And what gets sent on J1708 is this byte that's put right here, which means that you can
send things where those two don't equal each other. And you can override priority. So you
could send a very low priority MID with an all zero PLC MID and it would margin on top of anyone
else that was talking on PLC. So a little bit about J1587. This is that next layer above. You
can think of it akin to J1939. If you look at the J1587 spec, there's a lot of really interesting
highlights. They say that you shouldn't send more than 21 bytes at a time unless the vehicle is
stationary. I wonder what happens if you don't. There's a factory test MID that should never be
sent by any vehicle system. There are bridging and forwarding schemes defined in the spec. There's a
dynamic address claim. There are cold and warm reset commands and lots of support for interesting
kind of peripherals on commercial vehicles like toll systems and display signage and climate
control. Now for some more details on how to decode J1587 automatically, please see our team's
presentation, which should be up today, or look at the pretty J1587 repository.
Even though J1587 defines a lot of interesting things that could be in there,
all we've seen in our testing for the most part is the ABS fault lamp on and off messages and
manufactured diagnostic messages. There was a report by the FMCSA that suggested that there
should also be axleway yaw sensor and door latch sensor traffic on the PLC bus, but we haven't run
into it yet. So how do you connect to PLC? There are some great options out there. The DG Technologies
PLC TESCON is very rugged and reliable. I love mine. There is also a NEXIC PLC adapter, which
has the advantage of being able to go in line on a cable, so you can you can test it in place.
The problem with these sort of classic diagnostic adapters is that they aren't cheap. You will need
them for running manufactured diagnostic tools though. And also the Intelon P485, I'm told,
is becoming harder to source, which is not going to help with the cost of these tools.
Finally, the limitation of these tools is that you can't do anything strange to PLC with these
tools, because they just have an Intelon P485 chip in them, and so you can't make arbitrary
PLC waveforms. For example, you can't do different PLC MID from a J1708 MID on the bus.
So how do you interface with J1708 so that you can interface with PLC? The first one up is another
one of those RP-1210 adapters, such as the Digitech DPA4, DPA5, or an EXIC USB link.
And these things are necessary for the manufacturer diagnostics. An option that I really like,
that's really cool, that was presented here at DEF CON 24 is the TruckDuck, which is a beaglebone
cape by 6V and Haystack. There's been some revisions to this board since the DEF CON 24
presentation. There's the 1.5 EET version and the Mega version. These beaglebone capes enable
communication with both J1939, or any Canon network actually, and J1708 networks through
the PiHV networks module that Haystack authored. And we are going to talk about some ways to use
these to write PLC. So our PLC writing tool, what we wanted was something to be low cost.
We wanted it to be open. We wanted it to be capable of doing weird things. We weren't so
concerned about arbitration. The J1708 stack that Haystack put together for the TruckDuck
originally didn't have any arbitration, just had frame detect, and it works fairly well on systems
that aren't highly loaded. And we didn't want to worry about getting read in right now, and the
reason for that you'll see will be clear later. So our approach that we elected, mostly because
we're biased and we like the TruckDuck, is let's make some small mods to the TruckDuck and push
them upstream and try to stick with very small BOM changes, and hopefully 6V can integrate those
into the next Mega Mega EET version of the TruckDuck. So, Bitbanging PWM on the PRU. Bitbanging
is the process of toggling a GPIO in order to create whatever protocol you're after. GPIOs are
general purpose input output pins, of which there are many on the BeagleBOM, and the PRU is a
programmable real-time unit on the BeagleBOM. It runs jitter-free, like deterministic code with no
interrupts stopping execution at 200 megahertz, which is plenty for the 400 kilohertz-ish
signal of PLC. And also the PRU was used originally on the TruckDuck for the J1708 stack itself,
so there's already a precedent there for using the PRU in this system.
It turns out that the TruckDuck J1708 channel 2 has pretty much been broken since release,
which is actually good for us because it lets us reuse, repurpose, one of the PRU cores for
the PLC application instead. And in trying to find pins, we needed to find one that we knew
we could bitbang from the PRU, which is a certain class of pins. But we also wanted to eventually
maybe get rid of the PRU, if possible, and use the integrated PWM unit in the BeagleBOM, although
that hasn't been done yet. So trying to find the pin that would work was, you know, one of
these fun processes. I found it best to just do it with markers. We wanted to make sure that it
could be accessed from the PRU. It could migrate to PWM. We wanted to make sure it didn't conflict
with any other TruckDuck pins. So for synthesizing PLC, we settled eventually on P928. We had a
backup. And then we also planned for doing frame detect and PLC read via an ADC, but we haven't
implement that. That's just kind of allocated for later. So in creating PLC signals, there's two
main parts. You have to synthesize this PLC with PWM, and then you have to couple this signal
that you've created onto the PLC network. So there's these two clouds that we're going to reveal.
I don't often do this, but I thought I would this time. I would try the dumbest thing first,
and my friends will tell you that I'm not very good at doing that, but I did it this time. The
first thing we tried was the dumbest PWM possible. You just turn it on when the signal that you're
trying to realize is above zero, and turn it off when the signal you're trying to realize is below
zero. So you can see that picture here. The orange waveform is the dumb PWM, and the blue waveform
is the true CHIRP. And it turns out that actually worked. So we said yay and moved on. The next part
was coupling. And you can see here in the DGTech PLC test con, the coupling network they created
is just gorgeous. And compared to what we were using, it is amazing because we found out that
100 nanofarad capacitor was enough, and that was our filtering as well. So the dumbest filtering
and the dumbest PWM got us what we needed, and we moved on. The results were pretty good,
actually. We did run into one issue with undocumented cycle counts for some of the
instructions that we we had to use in assembly, but the results were fine. You can see down here
the orange signal is a recording on an oscilloscope of the PLC signal that we synthesized
after filtering on a receiver. Same with the purple. This is just a larger zoomed out trace.
So this is post-filtering of the signal that we realized. The signal that we realized is much more
like these square waves up here in the tuning edge delays diagram. And this is just a representation
of how we had to tune some of the assembly instructions to make sure that the signal would
line up, you know, all the way into the realization like bit 54 of the PLC chirp train that we had to
create. So it worked pretty well. The code. You can get this tool. It's MIT licensed. It's available
on GitHub as of today. What it does is it adds a new J1708 server. That's the way that the 1708
was set up on the truck ducks is they receive and send UDP frames and will send or receive those
onto J1708. What we did was create a whole new one that's completely compatible, but what it
does is send PLC signals instead. We also created some command line utilities. The network, the
Pi HV networks that Haystack created has a really nice programming interface for Python, but I just
like to have really simple command line tools like dump and send. So we drafted those and they're
compatible with the existing stack as well. And so to get your truck ducks to connect to PLC,
you actually do need to do some PCB changes to your truck duck for now until 6V rolls us into
the next revision. And this led to probably one of my favorite kind of bodge jobs because I love
to do rework of PCBs and I also really like it when things have to be MacGyvered. When we were
connecting this up to PLC, we discovered that it would work when there was a really long length of
cable in between the power supply of the truck duck and the point where we were coupling to the
network. And if we didn't have that long piece of cable, the truck duck power supply just seemed to
attenuate the PLC signals to almost nothing, which led me to this great bodge job right here where I
wrapped 40 inches of wire and soldered that down to the board in between the input to the power
supply and the connector. And that actually solved the problem, which is fun. Okay, so next up we're
going to show you how you can use some adapters to connect your truck duck up to the power lines.
There's a lot of different options. The first is this J560 to DB15 in Deutsch 2-pin. So these
DB15 connectors, you can find them in a lot of different diagnostics adapters. The DPA4 and the
truck duck both have them. This is a 560 connector here, which is useful to be plugged into the back
of your tractor. You can also plug into the back of your trailer if you have an adapter to connect
to the batteries up here on the Deutsch 2-pin, and the whole set is in the DG Tech PLC Tescon.
Next up is these battery clip, the DB15 adapters, and these ones can be found in the Nexic adapter
sets on the internet. There's also these Y adapters for J560, where they give you a Deutsch
9-pin connector in line with two J560 connectors, so these can be used in line with a tractor and
trailer that are connected. You've got to watch out that some of these actually do contain an
Intelon P485, and what they're doing is converting PLC to J1708 and routing that to the J1708 pins
instead of PLC onto the power pins. Another one that's useful is one of these inline
jack and plug, which is very similar to the previous one. None of these have the Intelon P485
inside them. You can also build your own umbilical, so these J560 plugs, you can take them apart by
removing the set screw, and you can wire any kind of a pigtail you like. I like to use these Deutsch
2 pins because they work with the DG Tech sets, and then you can close it all back up and you can
have a connector that can be used with a tractor and trailer connected. So we also created a PLC
reading tool, and Chris Poore is going to tell you some more details about that. Chris? Thanks, Ben.
One of our goals was to develop a low-cost tool for reading J2497 messages with SDRs and
open source software. We wanted a solution to let just about anybody tap into a line and see
messages all for little cost. Next slide, please. Again, the J2497 signals primarily consist of a
series of 100 microsecond chirps that start at 203 kilohertz, ramp up to 400 kilohertz, quickly
drop down to 100 kilohertz, and back to 203 kilohertz. The 100 to 400 kilohertz frequency
range is lower than most SDRs can handle. For example, the starting frequency of the RTL2832U
dongles vary depending on the model, but they can range from 500 kilohertz to around 50 megahertz.
Next slide, please. To get around this problem, we used up converters. The Hammett up up converter
will take our signal and mix it with an intermediate frequency of 125 megahertz.
I believe the SPIverter uses 120 megahertz. Once it's near 125 megahertz, we can receive it with
radios and begin to condition the signal in software. We improved the quality of the signal
if we didn't tune our radio directly on 125 megahertz, but instead at 126. This allowed
us to use a bandpass filter to get rid of a lot of the DC noise associated with the Hammett up.
Next slide, please.
We achieved most of our success with an RTL and a Hammett up, but there are solutions out there
that could be promising that don't use up converters. We tried the Lime SDR, which starts
at 100 kilohertz, but the gain and performance down at those frequencies was too low for us.
You can find schematics online for modifying RTL SDRs to get a lower starting frequency.
They also make some that have a direct receive mode that can tune down to 500 kilohertz,
but they say the performance is reduced when operating them there.
The AirSpy HF Plus is supposed to start at 9 kilohertz,
but it might not have the bandwidth to support the J2497 chirps.
You might have some luck with oscilloscopes, but then the price starts to go up.
The ADOM2000 is a cheaper option you might want to consider.
Next slide, please.
Back to our setup. When tapped to the line, we used a coupling adapter to remove the 12-volt
DC offset that exists. This was to be on the safe side and avoid any chance of damaging our
upconverter. Next, the output of the upconverter went to the RTL SDR and was sampled and filtered
in GNU Radio, producing a J1708-looking message like you see in the bottom right.
Note how the preamble has visible silent periods,
and the body is the continuous section at the end of the message.
Next slide, please.
We developed three methods for demodulating those signals into bits. One method examines the
instantaneous frequency. The other two rely on correlating the signal with specific sequences.
I'll go over them in the next few slides. Next slide, please.
Our first attempts took advantage of GNU Radio's quadrature demod block to produce the plot you
see in the bottom right. The sawtooth pattern you see down there represents the frequency over
time for chirps in the body of the message. The circled spikes indicate sudden changes in phase
at the start of a new chirp. This is what we use to distinguish the ones and zeros.
No change in phase means keeps the value of the previous bit, while phase change means flip the
bit. We framed the start and stop of each message based on the amplitude and tried to ignore the
preamble sections of each message since the body contains the whole J1708 message anyway.
Next slide, please.
We started developing alternative methods because the previous one
did not work well with noise and relied heavily on a consistent signal amplitude.
So to get around that, we correlated the signal with a 203 kilohertz reference.
Now, 203 kilohertz is the precise frequency where each chirp begins. If there's no phase change,
there's a smooth 203 kilohertz signal, which are the higher peaks you see in the output down there.
However, when there's a phase change present, the frequency gets disrupted for a short period of
time. It results in a value close to zero when correlated with the reference.
That's why you kind of see those mini spikes where it's ramping up and down
as it approaches the location where 203 kilohertz should be in the chirp.
Likewise, anything outside the message, like the noise, is going to be reduced to a value close to
zero. We use a moving average filter on the correlation output to frame the message and
ignore the preamble part of it. Next slide, please. Now, for situations where the signal
is completely buried in the noise, the previous two methods are not very effective.
Instead, we tried a new method, which begins by correlating the signal
with a Python-generated chirp designed to mimic a real one.
The result produces much larger peaks, like you see down there, which helps distinguish it from
the noise. We use this technique to frame the message and reuse the 203 kilohertz reference
in the previous method to distinguish the ones and zeros. Next slide, please.
Next slide, please. We call it all GRJ2497. It contains the blocks and flow graphs that will
read the traffic and print out messages like what you see on the right. The values for the MID,
data, and checksum are pulled right from the messages. Additionally, there is an option
built into the blocks to send the messages in hex over to a UDP port for other potential tools to
use. Now, back to Ben to continue on. Thanks, Chris. So, you've got GENIE radio, and you can
now read your PLC signals, but how do you connect your Hammet up or some direct receive receiver
onto PLC? Turns out, once again, just 100 nanofarad capacitor is going to do the trick.
I have used and like to use the 100 volt ones just to be safe, because we don't really want
to get battery currents connected to our receivers. And then you just need a way to connect
those PLC wires onto this coupling network. So, all of those previous adapters that we talked
about all apply in this case, but then how do you connect the wires up? And I think one of the
nice solutions we came up with is modifying these Balan19 adapters. So, you can actually
take the transformer off of the board and cut the trace right here at the back,
replace that transformer with a surface mount capacitor, bridge the ground here, and then cover
it all with solder resist to avoid ever touching 12 volt at back battery currents for trucks.
Another one that's an adapter that works is an antenna. You actually can read these signals
wirelessly. We experimented with a whole bunch of different antennas, but we found that this form
of active antenna, pictured here, works pretty good and is pretty darn cheap. The power supply
that's here is fine, but it works well as well if you connect a 9 volt battery to it instead.
And we believe that there's a lot more options out there because really anything that's made for
2200 meters or low FER is in the right band. But we stuck with portable options because a lot of
low FER and 2200 meter stuff is giant masts and you're not going to move that around with you,
but there are loops and whips and mini whips. But really if you just want to do quick and dirty,
these mini whips work really great for the price. Over here you can actually see, you know, we're
receiving a pretty clear PLC signal on top of the background noise using just this mini whip taped
to the side of a box next to a truck. So we're able to read these signals wirelessly, but
how far? In our testing we can reliably receive six feet away from a position next to the gap
between the tractor and the trailer. Now this was using our first version of the GNU radio receiver,
the one that does the phase measurements and not the new cool stuff that Chris talked about
with correlation. So we feel pretty confident this can be extended. We don't know how far and, you
more testing, we're going to find out. Why do we think this works? It's a bit strange because,
you know, these trailers, or maybe the long ones that we were testing on, were 40 feet.
And a half wave, you know, resonator at 40 feet is really only 12 megahertz, which is
way, way above the 400 kilohertz top end of PLC for trucks. So it really shouldn't be
a good radiator. But when we tested it, it certainly is good enough at this point. And
we think that may be a combination of factors, but possibly primarily due to that very large
voltage that they transmit, that these devices transmit at, to make sure they can make it across
the whole range of the tractor and the trailer. So yeah, the long wires, the high transmit voltages,
I think also contributing this is maybe PLC transmitters are actually left alone to be
noisy. The spec for J2497 allows any conducted noise to be beyond any other restrictions.
And then also FCC's regulations on unintentional radiators actually exempt vehicles,
any digital device utilized exclusively in any transportation vehicle from the unintended
radiator status. Now they do still have to, you know, turn off if they're found to be in violation,
but it's hard to understand how that could be enforced with a large moving vehicle. So it seems
like maybe these are radiators that are beyond spec and no one's been testing for them because
they're exempt or because it's in spec. There are some impacts to this, but the good news is
the impacts aren't very large. It's really a minor impact. On trailers, as we mentioned, really the
main traffic is just the ABS fault information. And if that's the only information that's being
disclosed by these radiators on a remote read, then you're not really losing confidentiality
much. Now if you are a fleet that's deploying other technologies like, you know, way axles
or maybe even your door sensors, any canvassing technology in the trailer, this kind of stuff
might be more confidential. You wouldn't want to have it disclosed. In terms of the impact
in other technologies, other applications of the Intel on P485, we don't really know.
Now one of the reasons we wanted to do this talk is that there are future impacts that really matter.
The ATATMC is working on putting together a new next generation tractor-trailer interface,
and one of the propositions include exchanging keys over PLC. Not that, you know, you can't
do key exchange without guarantees of confidentiality, but we just want everyone
designing those systems to be aware of the fact that you can't assume that what you exchange over
these buses will be confidential. So it could be a problem if it's not implemented correctly.
And then as we mentioned at the beginning of the presentation, this is not unique to PLC for trucks.
This behavior is present in other powerline technologies, and we encourage you to look
at the work of Baker and Martinovic, who showed that this happens in plug-in electric vehicle
chargers. Now what can we do about it? Presently, there's not a whole lot you could do on existing
trailers, because we think that really it's these long wires and the high voltage levels that are
contributing to this. But for the future, there is something you could do. You also should, if you're
a fleet, consider what kind of information is flowing on your trailers. If you are using airway,
if you are using door sensors or canvassing systems, you might want to be aware that that
kind of information can't be considered confidential when your trucks are rolling down the road.
You also should be aware if your maintenance departments configure your trailer ECUs to do
any streaming of readings, which is possible on several of the manufacturers, where you can
configure them to continuously stream wheel speed readings or temperature or voltage readings. Those
wouldn't be considered confidential anymore on those buses. But for the future, when they're
designing the next tractor-trailer interface, I think the main mitigation that needs to be taken
into place is reducing those emissions. And that should be able to be achieved by using PLC on
power lines only between the connections where those J560 connectors are. We recognize that the
J560 connector is not going anywhere. It's going to be too expensive to try to get fleets to move
off of it. So if we only use PLC in between the J560 connectors, that should reduce the radiated
emissions. If we only use it in between those J560 connectors, it also affords designers the
opportunity to use lower transmit voltages because the signals don't have to reach
across the entire tractor-trailer or multiple, especially multiple trailers in tandem.
So this issue has, throughout the process, has been disclosed to various parties over the past
eight months or so. We've been in contact with trailer equipment manufacturers, all three of the
major ones. We have reached out to all the trailer builders. Only one of them responded to us.
We have coordinated the disclosure with NMFDA members and our sponsors. We've also done it with
what was previously ICS CERT, who now wants to be called the CISA Vulnerability Disclosure Program.
And they themselves also reached out to the trailer builders that didn't respond to us.
At this time, CISA BDP has assigned CVE-2020-14514, and there is a advisory on this issue of trailer
powerline communications to raise awareness forthcoming. So in terms of future work, it's
kind of got two different directions. I know our AIS friends here do a lot of industrial control
systems work, and they're very interested in looking at applications of the same method to
various other powerline communication technologies, some of them listed here.
On the transportation side, very much would like to improve those truck tuck features,
you know, get some PLC read going, maybe use the PWM unit instead. I recognize that those
DC blocks could be implemented differently, maybe capacitive coupling on one side of the
transformer instead of removing the transformer. Also, the new Balin-19s have really great screw
terminals, so you could have a much more rugged connection to the powerline. We also would like
to take Chris's receiver code and figure out just how far the reception can be done reasonably using
one of these cheap active antennas, and maybe some of the other more fancy active antennas
that we've bought since then. And then there's also looking at the other places where you find
PLC. We're told that PLC is also used in intramodal, which is where people take containers
and put those on top of flat cars or put them on top of trailers on the road as well. So we'd like
to have a look at how PLC integrates in that space. And there's also this thing, which should
be really fun to look at, that someone took a trailer brake controller and of course added
Wi-Fi to it, because that's a great idea. If anyone wants to have fun with a trailer brake controller,
check this one out. But also at the Car Hacking Village, we have two brake controllers
hooked up to pressured air. I'll tell you about that a little more in a minute.
So yeah, in summary, in conclusion, we got you two tools. There's PLC for TruckDuck,
which enables you to write to PLC using 1-bit PLC chirps that we did with bit banging.
You can make an arbitrary waveform, you know, you can have different PLC MIDs than you do for
the J1708 payloads. Everything we put together is compatible with Haystack's PyHV Networks modules.
There's also the ability to read PLC traffic remotely, and this is tracked also internally
as ICSVU-227452, and I gave you the CVE earlier. And the GR-J2497 tool that Chris told you all
about is capable of receiving this traffic at a distance of six feet. And also that GR-2497 tool
is itself compatible with the PyHV Networks modules from Haystack. So this is what I was
trying to tell you about. We actually have a couple trailer brake controllers turned upside down,
and we've connected Nerf dart firing cactuses to the exhaust ports on the bottom, and we're
running pressurized air on them so that if you can figure out how to do a valve test or do an
ECU reset on one of these things, it should push air through that exhaust port and you should fire
those Nerf darts. And they're connected up on the Virtual Car Hacking Builder system, so there's a
Twitch stream and remote logins to the shells. We do hope that you log in and have a try, and maybe
if you get familiar with them, have a try at that Wi-Fi trailer unit. I know I'd like to someday too.
What we did here was, you know, not the result of just Chris and I's effort, but really the result
of a lot of people committing a lot of resources and assistance over the past few months. And I
really want to take an opportunity to put all their names up here and thank them. Really, this
wouldn't be possible without, you know, support of a team and a community, and I feel really lucky to
be a part of both. So thank you very much for your time. I'll be over in chat with Chris,
hopefully answering any questions you have, and I'll see you at the Virtual Car Hacking Village
later. Bye!