[00:00.640 --> 00:06.940] Hi, welcome to our talk, Powerline Truck Hacking, Two Tools for PLC for Trucks. [00:07.140 --> 00:13.840] We're going to talk to you today for about an hour, you know, who are we, what is PLC, [00:13.840 --> 00:19.280] how do you interface with PLC, what are these two tools, PLC for Trucks, GR2497, [00:19.900 --> 00:25.800] how can you adapt what you got onto the PLC connection. We discovered an issue, [00:25.800 --> 00:29.980] we're going to discuss that issue and the impacts, and then we'll show you some future work. [00:30.640 --> 00:36.360] So first up about us, I'm Ben Gardner, I'm a researcher with the National Motor Freight [00:36.360 --> 00:41.660] Traffic Association, previously done embedded systems development, reverse engineering, [00:41.660 --> 00:46.560] I've been an instructor at the Cybertruck Challenge and plan to, when it ever comes back, [00:46.560 --> 00:53.440] I also volunteer at DEF CON and SAE. Hi, I'm Chris Poore, an electrical engineer who has [00:53.440 --> 00:58.180] been hacking things and helping people get away with it for more years than I can count on these [00:58.180 --> 01:03.100] blood-stained hands. I work at Assured Information Security, headquartered in Rome, [01:03.100 --> 01:09.700] New York, with locations all over the U.S. AIS strives to be a driving force for technology and [01:09.700 --> 01:16.220] national security and has the combined professional experience that I believe is rivaled only by the [01:16.220 --> 01:26.100] space program. Contact AIS today. Next slide, please. It's not just a two-person effort, [01:26.100 --> 01:30.780] we're part of a much larger team, a great team that we've been privileged to be a part of, [01:30.780 --> 01:36.260] comprised of Dan Salone, Christopher Poore, who you now know, Eric Thayer, all of AIS, [01:36.700 --> 01:42.560] and myself from the NMFTA. Also, this research would not have been possible without the support [01:42.560 --> 01:47.120] of the Motor Freight Carrier members of the NMFTA, who sponsored us with access to their [01:47.120 --> 01:52.560] facilities and to their equipment, and thank you for that. First up, what is power line [01:52.560 --> 01:57.880] communications? Generally speaking, any time you're putting data onto lines that are intended [01:57.880 --> 02:03.880] for power, you're doing power line communications. You might know some technologies that fall into [02:03.880 --> 02:08.260] this class, such as Green PHY and Home Plug. There's an entire interoperable family of [02:08.260 --> 02:15.340] technologies in IEEE 1901. The technology is found in automotive, most commonly under SAEJ [02:15.340 --> 02:20.120] 1772, which is for plug-in electric vehicle charging, and there was some really interesting [02:20.120 --> 02:25.740] work by Baker and Martinovic at USENIX 19, where they showed that they could remotely read traffic [02:26.340 --> 02:30.700] between the plug-in electric connection of a vehicle and the charger. But today, we're not [02:30.700 --> 02:36.060] talking about plug-in electric vehicles, we're talking about trucks. So let's rewind the clock [02:36.240 --> 02:41.700] a little bit, maybe a couple decades, and look at what trucks looked like around 1997. There were [02:42.560 --> 02:47.240] anti-lock braking, ABS systems, on trailers and on tractors, and these ABS systems are quite [02:47.240 --> 02:54.640] important to prevent rolls and reduce braking distance. It's really important [02:54.640 --> 03:00.500] for safety. So at the time, there was only a warning on the side of the trailer that showed [03:00.500 --> 03:05.240] you if the ABS was malfunctioning. There are regulators and fleet safety managers that really [03:05.240 --> 03:10.220] wanted to have some kind of a dash display that would show the driver if there was a problem with [03:10.220 --> 03:15.460] the trailer ABS. And this, of course, would help make sure that ABS is functioning and everyone [03:15.460 --> 03:22.440] would stay safe. Now let's look at how these trailers and tractors were connected. So back [03:22.440 --> 03:27.860] then, and actually as it is today, trailers and tractors are connected with a J560 connector. [03:27.860 --> 03:35.340] Here you can see that green pigtailed cable plugging into a bulkhead jack there. And that's [03:35.460 --> 03:41.720] a seven-way connector. You can also see a red and a blue cable behind the bulkhead here. Those are [03:41.720 --> 03:50.060] actually pressurized air, whereas the green cable here, this is electrical. So back then, [03:50.060 --> 03:55.520] they had this tractor-trailer connector. You can see a breakout here of the J560. It's got [03:55.520 --> 04:02.800] tail lights, right turn, left turn, brake lights, a ground connector, and then this power for ABS [04:02.800 --> 04:08.720] and auxiliary power. So it's a fully populated connector. There's no room for anything else, but [04:08.720 --> 04:14.440] still, regulators and safety managers really wanted to have a way to show the driver when [04:14.440 --> 04:19.320] something was failing. Now an obvious option is to add another connector, but unfortunately, [04:19.320 --> 04:24.560] you know, for fleets, the lifetime of trailer equipment is very long and the cost of retrofitting [04:24.560 --> 04:30.200] is very high. So the industry took it upon themselves to design a technology that would [04:30.200 --> 04:36.980] let them send this ABS fault data up into the tractor without adding a new connector. [04:36.980 --> 04:43.000] And at the same time, there was a lot of other technologies that people wanted to get data from [04:43.000 --> 04:49.740] the trailer into the tractor, and there was things like axle weight, door latch, yaw sensors, and [04:49.740 --> 04:55.500] things like that. So it was hoped that this technology could carry all sorts of information [04:55.500 --> 05:01.460] up from the trailer to the tractor, not just the ABS fault info. Around June 1998, ATATMC actually [05:01.460 --> 05:06.060] approved PLC for trucks. This is the American Trucking Association's Technical Maintenance [05:06.060 --> 05:10.300] Council. They are responsible for making recommended practices in the commercial vehicle [05:10.300 --> 05:20.280] space. And eventually, SAE published J2497 in 2002. And what they did was add high-frequency [05:21.700 --> 05:26.860] signals onto these power lines that run the length of the truck. So they would couple them [05:26.860 --> 05:32.080] onto their either transformer or capacitor, just AC-coupled, and send these high-frequency [05:32.080 --> 05:39.780] signals with enough of a voltage that they would propagate. Now, there was an issue with [05:39.780 --> 05:45.300] PLC for trucks that was patent. It was actually patent incumbent. And at the time that they [05:45.300 --> 05:50.220] started the work on this, they didn't know. Eventually, it became known, and SAE actually, [05:50.220 --> 05:56.800] at one point, just canceled the working group to create J2497. And eventually, it was resolved. [05:56.800 --> 06:00.600] The technology was patented for a long time, and there were royalties that had to be paid, but the [06:02.480 --> 06:08.380] standard did go forward. Now, if you go to SAA meetings or ATATMC meetings like I do, [06:08.380 --> 06:13.680] you've probably seen these patent disclosure and IP statements at the beginning of the meetings. [06:13.680 --> 06:18.980] I've been told that for ATATMC, those passages actually exist because of what happened with [06:18.980 --> 06:26.440] PLC for trucks, whereas with SAE, those statements actually predated the PLC for trucks issue. [06:27.060 --> 06:31.740] So it took the industry a while to get it done. It was quite complicated. There was a lot of tests [06:31.740 --> 06:36.160] that happened over the winter and otherwise. And as I mentioned, there was other technologies [06:36.160 --> 06:41.360] that wanted to get like axle weighing and door sensors and things like that up from the trailer [06:41.360 --> 06:47.580] into the tractor. So they had interoperability tests. And it ended up being... eventually, [06:47.580 --> 06:52.260] it was deployed, but it was quite complicated to get it to that point. So the news media [06:53.480 --> 06:59.200] has been seen to call this technology expensive or complicated. There's a funny quote right here [06:59.200 --> 07:03.880] where someone's saying the most expensive light bulb in history. So it is funny to look at the [07:03.880 --> 07:09.420] technology that way. But it's also important to recognize that the calculus that the fleets were [07:09.420 --> 07:13.640] looking at was whether they would have to retrofit all their trailers, which typically have, you know, [07:13.640 --> 07:21.020] 30 year service lifetimes, just to get another light up into the cab. So creating this technology, [07:21.020 --> 07:25.880] even though it seems like it was an expensive light bulb, still, from their point of view, [07:25.880 --> 07:32.320] what they wanted was cheaper. And that's going to be true today as it was back then. The trailers [07:32.320 --> 07:37.380] last for a very long time. The connectors are still the J560 connector. And trying to change [07:37.380 --> 07:44.000] any of that might prove to be more expensive than anyone would want to spend. So now you know a lot [07:44.000 --> 07:48.700] of the history about J2497 and why it came about and why are we sending these high frequency signals [07:48.700 --> 07:55.060] on power lines. Let's talk more about what it is, how it's put together. You can think of J2497 [07:55.060 --> 08:02.460] like an alternate physical layer for J1708. And we're not going to go into J17 a lot because [08:02.460 --> 08:07.380] there's another talk that will give you lots of details on it. Suffice it to say that it's a [08:07.380 --> 08:16.280] heavy vehicle network that predates J1939. J2497 has its own arbitration scheme that it [08:16.280 --> 08:23.740] employs around J1708. The PLC for trucks 2497 is always 9600 bauds. And the way it takes these [08:23.740 --> 08:31.040] 1708 signals is it'll actually encode them into spread spectrum chirps. So another way to think [08:31.040 --> 08:39.340] about 2497 is by an analogy. You can see a couple analogies that I'm making here. You know J1939 [08:39.340 --> 08:47.000] is a lot like J1587. And J1939 can sit on top of high speed or low speed canned buses, twisted or [08:48.060 --> 08:57.840] unshielded. So similarly can J1587 sit on top of either J2497 or just J1708. And you'll probably [08:57.840 --> 09:02.980] have diagnostics or some other applications on top of those. Which if you're not an automotive [09:02.980 --> 09:10.020] person you can think of it by an analogy to DNS which is built on top of UDP. And UDP IP can run [09:10.020 --> 09:18.400] either like ethernet or 802.11 infrared for example. So let's talk a little bit more about [09:18.400 --> 09:24.940] these spread spectrum chirps. The specification of J2497 by SAE actually includes a definition [09:24.940 --> 09:31.260] of the chirp. And they have to sweep from 200 to 400 kilohertz, then from 400 to 100 kilohertz, [09:31.260 --> 09:36.180] and then from 100 to 2 or 3 kilohertz. You can see a picture here of a rendering of a couple [09:36.180 --> 09:42.280] possible chirps. Different possibilities result by how you treat these discontinuities here. [09:42.420 --> 09:49.260] The chirps themselves are about 100 microseconds total. They start and end at value zero so that [09:49.260 --> 09:52.960] they can be concatenated. And when they're transmitted they should be transmitted in [09:52.960 --> 09:58.240] amplitude between 2.5 to 7 volts peak-to-peak according to the spec. Now in practice [09:59.540 --> 10:04.360] the transmitters on trailer equipment tend to send them even higher than 7 volts peak-to-peak [10:04.360 --> 10:09.780] just to make sure that they'll make it from one end of the tractor trailer to the other. [10:11.420 --> 10:16.300] The chirps are put together into frame encodings that will let them actually send [10:16.820 --> 10:21.740] J1708 frames. And the way the frames are encoded is broken up into a preamble and a body. [10:21.760 --> 10:28.160] The purpose of the preamble is there to realize that alternate arbitration method so that if two [10:28.160 --> 10:32.580] PLC devices are trying to talk at the same time there's a way to determine who has the highest [10:32.580 --> 10:39.080] priority and which one should back off. It's very similar to CAN. It involves that very first [10:39.080 --> 10:47.260] byte being sent and the lower byte is the higher priority. So here you can see two renderings of [10:47.260 --> 10:55.800] frames. The first being OA00, the second being OBFF. The OA00 frame and the OBFF frame are the [10:55.800 --> 11:03.540] ADS fault information that we talked about, the impetus for J2497. So in the preamble you can see [11:03.540 --> 11:09.100] that the messages, the actual chirps have delays in between them. And this is because the chirps [11:09.100 --> 11:15.920] are 100 microseconds but the time for the symbols is 104 microseconds, these little gaps. In the [11:15.920 --> 11:23.480] preamble the presence of the chirp indicates, you know, the logic value. So logic 0 means chirp [11:23.480 --> 11:29.580] present, logic 1 is chirp absent. But then when you get into the body it's actually 100 [11:29.580 --> 11:38.240] microseconds with no gaps and the encoding is actually determined by phase. So this is phase [11:38.240 --> 11:44.740] shift keying in the body. The phase of logic 0 is arbitrary per device and it's actually given by [11:44.740 --> 11:50.880] the phase that's transmitted here in the amplitude shift keying section. There's a checksum [11:50.880 --> 11:55.940] at the end and then there's all these sync bits you can see in orange and in green. [11:56.440 --> 12:01.620] And some of these sizes are variable so there could be one to two initial symbols and there [12:01.620 --> 12:14.080] could be zero to four gap symbols. So why is it like that? Well J2497 was designed for J1708. [12:14.420 --> 12:19.420] This whole PLC for trucks scheme was actually accomplished by a particular piece of [12:19.420 --> 12:28.960] silicon, the Intelon SSC P485. And this particular chip was designed to take J1708 frames and wrap [12:28.960 --> 12:34.220] them around with some extra information and re-encode them into these spread spectrum chirps. [12:34.220 --> 12:41.860] So the Intelon P485 actually adds, you know, these sync bits and adds all the preamble highlighted [12:41.860 --> 12:49.280] here in orange. It will then send, you know, the actual encoded information in chirps as the body [12:49.280 --> 12:55.180] which matches exactly what you would see on the J1708 line. And then it adds these terminators with [12:55.180 --> 13:04.040] the gaps and the sync bits. So the checksum is actually part of J1708 and part of J2497. [13:04.780 --> 13:11.680] And you can see there's a duplication of MIDs. You can think of MIDs like arbitration IDs [13:11.680 --> 13:17.980] in CAN. It's that first byte. It determines arbitration on the bus and the data is duplicated [13:18.660 --> 13:27.160] twice. It turns out that this information here in the preamble is used for arbitration of the PLC bus [13:27.160 --> 13:33.860] only. And what gets sent on J1708 is this byte that's put right here, which means that you can [13:33.860 --> 13:39.700] send things where those two don't equal each other. And you can override priority. So you [13:39.700 --> 13:47.100] could send a very low priority MID with an all zero PLC MID and it would margin on top of anyone [13:47.100 --> 13:54.720] else that was talking on PLC. So a little bit about J1587. This is that next layer above. You [13:54.720 --> 14:01.560] can think of it akin to J1939. If you look at the J1587 spec, there's a lot of really interesting [14:01.560 --> 14:06.840] highlights. They say that you shouldn't send more than 21 bytes at a time unless the vehicle is [14:06.840 --> 14:12.680] stationary. I wonder what happens if you don't. There's a factory test MID that should never be [14:12.680 --> 14:19.400] sent by any vehicle system. There are bridging and forwarding schemes defined in the spec. There's a [14:19.400 --> 14:26.360] dynamic address claim. There are cold and warm reset commands and lots of support for interesting [14:26.360 --> 14:30.960] kind of peripherals on commercial vehicles like toll systems and display signage and climate [14:30.960 --> 14:37.940] control. Now for some more details on how to decode J1587 automatically, please see our team's [14:37.940 --> 14:44.740] presentation, which should be up today, or look at the pretty J1587 repository. [14:46.140 --> 14:50.980] Even though J1587 defines a lot of interesting things that could be in there, [14:50.980 --> 14:56.820] all we've seen in our testing for the most part is the ABS fault lamp on and off messages and [14:56.820 --> 15:04.740] manufactured diagnostic messages. There was a report by the FMCSA that suggested that there [15:04.740 --> 15:13.220] should also be axleway yaw sensor and door latch sensor traffic on the PLC bus, but we haven't run [15:13.220 --> 15:24.960] into it yet. So how do you connect to PLC? There are some great options out there. The DG Technologies [15:24.960 --> 15:33.360] PLC TESCON is very rugged and reliable. I love mine. There is also a NEXIC PLC adapter, which [15:33.360 --> 15:40.000] has the advantage of being able to go in line on a cable, so you can you can test it in place. [15:40.280 --> 15:47.180] The problem with these sort of classic diagnostic adapters is that they aren't cheap. You will need [15:47.180 --> 15:53.760] them for running manufactured diagnostic tools though. And also the Intelon P485, I'm told, [15:53.760 --> 15:57.500] is becoming harder to source, which is not going to help with the cost of these tools. [15:57.980 --> 16:03.200] Finally, the limitation of these tools is that you can't do anything strange to PLC with these [16:03.200 --> 16:09.680] tools, because they just have an Intelon P485 chip in them, and so you can't make arbitrary [16:09.680 --> 16:18.140] PLC waveforms. For example, you can't do different PLC MID from a J1708 MID on the bus. [16:19.220 --> 16:26.940] So how do you interface with J1708 so that you can interface with PLC? The first one up is another [16:26.940 --> 16:34.480] one of those RP-1210 adapters, such as the Digitech DPA4, DPA5, or an EXIC USB link. [16:34.480 --> 16:41.700] And these things are necessary for the manufacturer diagnostics. An option that I really like, [16:41.700 --> 16:46.900] that's really cool, that was presented here at DEF CON 24 is the TruckDuck, which is a beaglebone [16:46.900 --> 16:54.660] cape by 6V and Haystack. There's been some revisions to this board since the DEF CON 24 [16:54.660 --> 17:01.640] presentation. There's the 1.5 EET version and the Mega version. These beaglebone capes enable [17:01.640 --> 17:07.920] communication with both J1939, or any Canon network actually, and J1708 networks through [17:07.920 --> 17:14.200] the PiHV networks module that Haystack authored. And we are going to talk about some ways to use [17:14.200 --> 17:21.920] these to write PLC. So our PLC writing tool, what we wanted was something to be low cost. [17:21.920 --> 17:27.540] We wanted it to be open. We wanted it to be capable of doing weird things. We weren't so [17:27.540 --> 17:34.360] concerned about arbitration. The J1708 stack that Haystack put together for the TruckDuck [17:34.360 --> 17:39.680] originally didn't have any arbitration, just had frame detect, and it works fairly well on systems [17:39.680 --> 17:48.320] that aren't highly loaded. And we didn't want to worry about getting read in right now, and the [17:48.320 --> 17:53.800] reason for that you'll see will be clear later. So our approach that we elected, mostly because [17:53.800 --> 17:58.960] we're biased and we like the TruckDuck, is let's make some small mods to the TruckDuck and push [17:58.960 --> 18:05.720] them upstream and try to stick with very small BOM changes, and hopefully 6V can integrate those [18:05.720 --> 18:15.340] into the next Mega Mega EET version of the TruckDuck. So, Bitbanging PWM on the PRU. Bitbanging [18:15.340 --> 18:21.500] is the process of toggling a GPIO in order to create whatever protocol you're after. GPIOs are [18:21.500 --> 18:27.160] general purpose input output pins, of which there are many on the BeagleBOM, and the PRU is a [18:27.160 --> 18:33.480] programmable real-time unit on the BeagleBOM. It runs jitter-free, like deterministic code with no [18:33.480 --> 18:39.300] interrupts stopping execution at 200 megahertz, which is plenty for the 400 kilohertz-ish [18:39.300 --> 18:47.060] signal of PLC. And also the PRU was used originally on the TruckDuck for the J1708 stack itself, [18:47.060 --> 18:52.520] so there's already a precedent there for using the PRU in this system. [18:53.180 --> 19:00.200] It turns out that the TruckDuck J1708 channel 2 has pretty much been broken since release, [19:00.200 --> 19:07.020] which is actually good for us because it lets us reuse, repurpose, one of the PRU cores for [19:07.020 --> 19:16.540] the PLC application instead. And in trying to find pins, we needed to find one that we knew [19:16.540 --> 19:22.040] we could bitbang from the PRU, which is a certain class of pins. But we also wanted to eventually [19:22.040 --> 19:28.280] maybe get rid of the PRU, if possible, and use the integrated PWM unit in the BeagleBOM, although [19:28.280 --> 19:34.040] that hasn't been done yet. So trying to find the pin that would work was, you know, one of [19:34.040 --> 19:39.280] these fun processes. I found it best to just do it with markers. We wanted to make sure that it [19:39.280 --> 19:44.300] could be accessed from the PRU. It could migrate to PWM. We wanted to make sure it didn't conflict [19:44.300 --> 19:50.940] with any other TruckDuck pins. So for synthesizing PLC, we settled eventually on P928. We had a [19:50.940 --> 19:59.040] backup. And then we also planned for doing frame detect and PLC read via an ADC, but we haven't [19:59.040 --> 20:05.700] implement that. That's just kind of allocated for later. So in creating PLC signals, there's two [20:05.700 --> 20:11.340] main parts. You have to synthesize this PLC with PWM, and then you have to couple this signal [20:11.340 --> 20:16.200] that you've created onto the PLC network. So there's these two clouds that we're going to reveal. [20:17.920 --> 20:23.020] I don't often do this, but I thought I would this time. I would try the dumbest thing first, [20:23.020 --> 20:27.880] and my friends will tell you that I'm not very good at doing that, but I did it this time. The [20:27.880 --> 20:33.660] first thing we tried was the dumbest PWM possible. You just turn it on when the signal that you're [20:33.660 --> 20:37.560] trying to realize is above zero, and turn it off when the signal you're trying to realize is below [20:37.560 --> 20:42.880] zero. So you can see that picture here. The orange waveform is the dumb PWM, and the blue waveform [20:42.880 --> 20:50.180] is the true CHIRP. And it turns out that actually worked. So we said yay and moved on. The next part [20:50.180 --> 20:56.140] was coupling. And you can see here in the DGTech PLC test con, the coupling network they created [20:56.140 --> 21:02.980] is just gorgeous. And compared to what we were using, it is amazing because we found out that [21:02.980 --> 21:08.880] 100 nanofarad capacitor was enough, and that was our filtering as well. So the dumbest filtering [21:08.880 --> 21:15.560] and the dumbest PWM got us what we needed, and we moved on. The results were pretty good, [21:15.560 --> 21:22.220] actually. We did run into one issue with undocumented cycle counts for some of the [21:22.220 --> 21:27.320] instructions that we we had to use in assembly, but the results were fine. You can see down here [21:27.320 --> 21:34.080] the orange signal is a recording on an oscilloscope of the PLC signal that we synthesized [21:34.080 --> 21:41.000] after filtering on a receiver. Same with the purple. This is just a larger zoomed out trace. [21:41.260 --> 21:47.140] So this is post-filtering of the signal that we realized. The signal that we realized is much more [21:47.140 --> 21:51.840] like these square waves up here in the tuning edge delays diagram. And this is just a representation [21:51.840 --> 21:56.580] of how we had to tune some of the assembly instructions to make sure that the signal would [21:56.580 --> 22:02.720] line up, you know, all the way into the realization like bit 54 of the PLC chirp train that we had to [22:02.720 --> 22:12.480] create. So it worked pretty well. The code. You can get this tool. It's MIT licensed. It's available [22:12.480 --> 22:21.160] on GitHub as of today. What it does is it adds a new J1708 server. That's the way that the 1708 [22:21.160 --> 22:28.840] was set up on the truck ducks is they receive and send UDP frames and will send or receive those [22:28.840 --> 22:34.280] onto J1708. What we did was create a whole new one that's completely compatible, but what it [22:34.280 --> 22:43.080] does is send PLC signals instead. We also created some command line utilities. The network, the [22:43.080 --> 22:48.860] Pi HV networks that Haystack created has a really nice programming interface for Python, but I just [22:48.860 --> 22:55.120] like to have really simple command line tools like dump and send. So we drafted those and they're [22:55.120 --> 23:03.160] compatible with the existing stack as well. And so to get your truck ducks to connect to PLC, [23:03.160 --> 23:08.300] you actually do need to do some PCB changes to your truck duck for now until 6V rolls us into [23:08.300 --> 23:14.420] the next revision. And this led to probably one of my favorite kind of bodge jobs because I love [23:14.420 --> 23:20.140] to do rework of PCBs and I also really like it when things have to be MacGyvered. When we were [23:20.140 --> 23:26.120] connecting this up to PLC, we discovered that it would work when there was a really long length of [23:26.120 --> 23:31.460] cable in between the power supply of the truck duck and the point where we were coupling to the [23:31.460 --> 23:35.400] network. And if we didn't have that long piece of cable, the truck duck power supply just seemed to [23:35.400 --> 23:43.220] attenuate the PLC signals to almost nothing, which led me to this great bodge job right here where I [23:43.220 --> 23:48.120] wrapped 40 inches of wire and soldered that down to the board in between the input to the power [23:48.120 --> 23:56.600] supply and the connector. And that actually solved the problem, which is fun. Okay, so next up we're [23:56.600 --> 24:01.260] going to show you how you can use some adapters to connect your truck duck up to the power lines. [24:01.260 --> 24:08.560] There's a lot of different options. The first is this J560 to DB15 in Deutsch 2-pin. So these [24:08.560 --> 24:13.880] DB15 connectors, you can find them in a lot of different diagnostics adapters. The DPA4 and the [24:13.880 --> 24:18.280] truck duck both have them. This is a 560 connector here, which is useful to be plugged into the back [24:18.280 --> 24:23.000] of your tractor. You can also plug into the back of your trailer if you have an adapter to connect [24:23.000 --> 24:29.220] to the batteries up here on the Deutsch 2-pin, and the whole set is in the DG Tech PLC Tescon. [24:29.560 --> 24:36.060] Next up is these battery clip, the DB15 adapters, and these ones can be found in the Nexic adapter [24:36.060 --> 24:43.060] sets on the internet. There's also these Y adapters for J560, where they give you a Deutsch [24:43.060 --> 24:49.940] 9-pin connector in line with two J560 connectors, so these can be used in line with a tractor and [24:49.940 --> 24:54.680] trailer that are connected. You've got to watch out that some of these actually do contain an [24:54.680 --> 25:03.680] Intelon P485, and what they're doing is converting PLC to J1708 and routing that to the J1708 pins [25:03.680 --> 25:09.820] instead of PLC onto the power pins. Another one that's useful is one of these inline [25:09.820 --> 25:16.600] jack and plug, which is very similar to the previous one. None of these have the Intelon P485 [25:16.600 --> 25:24.760] inside them. You can also build your own umbilical, so these J560 plugs, you can take them apart by [25:24.760 --> 25:29.620] removing the set screw, and you can wire any kind of a pigtail you like. I like to use these Deutsch [25:29.620 --> 25:34.260] 2 pins because they work with the DG Tech sets, and then you can close it all back up and you can [25:34.260 --> 25:43.300] have a connector that can be used with a tractor and trailer connected. So we also created a PLC [25:43.300 --> 25:51.220] reading tool, and Chris Poore is going to tell you some more details about that. Chris? Thanks, Ben. [25:51.360 --> 25:58.680] One of our goals was to develop a low-cost tool for reading J2497 messages with SDRs and [25:58.680 --> 26:04.320] open source software. We wanted a solution to let just about anybody tap into a line and see [26:04.320 --> 26:16.940] messages all for little cost. Next slide, please. Again, the J2497 signals primarily consist of a [26:16.940 --> 26:23.540] series of 100 microsecond chirps that start at 203 kilohertz, ramp up to 400 kilohertz, quickly [26:23.540 --> 26:31.380] drop down to 100 kilohertz, and back to 203 kilohertz. The 100 to 400 kilohertz frequency [26:31.380 --> 26:40.460] range is lower than most SDRs can handle. For example, the starting frequency of the RTL2832U [26:40.460 --> 26:48.720] dongles vary depending on the model, but they can range from 500 kilohertz to around 50 megahertz. [26:50.060 --> 26:59.920] Next slide, please. To get around this problem, we used up converters. The Hammett up up converter [26:59.920 --> 27:05.860] will take our signal and mix it with an intermediate frequency of 125 megahertz. [27:06.120 --> 27:14.700] I believe the SPIverter uses 120 megahertz. Once it's near 125 megahertz, we can receive it with [27:14.700 --> 27:21.260] radios and begin to condition the signal in software. We improved the quality of the signal [27:21.260 --> 27:29.700] if we didn't tune our radio directly on 125 megahertz, but instead at 126. This allowed [27:29.700 --> 27:35.620] us to use a bandpass filter to get rid of a lot of the DC noise associated with the Hammett up. [27:36.460 --> 27:38.240] Next slide, please. [27:40.240 --> 27:46.220] We achieved most of our success with an RTL and a Hammett up, but there are solutions out there [27:46.220 --> 27:52.600] that could be promising that don't use up converters. We tried the Lime SDR, which starts [27:52.600 --> 27:59.300] at 100 kilohertz, but the gain and performance down at those frequencies was too low for us. [27:59.460 --> 28:06.060] You can find schematics online for modifying RTL SDRs to get a lower starting frequency. [28:06.060 --> 28:11.900] They also make some that have a direct receive mode that can tune down to 500 kilohertz, [28:11.900 --> 28:16.720] but they say the performance is reduced when operating them there. [28:17.740 --> 28:23.040] The AirSpy HF Plus is supposed to start at 9 kilohertz, [28:23.040 --> 28:28.440] but it might not have the bandwidth to support the J2497 chirps. [28:29.520 --> 28:34.580] You might have some luck with oscilloscopes, but then the price starts to go up. [28:34.580 --> 28:39.780] The ADOM2000 is a cheaper option you might want to consider. [28:41.280 --> 28:43.140] Next slide, please. [28:44.420 --> 28:51.540] Back to our setup. When tapped to the line, we used a coupling adapter to remove the 12-volt [28:51.540 --> 28:58.480] DC offset that exists. This was to be on the safe side and avoid any chance of damaging our [28:58.480 --> 29:07.220] upconverter. Next, the output of the upconverter went to the RTL SDR and was sampled and filtered [29:07.220 --> 29:13.490] in GNU Radio, producing a J1708-looking message like you see in the bottom right. [29:14.540 --> 29:18.740] Note how the preamble has visible silent periods, [29:18.740 --> 29:23.760] and the body is the continuous section at the end of the message. [29:25.360 --> 29:27.240] Next slide, please. [29:29.240 --> 29:36.080] We developed three methods for demodulating those signals into bits. One method examines the [29:36.080 --> 29:43.060] instantaneous frequency. The other two rely on correlating the signal with specific sequences. [29:43.100 --> 29:48.480] I'll go over them in the next few slides. Next slide, please. [29:50.400 --> 29:56.660] Our first attempts took advantage of GNU Radio's quadrature demod block to produce the plot you [29:56.660 --> 30:02.500] see in the bottom right. The sawtooth pattern you see down there represents the frequency over [30:02.500 --> 30:09.800] time for chirps in the body of the message. The circled spikes indicate sudden changes in phase [30:09.800 --> 30:16.420] at the start of a new chirp. This is what we use to distinguish the ones and zeros. [30:17.160 --> 30:24.740] No change in phase means keeps the value of the previous bit, while phase change means flip the [30:24.740 --> 30:31.580] bit. We framed the start and stop of each message based on the amplitude and tried to ignore the [30:31.580 --> 30:38.340] preamble sections of each message since the body contains the whole J1708 message anyway. [30:39.700 --> 30:41.400] Next slide, please. [30:43.560 --> 30:47.440] We started developing alternative methods because the previous one [30:47.440 --> 30:53.480] did not work well with noise and relied heavily on a consistent signal amplitude. [30:53.480 --> 30:58.440] So to get around that, we correlated the signal with a 203 kilohertz reference. [30:59.600 --> 31:06.580] Now, 203 kilohertz is the precise frequency where each chirp begins. If there's no phase change, [31:06.580 --> 31:12.960] there's a smooth 203 kilohertz signal, which are the higher peaks you see in the output down there. [31:13.680 --> 31:19.160] However, when there's a phase change present, the frequency gets disrupted for a short period of [31:19.160 --> 31:24.580] time. It results in a value close to zero when correlated with the reference. [31:25.320 --> 31:28.980] That's why you kind of see those mini spikes where it's ramping up and down [31:29.540 --> 31:34.860] as it approaches the location where 203 kilohertz should be in the chirp. [31:35.820 --> 31:42.600] Likewise, anything outside the message, like the noise, is going to be reduced to a value close to [31:42.600 --> 31:49.600] zero. We use a moving average filter on the correlation output to frame the message and [31:49.600 --> 31:59.820] ignore the preamble part of it. Next slide, please. Now, for situations where the signal [31:59.820 --> 32:05.280] is completely buried in the noise, the previous two methods are not very effective. [32:05.280 --> 32:09.820] Instead, we tried a new method, which begins by correlating the signal [32:09.820 --> 32:14.360] with a Python-generated chirp designed to mimic a real one. [32:14.460 --> 32:20.520] The result produces much larger peaks, like you see down there, which helps distinguish it from [32:20.520 --> 32:27.480] the noise. We use this technique to frame the message and reuse the 203 kilohertz reference [32:27.480 --> 32:34.500] in the previous method to distinguish the ones and zeros. Next slide, please. [32:35.800 --> 32:43.320] Next slide, please. We call it all GRJ2497. It contains the blocks and flow graphs that will [32:43.320 --> 32:49.600] read the traffic and print out messages like what you see on the right. The values for the MID, [32:49.600 --> 32:55.860] data, and checksum are pulled right from the messages. Additionally, there is an option [32:55.860 --> 33:03.040] built into the blocks to send the messages in hex over to a UDP port for other potential tools to [33:03.040 --> 33:11.960] use. Now, back to Ben to continue on. Thanks, Chris. So, you've got GENIE radio, and you can [33:11.960 --> 33:17.840] now read your PLC signals, but how do you connect your Hammet up or some direct receive receiver [33:17.840 --> 33:24.740] onto PLC? Turns out, once again, just 100 nanofarad capacitor is going to do the trick. [33:24.880 --> 33:29.900] I have used and like to use the 100 volt ones just to be safe, because we don't really want [33:29.900 --> 33:35.080] to get battery currents connected to our receivers. And then you just need a way to connect [33:35.080 --> 33:42.020] those PLC wires onto this coupling network. So, all of those previous adapters that we talked [33:42.020 --> 33:47.060] about all apply in this case, but then how do you connect the wires up? And I think one of the [33:47.060 --> 33:52.480] nice solutions we came up with is modifying these Balan19 adapters. So, you can actually [33:52.480 --> 33:58.620] take the transformer off of the board and cut the trace right here at the back, [33:58.620 --> 34:05.700] replace that transformer with a surface mount capacitor, bridge the ground here, and then cover [34:05.700 --> 34:12.420] it all with solder resist to avoid ever touching 12 volt at back battery currents for trucks. [34:13.440 --> 34:19.200] Another one that's an adapter that works is an antenna. You actually can read these signals [34:19.200 --> 34:25.920] wirelessly. We experimented with a whole bunch of different antennas, but we found that this form [34:25.920 --> 34:32.680] of active antenna, pictured here, works pretty good and is pretty darn cheap. The power supply [34:32.680 --> 34:39.700] that's here is fine, but it works well as well if you connect a 9 volt battery to it instead. [34:39.760 --> 34:44.480] And we believe that there's a lot more options out there because really anything that's made for [34:44.480 --> 34:51.400] 2200 meters or low FER is in the right band. But we stuck with portable options because a lot of [34:51.400 --> 34:55.940] low FER and 2200 meter stuff is giant masts and you're not going to move that around with you, [34:55.940 --> 35:02.380] but there are loops and whips and mini whips. But really if you just want to do quick and dirty, [35:02.380 --> 35:08.160] these mini whips work really great for the price. Over here you can actually see, you know, we're [35:08.160 --> 35:15.160] receiving a pretty clear PLC signal on top of the background noise using just this mini whip taped [35:15.160 --> 35:21.080] to the side of a box next to a truck. So we're able to read these signals wirelessly, but [35:21.080 --> 35:28.640] how far? In our testing we can reliably receive six feet away from a position next to the gap [35:28.640 --> 35:34.920] between the tractor and the trailer. Now this was using our first version of the GNU radio receiver, [35:34.920 --> 35:39.820] the one that does the phase measurements and not the new cool stuff that Chris talked about [35:39.820 --> 35:47.740] with correlation. So we feel pretty confident this can be extended. We don't know how far and, you [35:47.740 --> 35:55.740] more testing, we're going to find out. Why do we think this works? It's a bit strange because, [35:55.740 --> 36:00.660] you know, these trailers, or maybe the long ones that we were testing on, were 40 feet. [36:01.060 --> 36:07.180] And a half wave, you know, resonator at 40 feet is really only 12 megahertz, which is [36:07.180 --> 36:14.360] way, way above the 400 kilohertz top end of PLC for trucks. So it really shouldn't be [36:15.060 --> 36:21.120] a good radiator. But when we tested it, it certainly is good enough at this point. And [36:21.120 --> 36:29.000] we think that may be a combination of factors, but possibly primarily due to that very large [36:29.000 --> 36:34.020] voltage that they transmit, that these devices transmit at, to make sure they can make it across [36:34.020 --> 36:42.380] the whole range of the tractor and the trailer. So yeah, the long wires, the high transmit voltages, [36:42.380 --> 36:48.260] I think also contributing this is maybe PLC transmitters are actually left alone to be [36:48.260 --> 36:56.860] noisy. The spec for J2497 allows any conducted noise to be beyond any other restrictions. [36:56.880 --> 37:05.180] And then also FCC's regulations on unintentional radiators actually exempt vehicles, [37:05.180 --> 37:09.980] any digital device utilized exclusively in any transportation vehicle from the unintended [37:09.980 --> 37:16.180] radiator status. Now they do still have to, you know, turn off if they're found to be in violation, [37:16.180 --> 37:21.560] but it's hard to understand how that could be enforced with a large moving vehicle. So it seems [37:21.560 --> 37:28.160] like maybe these are radiators that are beyond spec and no one's been testing for them because [37:28.160 --> 37:35.860] they're exempt or because it's in spec. There are some impacts to this, but the good news is [37:35.860 --> 37:41.900] the impacts aren't very large. It's really a minor impact. On trailers, as we mentioned, really the [37:41.900 --> 37:47.560] main traffic is just the ABS fault information. And if that's the only information that's being [37:47.560 --> 37:54.360] disclosed by these radiators on a remote read, then you're not really losing confidentiality [37:55.120 --> 38:01.980] much. Now if you are a fleet that's deploying other technologies like, you know, way axles [38:02.620 --> 38:08.720] or maybe even your door sensors, any canvassing technology in the trailer, this kind of stuff [38:08.720 --> 38:15.060] might be more confidential. You wouldn't want to have it disclosed. In terms of the impact [38:15.060 --> 38:19.820] in other technologies, other applications of the Intel on P485, we don't really know. [38:20.040 --> 38:26.320] Now one of the reasons we wanted to do this talk is that there are future impacts that really matter. [38:26.320 --> 38:32.900] The ATATMC is working on putting together a new next generation tractor-trailer interface, [38:32.900 --> 38:40.180] and one of the propositions include exchanging keys over PLC. Not that, you know, you can't [38:40.180 --> 38:45.500] do key exchange without guarantees of confidentiality, but we just want everyone [38:45.500 --> 38:50.480] designing those systems to be aware of the fact that you can't assume that what you exchange over [38:50.480 --> 38:56.540] these buses will be confidential. So it could be a problem if it's not implemented correctly. [38:56.760 --> 39:01.740] And then as we mentioned at the beginning of the presentation, this is not unique to PLC for trucks. [39:01.740 --> 39:06.440] This behavior is present in other powerline technologies, and we encourage you to look [39:06.440 --> 39:11.120] at the work of Baker and Martinovic, who showed that this happens in plug-in electric vehicle [39:11.120 --> 39:18.180] chargers. Now what can we do about it? Presently, there's not a whole lot you could do on existing [39:18.180 --> 39:22.780] trailers, because we think that really it's these long wires and the high voltage levels that are [39:22.780 --> 39:30.100] contributing to this. But for the future, there is something you could do. You also should, if you're [39:30.240 --> 39:35.860] a fleet, consider what kind of information is flowing on your trailers. If you are using airway, [39:35.860 --> 39:41.280] if you are using door sensors or canvassing systems, you might want to be aware that that [39:41.280 --> 39:45.760] kind of information can't be considered confidential when your trucks are rolling down the road. [39:46.540 --> 39:51.600] You also should be aware if your maintenance departments configure your trailer ECUs to do [39:51.600 --> 39:56.300] any streaming of readings, which is possible on several of the manufacturers, where you can [39:56.300 --> 40:01.600] configure them to continuously stream wheel speed readings or temperature or voltage readings. Those [40:01.600 --> 40:07.040] wouldn't be considered confidential anymore on those buses. But for the future, when they're [40:07.040 --> 40:12.000] designing the next tractor-trailer interface, I think the main mitigation that needs to be taken [40:12.000 --> 40:19.040] into place is reducing those emissions. And that should be able to be achieved by using PLC on [40:19.040 --> 40:26.080] power lines only between the connections where those J560 connectors are. We recognize that the [40:26.080 --> 40:31.620] J560 connector is not going anywhere. It's going to be too expensive to try to get fleets to move [40:31.620 --> 40:38.600] off of it. So if we only use PLC in between the J560 connectors, that should reduce the radiated [40:38.600 --> 40:45.300] emissions. If we only use it in between those J560 connectors, it also affords designers the [40:45.300 --> 40:50.940] opportunity to use lower transmit voltages because the signals don't have to reach [40:51.800 --> 40:57.760] across the entire tractor-trailer or multiple, especially multiple trailers in tandem. [40:59.240 --> 41:06.260] So this issue has, throughout the process, has been disclosed to various parties over the past [41:06.260 --> 41:10.180] eight months or so. We've been in contact with trailer equipment manufacturers, all three of the [41:10.180 --> 41:16.400] major ones. We have reached out to all the trailer builders. Only one of them responded to us. [41:16.660 --> 41:22.960] We have coordinated the disclosure with NMFDA members and our sponsors. We've also done it with [41:22.960 --> 41:29.140] what was previously ICS CERT, who now wants to be called the CISA Vulnerability Disclosure Program. [41:29.600 --> 41:34.400] And they themselves also reached out to the trailer builders that didn't respond to us. [41:35.160 --> 41:45.760] At this time, CISA BDP has assigned CVE-2020-14514, and there is a advisory on this issue of trailer [41:45.760 --> 41:52.720] powerline communications to raise awareness forthcoming. So in terms of future work, it's [41:52.720 --> 41:58.220] kind of got two different directions. I know our AIS friends here do a lot of industrial control [41:58.220 --> 42:02.540] systems work, and they're very interested in looking at applications of the same method to [42:02.540 --> 42:07.140] various other powerline communication technologies, some of them listed here. [42:07.360 --> 42:13.020] On the transportation side, very much would like to improve those truck tuck features, [42:13.020 --> 42:19.940] you know, get some PLC read going, maybe use the PWM unit instead. I recognize that those [42:19.940 --> 42:24.460] DC blocks could be implemented differently, maybe capacitive coupling on one side of the [42:24.460 --> 42:30.160] transformer instead of removing the transformer. Also, the new Balin-19s have really great screw [42:30.160 --> 42:35.640] terminals, so you could have a much more rugged connection to the powerline. We also would like [42:35.640 --> 42:41.880] to take Chris's receiver code and figure out just how far the reception can be done reasonably using [42:41.880 --> 42:46.120] one of these cheap active antennas, and maybe some of the other more fancy active antennas [42:46.120 --> 42:51.560] that we've bought since then. And then there's also looking at the other places where you find [42:51.560 --> 42:57.540] PLC. We're told that PLC is also used in intramodal, which is where people take containers [42:57.540 --> 43:04.360] and put those on top of flat cars or put them on top of trailers on the road as well. So we'd like [43:04.360 --> 43:10.560] to have a look at how PLC integrates in that space. And there's also this thing, which should [43:10.560 --> 43:15.300] be really fun to look at, that someone took a trailer brake controller and of course added [43:15.300 --> 43:21.110] Wi-Fi to it, because that's a great idea. If anyone wants to have fun with a trailer brake controller, [43:21.930 --> 43:28.430] check this one out. But also at the Car Hacking Village, we have two brake controllers [43:28.430 --> 43:32.650] hooked up to pressured air. I'll tell you about that a little more in a minute. [43:33.370 --> 43:39.790] So yeah, in summary, in conclusion, we got you two tools. There's PLC for TruckDuck, [43:39.790 --> 43:46.070] which enables you to write to PLC using 1-bit PLC chirps that we did with bit banging. [43:46.070 --> 43:50.670] You can make an arbitrary waveform, you know, you can have different PLC MIDs than you do for [43:50.670 --> 43:57.090] the J1708 payloads. Everything we put together is compatible with Haystack's PyHV Networks modules. [43:57.470 --> 44:03.390] There's also the ability to read PLC traffic remotely, and this is tracked also internally [44:03.390 --> 44:13.410] as ICSVU-227452, and I gave you the CVE earlier. And the GR-J2497 tool that Chris told you all [44:13.410 --> 44:21.790] about is capable of receiving this traffic at a distance of six feet. And also that GR-2497 tool [44:21.790 --> 44:26.910] is itself compatible with the PyHV Networks modules from Haystack. So this is what I was [44:26.910 --> 44:32.690] trying to tell you about. We actually have a couple trailer brake controllers turned upside down, [44:32.690 --> 44:39.470] and we've connected Nerf dart firing cactuses to the exhaust ports on the bottom, and we're [44:39.470 --> 44:45.270] running pressurized air on them so that if you can figure out how to do a valve test or do an [44:45.270 --> 44:50.870] ECU reset on one of these things, it should push air through that exhaust port and you should fire [44:50.870 --> 44:56.230] those Nerf darts. And they're connected up on the Virtual Car Hacking Builder system, so there's a [44:56.230 --> 45:01.930] Twitch stream and remote logins to the shells. We do hope that you log in and have a try, and maybe [45:01.930 --> 45:08.970] if you get familiar with them, have a try at that Wi-Fi trailer unit. I know I'd like to someday too. [45:11.410 --> 45:16.930] What we did here was, you know, not the result of just Chris and I's effort, but really the result [45:16.930 --> 45:22.430] of a lot of people committing a lot of resources and assistance over the past few months. And I [45:22.430 --> 45:27.390] really want to take an opportunity to put all their names up here and thank them. Really, this [45:27.390 --> 45:33.550] wouldn't be possible without, you know, support of a team and a community, and I feel really lucky to [45:33.550 --> 45:40.150] be a part of both. So thank you very much for your time. I'll be over in chat with Chris, [45:40.150 --> 45:44.450] hopefully answering any questions you have, and I'll see you at the Virtual Car Hacking Village [45:44.450 --> 45:46.450] later. Bye!