[00:01.560 --> 00:07.860]  Hi, welcome to our talk, Powerline Truck Hacking, Two Tools for PLC for Trucks.
[00:08.100 --> 00:14.740]  We're going to talk to you today for about an hour, you know, who are we, what is PLC,
[00:14.740 --> 00:20.240]  how do you interface with PLC, what are these two tools, PLC for Trucks, GR2497,
[00:20.860 --> 00:26.760]  how can you adapt what you got onto the PLC connection. We discovered an issue,
[00:26.760 --> 00:30.900]  we're going to discuss that issue and the impacts, and then we'll show you some future work.
[00:31.600 --> 00:37.320]  So first up about us, I'm Ben Gardner, I'm a researcher with the National Motor Freight
[00:37.320 --> 00:42.820]  Traffic Association, previously done embedded systems development, reverse engineering. I've
[00:42.820 --> 00:47.920]  been an instructor at the Cybertruck Challenge and plan to, when it ever comes back, I also
[00:47.920 --> 00:55.280]  volunteer at DEF CON and SAE. Hi, I'm Chris Poore, an electrical engineer who has been hacking things
[00:55.280 --> 01:00.500]  and helping people get away with it for more years than I can count on these blood-stained hands.
[01:00.920 --> 01:05.280]  I work at Assured Information Security, headquartered in Rome, New York, with locations
[01:05.280 --> 01:11.600]  all over the U.S. AIS strives to be a driving force for technology and national security
[01:12.360 --> 01:18.480]  and has the combined professional experience that I believe is rivaled only by the space program.
[01:18.840 --> 01:23.460]  Contact AIS today. Next slide, please.
[01:25.300 --> 01:29.740]  It's not just a two-person effort though, we're part of a much larger team, a great team that
[01:29.740 --> 01:35.560]  we've been privileged to be a part of, comprised of Dan Salone, Christopher Poore, who you now know,
[01:35.560 --> 01:42.500]  Eric Thayer, all of AIS, and myself from the NMFTA. Also, this research would not have been possible
[01:42.500 --> 01:47.540]  without the support of the Motor Freight Carrier members of the NMFTA who sponsored us with access
[01:47.540 --> 01:53.520]  to their facilities and to their equipment, and thank you for that. First up, what is power line
[01:53.520 --> 01:59.460]  communications? Generally speaking, anytime you're putting data onto lines that are intended for
[02:00.080 --> 02:04.860]  power, you're doing power line communications. You might know some technologies that fall into
[02:04.860 --> 02:09.220]  this class, such as Green PHY and Home Plug. There's an entire interoperable family of
[02:09.220 --> 02:17.420]  technologies in IEEE 1901. The technology is found in automotive, most commonly under SAE J1772,
[02:17.420 --> 02:21.720]  which is for plug-in electric vehicle charging. And there was some really interesting work by
[02:21.720 --> 02:26.740]  Baker and Martinovic using X19, where they showed that they could remotely read traffic
[02:27.300 --> 02:30.660]  between the plug-in electric connection of a vehicle and the charger.
[02:30.660 --> 02:35.040]  But today, we're not talking about plug-in electric vehicles, we're talking about trucks.
[02:35.820 --> 02:40.500]  So let's rewind the clock a little bit, maybe a couple decades, and look at what trucks looked
[02:40.500 --> 02:46.960]  like around 1997. There were anti-lock braking, ABS systems, on trailers and on tractors,
[02:46.960 --> 02:54.560]  and these ABS systems are quite important to prevent rolls and reduce braking distance.
[02:54.560 --> 03:00.660]  It's really important for safety. So at the time, there was only a warning on the side of
[03:00.660 --> 03:05.100]  the trailer that showed you if the ABS was malfunctioning. There are regulators and fleet
[03:05.100 --> 03:10.280]  safety managers that really wanted to have some kind of a dash display that would show the driver
[03:10.280 --> 03:14.940]  if there was a problem with the trailer ABS. And this, of course, would help make sure that ABS is
[03:14.940 --> 03:21.900]  functioning and everyone would stay safe. Now let's look at how these trailers and tractors
[03:21.900 --> 03:26.940]  were connected. So back then, and actually as it is today, trailers and tractors are connected
[03:26.940 --> 03:32.800]  with a J560 connector. Here you can see that green pigtailed cable plugging into a bulkhead
[03:34.120 --> 03:40.320]  jack there, and that's a seven-way connector. You can also see a red and a blue cable behind the
[03:40.320 --> 03:47.640]  bulkhead here. Those are actually pressurized air, whereas the green cable here, this is electrical.
[03:49.680 --> 03:54.500]  So back then, you know, they had this tractor-trailer connector. You can see a breakout
[03:54.500 --> 04:02.260]  here of the J560. It's got taillights, right turn, left turn, you know, brake lights, ground connector,
[04:02.260 --> 04:08.260]  and then this power for ABS and auxiliary power. So it's a fully populated connector. There's no
[04:08.260 --> 04:14.200]  room for anything else, but still regulators and safety managers really wanted to have a way to
[04:14.200 --> 04:19.160]  show the driver when something was failing. Now, an obvious option is to add another connector,
[04:19.160 --> 04:24.440]  but unfortunately, you know, for fleets, the lifetime of trailer equipment is very long,
[04:24.440 --> 04:29.820]  and the cost of retrofitting is very high. So the industry took it upon themselves to design
[04:29.940 --> 04:35.060]  a technology that would let them send this ABS fault data up into the tractor
[04:36.100 --> 04:41.420]  without adding a new connector. And at the same time, there was a lot of other technologies that
[04:42.040 --> 04:47.440]  people wanted to get data from the trailer into the tractor, and there was things like
[04:47.980 --> 04:54.560]  axle weight, door latch, yaw sensors, and things like that. So it was hoped that this
[04:54.560 --> 04:58.220]  technology could carry all sorts of information up from the trailer to the tractor, not just the
[04:58.220 --> 05:05.040]  ABS fault info. Around June 1998, ATATMC actually approved PLC for trucks. This is the American
[05:05.040 --> 05:09.360]  Trucking Association's Technical Maintenance Council. They are responsible for making
[05:09.360 --> 05:16.560]  recommended practices in the commercial vehicle space. And eventually, SAE published J2497 in
[05:16.560 --> 05:25.660]  2002. And what they did was add high-frequency signals onto these power lines that run the length
[05:25.660 --> 05:31.420]  of the truck. So they would couple them onto their either transformer or capacitor, just AC couple
[05:31.420 --> 05:36.100]  them, and send these high-frequency signals with enough of a voltage that they would propagate.
[05:37.060 --> 05:44.560]  Now, there was an issue with PLC for trucks that was a patent. It was actually patent incumbent.
[05:44.900 --> 05:49.540]  And at the time that they started the work on this, they didn't know. Eventually, it became
[05:49.540 --> 05:55.360]  known, and SAE actually, at one point, just canceled the working group to create J2497.
[05:55.840 --> 06:00.560]  And eventually, it was resolved. The technology was patented for a long time, and there were royalties
[06:00.560 --> 06:08.440]  that had to be paid, but the standard did go forward. Now, if you go to SAE meetings or ATATMC
[06:08.440 --> 06:14.000]  meetings like I do, you've probably seen these patent disclosure and IP statements at the beginning
[06:14.000 --> 06:19.580]  of the meetings. I've been told that for ATATMC, those passages actually exist because of what
[06:19.580 --> 06:26.020]  happened with PLC for trucks, whereas with SAE, those statements actually predated the PLC for
[06:26.020 --> 06:32.240]  trucks issue. So it took the industry a while to get it done. It was quite complicated. There was a
[06:32.240 --> 06:36.320]  lot of tests that happened, you know, over the winter and otherwise. And as I mentioned, there
[06:36.320 --> 06:41.080]  was other technologies that wanted to get, like, you know, axle weighing and door sensors and things
[06:41.080 --> 06:46.680]  like that up from the trailer into the tractor. So they had interoperability tests, and it ended up
[06:46.680 --> 06:51.620]  being, you know, eventually it was deployed, but it was quite complicated to get it to that point.
[06:51.620 --> 06:58.680]  So the news media, you know, has been seen to call this technology expensive or complicated.
[06:58.680 --> 07:03.100]  Here's a funny quote right here where someone's saying the most expensive light bulb in history.
[07:03.560 --> 07:07.980]  So it is funny to look at the technology that way, but it's also important to recognize that
[07:07.980 --> 07:12.800]  the calculus that the fleets were looking at was whether they would have to retrofit all
[07:12.800 --> 07:17.940]  their trailers, which typically have, you know, 30-year service lifetimes, just to get another
[07:17.940 --> 07:23.420]  light up into the cab. So creating this technology, even though it seems like it was an expensive
[07:23.420 --> 07:29.740]  light bulb, still, from their point of view, what they wanted was cheaper. And that's going to be
[07:29.740 --> 07:35.880]  true today as it was back then. The trailers last for a very long time, the connectors are still the
[07:35.880 --> 07:41.820]  J560 connector, and trying to change any of that might prove to be more expensive than anyone would
[07:41.820 --> 07:48.280]  want to spend. So now you know a lot of the history about J2497 and why it came about, and why are we
[07:48.280 --> 07:52.900]  sending these high-frequency signals on power lines, let's talk more about what it is, how it's
[07:52.900 --> 08:01.720]  put together. You can think of J2497 like an alternate physical layer for J1708. And we're not
[08:01.720 --> 08:06.160]  going to go into J1708 a lot because there's another talk that will give you lots of details on it.
[08:06.160 --> 08:10.840]  Suffice it to say that it's a heavy vehicle network that predates J1939.
[08:12.500 --> 08:21.300]  J2497 has its own arbitration scheme that it employs around J1708. The PLC for trucks 2497
[08:21.300 --> 08:27.140]  is always 9600 bauds. And the way it takes these 1708 signals is it'll actually encode them into
[08:27.140 --> 08:36.060]  spread spectrum chirps. So another way to think about 2497 is by an analogy. You can see a couple
[08:36.060 --> 08:45.800]  analogies that I'm making here. J1939 is a lot like J1587. And J1939 can sit on top of high-speed
[08:45.800 --> 08:54.340]  or low-speed canned buses, twisted or unshielded. So similarly can J1587 sit on top of either
[08:55.200 --> 09:01.380]  J2497 or just J1708. And you'll probably have diagnostics or some other applications on top of
[09:01.380 --> 09:07.160]  those. Which if you're not an automotive person, you can think of it by an analogy to DNS, which
[09:07.160 --> 09:17.120]  is built on top of UDP. And UDP IP can run on either like Ethernet or 802.11 infrared, for example.
[09:17.740 --> 09:24.060]  So let's talk a little bit more about these spread spectrum chirps. The specification of J2497 by
[09:24.060 --> 09:30.260]  SAE actually includes a definition of the chirp. And they have to sweep from 200 to 400 kilohertz,
[09:30.260 --> 09:36.060]  then from 400 to 100 kilohertz, and then from 100 to 203 kilohertz. You can see a picture here
[09:36.060 --> 09:41.380]  of a rendering of a couple possible chirps. Different possibilities result by how you treat
[09:41.380 --> 09:48.440]  these discontinuities here. The chirps themselves are about 100 microseconds total. They start and
[09:48.440 --> 09:53.480]  end at value zero so that they can be concatenated. And when they're transmitted, they should be
[09:53.480 --> 09:59.180]  transmitted in amplitude between 2.5 to 7 volts peak-to-peak, according to the spec. Now in practice
[10:00.580 --> 10:04.040]  the transmitters on trailer equipment tend to send them even higher than
[10:04.040 --> 10:09.820]  7 volts peak-to-peak, just to make sure that they'll make it from one end of the tractor-trailer
[10:09.820 --> 10:17.240]  to the other. The chirps are put together into frame encodings that will let them actually send
[10:17.240 --> 10:22.720]  J1708 frames. And the way the frames are encoded is broken up into a preamble and a body.
[10:22.720 --> 10:28.800]  The purpose of the preamble is there to realize that alternate arbitration method, so that if
[10:28.800 --> 10:33.340]  two PLC devices are trying to talk at the same time, there's a way to determine who has the
[10:33.340 --> 10:39.280]  highest priority and which one should back off. It's very similar to CAN. It involves, you know,
[10:39.280 --> 10:46.220]  that very first byte being sent and the lower byte is the higher priority. So here you can see
[10:46.220 --> 10:55.680]  two renderings of frames, the first being OA00, the second being OBFF. The OA00 frame and the OBFF
[10:55.680 --> 11:02.080]  frame are the ADS fault information that we talked about, the impetus for J2497.
[11:02.700 --> 11:08.260]  So in the preamble, you can see that the messages, the actual chirps, have delays in between them.
[11:08.260 --> 11:14.240]  And this is because the chirps are 100 microseconds, but the time for the symbols is 104
[11:14.240 --> 11:21.520]  microseconds, these little gaps. In the preamble, the presence of the chirp indicates, you know,
[11:21.520 --> 11:27.760]  the logic value. So logic 0 means chirp present, logic 1 is chirp absent. But then when you get
[11:27.760 --> 11:36.120]  into the body, it's actually 100 microseconds with no gaps, and the encoding is actually
[11:36.120 --> 11:43.880]  determined by phase. So this is phase shift keying in the body. The phase of logic 0 is arbitrary
[11:43.880 --> 11:48.320]  per device, and it's actually given by the phase that's transmitted here in the amplitude shift
[11:48.320 --> 11:55.340]  keying section. There's a checksum at the end, and then there's all these sync bits, you can see
[11:55.340 --> 12:01.480]  in orange and in green. And some of these sizes are variable, so there could be one to two initial
[12:01.480 --> 12:12.840]  symbols, and there could be zero to four gap symbols. So why is it like that? Well, J2497 was designed
[12:12.840 --> 12:20.220]  for J1708. This whole PLC for trucks scheme was actually accomplished by a particular piece
[12:20.220 --> 12:28.760]  of silicon, the Intelon SSC P485. And this particular chip was designed to take J1708 frames
[12:28.760 --> 12:34.720]  and wrap them around with some extra information and re-encode them into these spread spectrum
[12:34.720 --> 12:42.440]  chirps. So the Intelon P485 actually adds, you know, these sync bits and adds all the preamble
[12:42.440 --> 12:49.380]  highlighted here in orange. It will then send, you know, the actual encoded information in chirps
[12:49.380 --> 12:54.780]  as the body, which matches exactly what you would see on the J1708 line. And then it adds these
[12:55.400 --> 13:01.920]  terminators with the gaps and the sync bits. So the checksum is actually part of J1708 and
[13:01.920 --> 13:11.420]  part of J2497. And you can see there's a duplication of MIDs. You can think of MIDs
[13:11.420 --> 13:18.380]  like arbitration IDs in CAN. It's that first byte. It determines arbitration on the bus and the data is
[13:18.380 --> 13:27.320]  duplicated twice. It turns out that this information here in the preamble is used for arbitration of
[13:27.320 --> 13:34.520]  the PLC bus only. And what gets sent on J1708 is this byte that's put right here, which means that
[13:34.520 --> 13:40.660]  you can send things where those two don't equal each other and you can override priority. So you
[13:40.660 --> 13:48.040]  could send a very low priority MID with an all zero PLC MID and it would margin on top of anyone
[13:48.040 --> 13:55.680]  else that was talking on PLC. So a little bit about J1587. This is that next layer above. You
[13:55.680 --> 14:02.540]  can think of it akin to J1939. If you look at the J1587 spec, there's a lot of really interesting
[14:02.540 --> 14:07.820]  highlights. They say that you shouldn't send more than 21 bytes at a time unless the vehicle is
[14:07.820 --> 14:13.620]  stationary. I wonder what happens if you don't. There's a factory test MID that should never be
[14:13.620 --> 14:20.320]  sent by any vehicle system. There are bridging and forwarding schemes defined in the spec. There's a
[14:20.320 --> 14:27.320]  dynamic address claim. There are cold and warm reset commands and lots of support for interesting
[14:27.320 --> 14:31.100]  kind of peripherals on commercial vehicles like toll systems and display signage and
[14:31.100 --> 14:37.460]  climate control. Now for some more details on how to decode J1587 automatically,
[14:37.460 --> 14:45.660]  please see our team's presentation which should be up today or look at the pretty J1587 repository.
[14:47.140 --> 14:52.180]  Even though J1587 defines a lot of interesting things that could be in there,
[14:52.180 --> 14:57.100]  all we've seen in our testing for the most part is the ABS fault lamp on and off messages
[14:57.100 --> 15:05.580]  and manufacturer diagnostic messages. There was a report by the FMCSA that suggested that
[15:05.580 --> 15:13.160]  there should also be axleway yaw sensor and door latch sensor traffic on the PLC bus,
[15:13.160 --> 15:23.520]  but we haven't run into it yet. So how do you connect to PLC? There are some great options
[15:23.520 --> 15:30.640]  out there. The DG Technologies PLC TESCON is very rugged and reliable. I love mine.
[15:31.280 --> 15:36.380]  There is also a NEXIC PLC adapter which has the advantage of being able to go in line
[15:36.380 --> 15:44.080]  on a cable so you can test it in place. The problem with these sort of classic diagnostic
[15:44.080 --> 15:50.960]  adapters is that they aren't cheap. You will need them for running manufacturer diagnostic tools
[15:50.960 --> 15:56.600]  though. And also the Intelon P485 I'm told is becoming harder to source, which is not going
[15:56.600 --> 16:02.160]  to help with the cost of these tools. Finally, the limitation of these tools is that you can't
[16:02.160 --> 16:08.740]  do anything strange to PLC with these tools because they just have an Intelon P485 chip in them,
[16:08.740 --> 16:16.280]  and so you can't make arbitrary PLC waveforms. For example, you can't do different PLC MID from
[16:16.280 --> 16:25.860]  J1708 MID on the bus. So how do you interface with J1708 so that you can interface with PLC?
[16:26.160 --> 16:34.040]  The first one up is another one of those RP1210 adapters such as the DGTEK DPA4, DPA5, or a NEXIC
[16:34.040 --> 16:42.080]  USB link. These things are necessary for the manufacturer diagnostics. An option that I
[16:42.080 --> 16:47.880]  really like that's really cool that was presented here at DEF CON 24 is the TruckDuck, which is a
[16:47.880 --> 16:56.280]  BeagleBone cape by 6Volt and Haystack. There's been some revisions to this board since the DEF
[16:56.280 --> 17:03.920]  CON 24 presentation. There's the 1.5 EET version and the Mega version. These BeagleBone capes
[17:03.920 --> 17:09.140]  enable communication with both J1939, or any CAN network actually, and J1708 networks through the
[17:09.140 --> 17:15.660]  PiHV networks module that Haystack authored. And we are going to talk about some ways to use these
[17:15.660 --> 17:23.040]  to write PLC. So our PLC writing tool, what we wanted was something that would be low cost. We
[17:23.040 --> 17:28.960]  wanted it to be open. We wanted it to be capable of doing weird things. We weren't so concerned
[17:28.960 --> 17:35.800]  about arbitration. The J1708 stack that Haystack put together for the TruckDuck originally
[17:35.800 --> 17:40.800]  didn't have any arbitration. It just had frame detect and it works fairly well on systems that
[17:40.800 --> 17:49.460]  aren't highly loaded. And we didn't want to worry about getting read in right now, and the reason
[17:49.460 --> 17:54.980]  for that you'll see will be clear later. So our approach that we elected, mostly because we're
[17:54.980 --> 18:00.040]  biased and we like the TruckDuck, is let's make some small mods to the TruckDuck and push them
[18:00.040 --> 18:06.900]  upstream and try to stick with very small BOM changes and hopefully 6V can integrate those into
[18:06.900 --> 18:16.540]  the next mega-mega-yeet version of the TruckDuck. So, bit banging PWM on the PRU. Bit banging is
[18:16.540 --> 18:22.780]  the process of toggling a GPIO in order to create whatever protocol you're after. GPIOs are general
[18:22.780 --> 18:28.120]  purpose input output pins, of which there are many on the BeagleBone. And the PRU is a programmable
[18:28.120 --> 18:33.460]  real-time unit on the BeagleBone. It runs jitter-free, like deterministic code with no
[18:33.460 --> 18:42.380]  interrupts stopping execution at 200 MHz, which is plenty for the 400 kHz-ish signal of PLC.
[18:42.940 --> 18:48.040]  And also the PRU was used originally on the TruckDuck for the J1708 stack itself,
[18:48.040 --> 18:53.600]  so there's already precedent there for using the PRU in this system.
[18:54.200 --> 19:01.200]  It turns out that the TruckDuck J1708 channel 2 has pretty much been broken since release,
[19:01.200 --> 19:07.980]  which is actually good for us because it lets us reuse, repurpose, one of the PRU cores for
[19:07.980 --> 19:17.500]  the PLC application instead. And in trying to find pins, we needed to find one that we knew
[19:17.500 --> 19:23.020]  we could bit bang from the PRU, which is a certain class of pins. But we also wanted to eventually
[19:23.020 --> 19:29.260]  maybe get rid of the PRU if possible and use the integrated PWM unit in the BeagleBone, although
[19:29.260 --> 19:35.340]  that hasn't been done yet. So trying to find the pin that would work was one of these fun
[19:35.340 --> 19:40.320]  processes. I found it best to just do it with markers. We wanted to make sure that it could
[19:40.320 --> 19:45.260]  be accessed from the PRU. It could migrate to PWM. We wanted to make sure it didn't conflict
[19:45.260 --> 19:51.600]  with any other TruckDuck pins. So for synthesizing PLC, we settled eventually on P928. We had a
[19:51.600 --> 20:00.000]  backup, and then we also planned for doing frame detect and PLC read via an ADC, but we haven't
[20:00.000 --> 20:06.400]  implemented that. That's just kind of allocated for later. So in creating PLC signals, there's
[20:06.400 --> 20:12.300]  two main parts. You have to synthesize this PLC with PWM, and then you have to couple this signal
[20:12.300 --> 20:17.280]  that you've created onto the PLC network. So there's these two clouds that we're going to reveal.
[20:18.820 --> 20:24.020]  I don't often do this, but I thought I would this time. I would try the dumbest thing first,
[20:24.020 --> 20:28.820]  and my friends will tell you that I'm not very good at doing that, but I did it this time. The
[20:28.820 --> 20:34.620]  first thing we tried was the dumbest PWM possible. You just turn it on when the signal that you're
[20:34.620 --> 20:38.520]  trying to realize is above zero, and turn it off when the signal you're trying to realize is below
[20:38.520 --> 20:43.820]  zero. So you can see that picture here. The orange waveform is the dumb PWM, and the blue waveform
[20:43.820 --> 20:51.120]  is the true CHIRP, and it turns out that actually worked. So we said yay and moved on. The next part
[20:51.120 --> 20:57.100]  was coupling, and you can see here in the DGTech PLC test con, the coupling network they created
[20:57.100 --> 21:03.940]  is just gorgeous, and compared to what we were using, it is amazing because we found out that
[21:03.940 --> 21:09.820]  100 nanofarad capacitor was enough, and that was our filtering as well. So the dumbest filtering
[21:09.820 --> 21:16.520]  and the dumbest PWM got us what we needed, and we moved on. The results were pretty good,
[21:16.520 --> 21:23.180]  actually. We did run into one issue with undocumented cycle counts for some of the
[21:23.180 --> 21:28.300]  instructions that we we had to use in assembly, but the results were fine. You can see down here
[21:28.300 --> 21:35.580]  the orange signal is a recording on an oscilloscope of the PLC signal that we synthesized after
[21:35.580 --> 21:42.740]  filtering on a receiver. Same with the purple, this is just a larger zoomed out trace. So this
[21:42.740 --> 21:48.340]  is post-filtering of the signal that we realized. The signal that we realized is much more like
[21:48.340 --> 21:52.780]  these square waves up here in the tuning edge delays diagram, and this is just a representation
[21:52.780 --> 21:57.320]  of how we had to tune some of the assembly instructions to make sure that the signal
[21:57.320 --> 22:03.180]  would line up, you know, all the way into the realization like bit 54 of the PLC CHIRP train
[22:03.180 --> 22:12.220]  that we had to create. So it worked pretty well. The code. You can get this tool. It's MIT-licensed.
[22:12.620 --> 22:20.520]  It's available on GitHub as of today. What it does is it adds a new J1708 server.
[22:20.520 --> 22:25.820]  That's the way that the 1708 was set up on the truck ducks, is they receive and send UDP frames
[22:26.610 --> 22:33.960]  and will send or receive those onto J1708. What we did was create a whole new one that's
[22:33.960 --> 22:41.120]  completely compatible, but what it does is send PLC signals instead. We also created some command
[22:41.120 --> 22:47.360]  line utilities. The network, the Pi HV networks that Haystack created as a really nice programming
[22:47.360 --> 22:52.660]  interface for Python, but I just like to have really simple command line tools like dump and
[22:52.660 --> 22:58.740]  send. So we drafted those and they're compatible with the existing stack as well.
[23:00.200 --> 23:06.160]  And so to get your truck ducks to connect to PLC, you actually do need to do some PCB
[23:06.160 --> 23:10.360]  changes to your truck duck for now until 6V rolls us into the next revision.
[23:11.180 --> 23:15.620]  And this led to probably one of my favorite kind of bodge jobs because I love to do
[23:15.620 --> 23:21.100]  rework of PCBs and I also really like it when things have to be MacGyvered. When we were
[23:21.100 --> 23:26.900]  connecting this up to PLC, we discovered that it would work when there was a really long length
[23:26.900 --> 23:32.420]  of cable in between the power supply of the truck duck and the point where we were coupling to the
[23:32.420 --> 23:36.360]  network. And if we didn't have that long piece of cable, the truck duck power supply just seemed to
[23:36.360 --> 23:44.180]  attenuate the PLC signals to almost nothing, which led me to this great bodge job right here where I
[23:44.180 --> 23:49.100]  wrapped 40 inches of wire and soldered that down to the board in between the input to the power
[23:49.100 --> 23:57.560]  supply and the connector and that actually solved the problem, which is fun. Okay, so next up we're
[23:57.560 --> 24:02.220]  going to show you how you can use some adapters to connect your truck duck up to the power lines.
[24:02.220 --> 24:08.460]  There's a lot of different options. The first is this J560 to DB15 in Deutsch 2 pin.
[24:09.000 --> 24:13.660]  So these DB15 connectors, you can find them in a lot of different diagnostics adapters,
[24:13.660 --> 24:18.520]  the DPA4 and the truck duck both have them. This is a 560 connector here, which is useful to be
[24:18.520 --> 24:22.760]  plugged into the back of your tractor. You can also plug into the back of your trailer if you
[24:22.760 --> 24:27.720]  have an adapter to connect to the batteries up here on the Deutsch 2 pin and the whole set is
[24:27.720 --> 24:35.060]  in the DG Tech PLC TESCON. Next up is these battery clip the DB15 adapters and these ones
[24:35.060 --> 24:42.020]  can be found in the Nexic adapter sets on the internet. There's also these Y adapters for J560
[24:42.700 --> 24:48.520]  where they give you a Deutsch 9 pin connector in line with two J560 connectors. So these can
[24:48.520 --> 24:53.300]  be used like in line with a tractor and trailer that are connected. You got to watch out that
[24:53.300 --> 25:00.760]  some of these actually do contain an Intelon P485 and what they're doing is converting PLC to J1708
[25:00.760 --> 25:09.600]  and routing that to the J1708 pins instead of PLC onto the power pins. Another one that's useful
[25:09.600 --> 25:14.940]  is one of these inline jack and plug which is very similar to the previous one. None of these have
[25:15.900 --> 25:24.820]  the Intelon P485 inside them. You can also build your own umbilical so these J560 plugs you can
[25:24.820 --> 25:30.040]  take them apart by removing the set screw and you can wire any kind of a pigtail you like. I like to
[25:30.040 --> 25:34.260]  use these Deutsch 2 pins because they work with the DG Tech sets and then you can close it all
[25:34.260 --> 25:40.220]  back up and you can have a connector that can be used with a tractor and trailer connected.
[25:41.480 --> 25:48.780]  So we also created a PLC reading tool and Chris Poore is going to tell you some more details
[25:48.780 --> 25:57.060]  about that. Chris? Thanks Ben. One of our goals was to develop a low-cost tool for reading J2497
[25:57.060 --> 26:04.080]  messages with SDRs and open source software. We wanted a solution to let just about anybody tap
[26:04.080 --> 26:15.910]  into a line and see messages all for little cost. Next slide please. Again the J2497 signals
[26:15.910 --> 26:23.070]  primarily consist of a series of 100 microsecond chirps that start at 203 kilohertz, ramp up to
[26:23.070 --> 26:31.870]  400 kilohertz, quickly drop down to 100 kilohertz, and back to 203 kilohertz. The 100 to 400 kilohertz
[26:31.870 --> 26:39.310]  frequency range is lower than most SDRs can handle. For example, the starting frequency of
[26:39.310 --> 26:47.910]  the RTL2832U dongles vary depending on the model, but they can range from 500 kilohertz to around
[26:47.910 --> 26:59.970]  50 megahertz. Next slide please. To get around this problem we used up converters. The Hammet
[26:59.970 --> 27:06.730]  up-up converter will take our signal and mix it with an intermediate frequency of 125 megahertz.
[27:06.730 --> 27:15.670]  I believe the SPIverter uses 120 megahertz. Once it's near 125 megahertz we can receive it with
[27:15.670 --> 27:22.210]  our radios and begin to condition the signal in software. We improved the quality of the signal
[27:22.210 --> 27:30.990]  if we didn't tune our radio directly on 125 megahertz but instead at 126. This allowed us to
[27:30.990 --> 27:36.610]  use a bandpass filter to get rid of a lot of the DC noise associated with the Hammet up.
[27:37.350 --> 27:39.230]  Next slide please.
[27:41.270 --> 27:47.210]  We achieved most of our success with an RTL and a Hammet up, but there are solutions out there
[27:47.210 --> 27:53.570]  that could be promising that don't use up converters. We tried the Lime SDR which starts
[27:53.570 --> 28:00.190]  at 100 kilohertz, but the gain and performance down at those frequencies was too low for us.
[28:00.190 --> 28:06.700]  You can find schematics online for modifying RTL SDRs to get a lower starting frequency.
[28:07.170 --> 28:12.850]  They also make some that have a direct receive mode that can tune down to 500 kilohertz,
[28:12.850 --> 28:17.670]  but they say the performance is reduced when operating them there.
[28:19.070 --> 28:24.010]  The AirSpy HF Plus is supposed to start at 9 kilohertz,
[28:24.010 --> 28:29.430]  but it might not have the bandwidth to support the J2497 chirps.
[28:30.550 --> 28:35.550]  You might have some luck with oscilloscopes, but then the price starts to go up.
[28:35.630 --> 28:40.770]  The ADOM2000 is a cheaper option you might want to consider.
[28:42.270 --> 28:50.790]  Next slide, please. Back to our setup. When tapped to the line, we used a coupling adapter
[28:50.790 --> 28:58.410]  to remove the 12 volt DC offset that exists. This was to be on the safe side and avoid any chance
[28:58.410 --> 29:07.170]  of damaging our up converter. Next, the output of the up converter went to the RTL SDR and was
[29:07.170 --> 29:13.810]  sampled and filtered in GNU Radio, producing a J1708 looking message like you see in the bottom
[29:13.810 --> 29:22.590]  right. Note how the preamble has visible silent periods and the body is the continuous section
[29:22.590 --> 29:28.510]  at the end of the message. Next slide, please.
[29:30.580 --> 29:35.350]  We developed three methods for demodulating those signals into bits.
[29:35.350 --> 29:41.770]  One method examines the instantaneous frequency. The other two rely on correlating the signal
[29:41.770 --> 29:49.430]  with specific sequences. I'll go over them in the next few slides. Next slide, please.
[29:51.410 --> 29:57.810]  Our first attempts took advantage of GNU Radio's quadrature demod block to produce the plot you see
[29:57.810 --> 30:04.190]  in the bottom right. The sawtooth pattern you see down there represents the frequency over time for
[30:04.190 --> 30:11.270]  chirps in the body of the message. The circled spikes indicate sudden changes in phase at the
[30:11.270 --> 30:18.910]  start of a new chirp. This is what we use to distinguish the ones and zeros. No change in
[30:18.910 --> 30:26.710]  phase means keeps the value of the previous bit, while phase change means flip the bit.
[30:26.950 --> 30:32.550]  We framed the start and stop of each message based on the amplitude and tried to ignore the
[30:32.550 --> 30:39.770]  preamble sections of each message since the body contains the whole J1708 message anyway.
[30:40.610 --> 30:42.850]  Next slide, please.
[30:44.500 --> 30:50.490]  We started developing alternative methods because the previous one did not work well with noise
[30:50.490 --> 30:56.510]  and relied heavily on a consistent signal amplitude. So to get around that, we correlated
[30:56.510 --> 31:04.250]  the signal with a 203 kilohertz reference. Now, 203 kilohertz is the precise frequency where each
[31:04.250 --> 31:11.290]  chirp begins. If there's no phase change, there's a smooth 203 kilohertz signal, which are the higher
[31:11.290 --> 31:18.230]  peaks you see in the output down there. However, when there's a phase change present, the frequency
[31:18.230 --> 31:24.130]  gets disrupted for a short period of time. It results in a value close to zero when correlated
[31:24.130 --> 31:29.970]  with the reference. That's why you kind of see those mini spikes where it's ramping up and down
[31:29.970 --> 31:35.870]  as it approaches the location where 203 kilohertz should be in the chirp.
[31:36.810 --> 31:41.030]  Likewise, anything outside the message, like the noise, is going to be reduced
[31:41.790 --> 31:48.950]  to a value close to zero. We use a moving average filter on the correlation output
[31:48.950 --> 31:55.490]  to frame the message and ignore the preamble part of it. Next slide, please.
[31:58.250 --> 32:02.870]  Now, for situations where the signal is completely buried in the noise,
[32:02.870 --> 32:09.610]  the previous two methods are not very effective. Instead, we tried a new method which begins by
[32:09.610 --> 32:16.510]  correlating the signal with a python-generated chirp designed to mimic a real one. The result
[32:16.510 --> 32:22.550]  produces much larger peaks, like you see down there, which helps distinguish it from the noise.
[32:22.850 --> 32:29.110]  We use this technique to frame the message and reuse the 203 kilohertz reference in the previous
[32:29.110 --> 32:35.450]  method to distinguish the ones and zeros. Next slide, please.
[32:36.990 --> 32:45.390]  We call it all GRJ2497. It contains the blocks and flow graphs that will read the traffic and
[32:45.390 --> 32:51.650]  print out messages like what you see on the right. The values for the MID, data, and checksum
[32:51.650 --> 32:58.490]  are pulled right from the messages. Additionally, there is an option built into the blocks to send
[32:58.490 --> 33:07.270]  the messages in hex over to a UDP port for other potential tools to use. Now, back to Ben to continue
[33:07.270 --> 33:15.030]  on. Thanks, Chris. So, you've got G&E radio and you can now read your PLC signals, but how do you
[33:15.030 --> 33:23.550]  connect your Hammet up or some direct receiver onto PLC? Turns out, once again, just 100
[33:23.550 --> 33:29.050]  nanofarad capacitor is going to do the trick. I have used and like to use the 100 volt ones just
[33:29.050 --> 33:34.050]  to be safe because we don't really want to get battery currents connected to our receivers.
[33:34.510 --> 33:40.930]  And then you just need a way to connect those PLC wires onto this coupling network. So, all of those
[33:40.930 --> 33:46.030]  previous adapters that we talked about all apply in this case. But then, how do you connect the
[33:46.030 --> 33:51.410]  wires up? And I think one of the nice solutions we came up with is modifying these Valon 1.9
[33:51.410 --> 33:58.330]  adapters. So, you can actually take the transformer off of the board and cut the trace right here at
[33:58.330 --> 34:06.390]  the back, replace that transformer with a surface mount capacitor, bridge the ground here, and then
[34:06.390 --> 34:13.060]  cover it all with solder resist to avoid ever touching 12 volt battery currents for trucks.
[34:14.390 --> 34:20.150]  Another one that's an adapter that works is an antenna. You actually can read these signals
[34:20.150 --> 34:26.570]  wirelessly. We experimented with a whole bunch of different antennas, but we found that this
[34:26.570 --> 34:33.190]  form of active antenna, pictured here, works pretty good and is pretty darn cheap. The power
[34:33.190 --> 34:40.690]  supply that's here is fine, but it works well as well if you connect a 9 volt battery to it instead.
[34:40.770 --> 34:45.310]  And we believe that there's a lot more options out there because really anything that's made
[34:45.310 --> 34:52.250]  for 2200 meters or low FER is in the right band. But we stuck with portable options because a lot
[34:52.250 --> 34:57.210]  low FER and 2200 meter stuff is giant masts and you're not going to move that around with you,
[34:57.210 --> 35:03.350]  but there are loops and whips and mini-whips. But really, if you just want to do quick and dirty,
[35:03.350 --> 35:09.110]  these mini-whips work really great for the price. Over here you can actually see, you know, we're
[35:09.110 --> 35:16.130]  receiving a pretty clear PLC signal on top of the background noise using just this mini-whip taped
[35:16.130 --> 35:21.970]  to the side of a box next to a truck. So, we're able to read these signals wirelessly, but
[35:22.250 --> 35:29.630]  how far? In our testing, we can reliably receive six feet away from a position next to the gap
[35:29.630 --> 35:35.850]  between the tractor and the trailer. Now, this was using our first version of the GNU radio receiver,
[35:35.850 --> 35:40.790]  the one that does the phase measurements and not the new cool stuff that Chris talked about
[35:40.790 --> 35:49.730]  with correlation. So, we feel pretty confident this can be extended. We don't know how far and,
[35:49.730 --> 35:57.050]  we're going to find out. Why do we think this works? It's a bit strange because, you know,
[35:57.050 --> 36:03.490]  these trailers, or maybe the long ones that we were testing on, were 40 feet. And a half-wave
[36:04.530 --> 36:12.230]  resonator at 40 feet is really only 12 megahertz, which is way, way above the 400 kilohertz top end
[36:12.230 --> 36:19.030]  of the PLC for trucks. So, it really shouldn't be a good radiator. But when we tested it,
[36:19.030 --> 36:26.250]  certainly is good enough at this point. And we think that may be a combination of factors,
[36:26.250 --> 36:32.590]  but possibly primarily due to that very large voltage that they transmit, that these devices
[36:32.590 --> 36:36.830]  transmit at, to make sure they can make it across the whole range of the tractor and the trailer.
[36:39.110 --> 36:45.570]  So, yeah, the long wires, the high transmit voltages, I think also contributing this is
[36:45.570 --> 36:53.630]  maybe PLC transmitters are actually left alone to be noisy. The spec for J2497 allows any conducted
[36:53.630 --> 37:02.770]  noise to be beyond any other restrictions. And then also FCC's regulations on unintentional
[37:02.770 --> 37:09.090]  radiators actually exempt vehicles, any digital device utilized exclusively in any transportation
[37:09.090 --> 37:16.130]  vehicle from the unintended radiator status. Now, they do still have to turn off if they're found
[37:16.130 --> 37:20.970]  to be in violation, but it's hard to understand how that could be enforced with a large moving
[37:20.970 --> 37:27.990]  vehicle. So, it seems like maybe these are radiators that are beyond spec and no one's
[37:27.990 --> 37:35.830]  been testing for them because they're exempt or because it's in spec. There are some impacts to
[37:35.830 --> 37:40.110]  this, but the good news is the impacts aren't very large. It's really a minor impact.
[37:40.370 --> 37:45.890]  On trailers, as we mentioned, really the main traffic is just the ABS fault information.
[37:46.630 --> 37:52.790]  And if that's the only information that's being disclosed by these radiators on a remote read,
[37:52.790 --> 37:59.970]  then you're not really losing confidentiality much. Now, if you are a fleet that's deploying
[37:59.970 --> 38:08.490]  other technologies like way axles or maybe even your door sensors, any canvassing technology in
[38:08.490 --> 38:12.650]  the trailer, this kind of stuff might be more confidential. You wouldn't want to have it
[38:12.650 --> 38:18.150]  disclosed. In terms of the impact in other technologies, other applications of the Intel
[38:18.150 --> 38:25.290]  on P485, we don't really know. Now, one of the reasons we wanted to do this talk is that there
[38:25.290 --> 38:31.410]  are future impacts that really matter. The ATATMC is working on putting together a new
[38:31.410 --> 38:37.250]  next generation tractor-trailer interface, and one of the propositions include exchanging keys
[38:37.250 --> 38:45.170]  over PLC. Not that you can't do key exchange without guarantees of confidentiality, but we just
[38:45.170 --> 38:50.630]  want everyone designing those systems to be aware of the fact that you can't assume that what you
[38:50.630 --> 38:56.590]  exchange over these buses will be confidential. So, it could be a problem if it's not implemented
[38:56.590 --> 39:01.130]  correctly. And then, as we mentioned at the beginning of the presentation, this is not unique
[39:01.130 --> 39:06.830]  to PLC for trucks. This behavior is present in other powerline technologies, and we encourage
[39:06.830 --> 39:11.750]  you to look at the work of Baker and Martinovic, who showed that this happens in plug-in electric
[39:11.750 --> 39:18.630]  vehicle chargers. Now, what can we do about it? Presently, there's not a whole lot you could do
[39:18.630 --> 39:23.430]  on existing trailers, because we think that really it's these long wires and the high voltage levels
[39:23.430 --> 39:30.870]  that are contributing to this. But for the future, there is something you could do. You also should,
[39:30.870 --> 39:35.630]  if you're a fleet, consider what kind of information is flowing on your trailers. If you are using
[39:35.630 --> 39:42.410]  airway, if you are using door sensors or canvassing systems, you might want to be aware that that kind
[39:42.410 --> 39:46.930]  of information can't be considered confidential when your trucks are rolling down the road.
[39:47.510 --> 39:52.570]  You also should be aware if your maintenance departments configure your trailer ECUs to do
[39:52.570 --> 39:57.270]  any streaming of readings, which is possible on several of the manufacturers, where you can
[39:57.270 --> 40:02.570]  configure them to continuously stream wheel speed readings or temperature or voltage readings. Those
[40:02.570 --> 40:08.010]  wouldn't be considered confidential anymore on those buses. But for the future, when they're
[40:08.010 --> 40:12.970]  designing the next tractor-trailer interface, I think the main mitigation that needs to be taken
[40:12.970 --> 40:19.650]  into place is reducing those emissions. And that should be able to be achieved by using PLC
[40:19.650 --> 40:27.050]  on power lines only between the connections where those J560 connectors are. We recognize that the
[40:27.050 --> 40:32.590]  J560 connector is not going anywhere. It's going to be too expensive to try to get fleets to move
[40:32.590 --> 40:39.570]  off of it. So if we only use PLC in between the J560 connectors, that should reduce the radiated
[40:39.570 --> 40:46.270]  emissions. If we only use it in between those J560 connectors, it also affords designers the
[40:46.270 --> 40:51.910]  opportunity to use lower transmit voltages because the signals don't have to reach
[40:52.770 --> 40:58.730]  across the entire tractor-trailer or multiple, especially multiple trailers in tandem.
[41:00.210 --> 41:07.210]  So this issue has, throughout the process, has been disclosed to various parties over the past
[41:07.210 --> 41:11.150]  eight months or so. We've been in contact with trailer equipment manufacturers, all three of the
[41:11.150 --> 41:17.370]  major ones. We have reached out to all the trailer builders. Only one of them responded to us.
[41:17.610 --> 41:24.130]  We have coordinated disclosure with NMFTA members and our sponsors. We've also done it with what
[41:24.130 --> 41:30.110]  was previously ICS CERT, who now wants to be called the CISA Vulnerability Disclosure Program.
[41:30.530 --> 41:35.370]  And they themselves also reached out to the trailer builders that didn't respond to us.
[41:36.120 --> 41:46.730]  At this time, CISA BDP has assigned CVE-2020-14514, and there is a advisory on this issue of trailer
[41:46.730 --> 41:53.690]  powerline communications to raise awareness forthcoming. So in terms of future work, it's
[41:53.690 --> 41:59.190]  kind of got two different directions. I know our AIS friends here do a lot of industrial control
[41:59.190 --> 42:03.510]  systems work, and they're very interested in looking at applications of the same method to
[42:03.510 --> 42:08.110]  various other powerline communication technologies, some of them listed here.
[42:08.330 --> 42:13.990]  On the transportation side, very much would like to improve those truck duct features,
[42:13.990 --> 42:20.910]  you know, get some PLC read going, maybe use the PWM unit instead. I recognize that those
[42:20.910 --> 42:25.430]  DC blocks could be implemented differently, maybe capacitive coupling on one side of the
[42:25.430 --> 42:31.110]  transformer instead of removing the transformer. Also, the new Balin-19s have really great screw
[42:31.110 --> 42:36.610]  terminals, so you could have a much more rugged connection to the powerline. We also would like
[42:36.610 --> 42:42.850]  to take Chris's receiver code and figure out just how far the reception can be done reasonably using
[42:42.850 --> 42:47.090]  one of these cheap active antennas, and maybe some of the other more fancy active antennas
[42:47.090 --> 42:52.530]  that we've bought since then. And then there's also looking at the other places where you find
[42:52.530 --> 42:59.730]  PLC. We're told that PLC is also used in intramodal, which is where people take containers and put
[42:59.730 --> 43:05.550]  those on top of flat cars or put them on top of trailers on the road as well. So we'd like to have
[43:05.650 --> 43:11.850]  a look at how PLC integrates in that space. And there's also this thing, which should be really
[43:11.850 --> 43:17.190]  fun to look at. Someone took a trailer brake controller and of course added Wi-Fi to it,
[43:17.190 --> 43:22.050]  because that's a great idea. If anyone wants to have fun with a trailer brake controller,
[43:22.890 --> 43:29.390]  check this one out. But also at the Car Hacking Village, we have two brake controllers
[43:29.390 --> 43:33.630]  hooked up to pressured air. I'll tell you about that a little more in a minute.
[43:34.350 --> 43:40.750]  So yeah, in summary, in conclusion, we got you two tools. There's PLC for TruckDuck,
[43:40.750 --> 43:47.030]  which enables you to write to PLC using 1-bit PLC chirps that we did with bit banging.
[43:47.030 --> 43:51.650]  You can make an arbitrary waveform, you know, you can have different PLC MIDs than you do for
[43:51.650 --> 43:57.790]  the J1708 payloads. Everything we put together is compatible with Haystack's PyHV Networks modules.
[43:58.370 --> 44:04.370]  There's also the ability to read PLC traffic remotely. And this is tracked also internally
[44:04.370 --> 44:14.390]  as ICSVU-227452, and I gave you the CVE earlier. And the GR-J2497 tool that Chris told you all
[44:14.390 --> 44:22.350]  about, he is capable of receiving this traffic at a distance of six feet. And also that GR-2497
[44:22.350 --> 44:27.890]  tool is itself compatible with the PyHV Networks modules from Haystack. So this is what I was
[44:27.890 --> 44:33.670]  trying to tell you about. We actually have a couple trailer brake controllers turned upside down,
[44:33.670 --> 44:40.450]  and we've connected Nerf dart firing cactuses to the exhaust ports on the bottom, and we're
[44:40.450 --> 44:46.250]  running pressurized air on them so that if you can figure out how to do a valve test or do an
[44:46.250 --> 44:51.390]  ECU reset on one of these things, it should push air through that exhaust port, and you should
[44:51.390 --> 44:56.630]  fire those Nerf darts. And they're connected up on the Virtual Car Hacking Builder system,
[44:56.630 --> 45:01.410]  so there's a Twitch stream and remote logins to the shells. We do hope that you log in and
[45:01.410 --> 45:07.990]  have a try, and maybe if you get familiar with them, have a try at that Wi-Fi trailer unit.
[45:07.990 --> 45:15.750]  I know I'd like to someday, too. What we did here was, you know, not the result of just
[45:15.750 --> 45:20.450]  Chris and I's effort, but really the result of a lot of people committing a lot of resources
[45:20.450 --> 45:25.330]  and assistance over the past few months, and I really want to take an opportunity to put all
[45:25.330 --> 45:30.050]  their names up here and thank them. Really, this wouldn't be possible without, you know,
[45:30.050 --> 45:36.010]  support of a team and a community, and I feel really lucky to be a part of both.
[45:36.010 --> 45:41.110]  So thank you very much for your time. I'll be over in chat with Chris,
[45:41.110 --> 45:45.430]  hopefully answering any questions you have, and I'll see you at the Virtual Car Hacking Village
[45:45.430 --> 45:47.270]  later. Bye!