WEBVTT 00:01.560 --> 00:07.860 Hi, welcome to our talk, Powerline Truck Hacking, Two Tools for PLC for Trucks. 00:08.100 --> 00:25.340 We're going to talk to you today for about an hour, you know, who are we, what is PLC, how do you interface with PLC, what are these two tools, PLC for Trucks, GR2497, how can you adapt what you got onto the PLC connection. 00:25.480 --> 00:30.900 We discovered an issue, we're going to discuss that issue and the impacts, and then we'll show you some future work. 00:31.600 --> 00:42.560 So first up about us, I'm Ben Gardner, I'm a researcher with the National Motor Freight Traffic Association, previously done embedded systems development, reverse engineering. 00:42.560 --> 00:51.000 I've been an instructor at the Cybertruck Challenge and plan to, when it ever comes back, I also volunteer at DEF CON and SAE. 00:51.000 --> 01:00.500 Hi, I'm Chris Poore, an electrical engineer who has been hacking things and helping people get away with it for more years than I can count on these blood-stained hands. 01:00.920 --> 01:07.040 I work at Assured Information Security, headquartered in Rome, New York, with locations all over the U.S. 01:07.380 --> 01:18.480 AIS strives to be a driving force for technology and national security and has the combined professional experience that I believe is rivaled only by the space program. 01:18.840 --> 01:20.980 Contact AIS today. 01:22.000 --> 01:23.460 Next slide, please. 01:25.300 --> 01:39.880 It's not just a two-person effort though, we're part of a much larger team, a great team that we've been privileged to be a part of, comprised of Dan Salone, Christopher Poore, who you now know, Eric Thayer, all of AIS, and myself from the NMFTA. 01:40.540 --> 01:50.840 Also, this research would not have been possible without the support of the Motor Freight Carrier members of the NMFTA who sponsored us with access to their facilities and to their equipment, and thank you for that. 01:51.480 --> 01:54.640 First up, what is power line communications? 01:54.820 --> 02:02.840 Generally speaking, anytime you're putting data onto lines that are intended for power, you're doing power line communications. 02:02.840 --> 02:07.340 You might know some technologies that fall into this class, such as Green PHY and Home Plug. 02:07.340 --> 02:11.740 There's an entire interoperable family of technologies in IEEE 1901. 02:11.980 --> 02:19.980 The technology is found in automotive, most commonly under SAE J1772, which is for plug-in electric vehicle charging. 02:20.220 --> 02:30.660 And there was some really interesting work by Baker and Martinovic using X19, where they showed that they could remotely read traffic 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:42.020 So let's rewind the clock a little bit, maybe a couple decades, and look at what trucks looked like around 1997. 02:42.020 --> 02:54.560 There were anti-lock braking, ABS systems, on trailers and on tractors, and these ABS systems are quite important to prevent rolls and reduce braking distance. 02:54.560 --> 02:56.520 It's really important for safety. 02:57.080 --> 03:03.360 So at the time, there was only a warning on the side of the trailer that showed you if the ABS was malfunctioning. 03:03.560 --> 03:12.220 There are regulators and fleet safety managers that really wanted to have some kind of a dash display that would show the driver if there was a problem with the trailer ABS. 03:12.220 --> 03:17.560 And this, of course, would help make sure that ABS is functioning and everyone would stay safe. 03:19.640 --> 03:22.900 Now let's look at how these trailers and tractors were connected. 03:22.900 --> 03:28.800 So back then, and actually as it is today, trailers and tractors are connected with a J560 connector. 03:28.800 --> 03:37.500 Here you can see that green pigtailed cable plugging into a bulkhead jack there, and that's a seven-way connector. 03:37.500 --> 03:42.320 You can also see a red and a blue cable behind the bulkhead here. 03:42.320 --> 03:47.640 Those are actually pressurized air, whereas the green cable here, this is electrical. 03:49.680 --> 03:53.860 So back then, you know, they had this tractor-trailer connector. 03:53.860 --> 03:56.060 You can see a breakout here of the J560. 03:56.060 --> 04:05.260 It's got taillights, right turn, left turn, you know, brake lights, ground connector, and then this power for ABS and auxiliary power. 04:05.260 --> 04:07.980 So it's a fully populated connector. 04:07.980 --> 04:16.880 There's no room for anything else, but still regulators and safety managers really wanted to have a way to show the driver when something was failing. 04:16.920 --> 04:26.500 Now, an obvious option is to add another connector, but unfortunately, you know, for fleets, the lifetime of trailer equipment is very long, and the cost of retrofitting is very high. 04:26.500 --> 04:38.180 So the industry took it upon themselves to design a technology that would let them send this ABS fault data up into the tractor without adding a new connector. 04:38.480 --> 04:51.860 And at the same time, there was a lot of other technologies that people wanted to get data from the trailer into the tractor, and there was things like axle weight, door latch, yaw sensors, and things like that. 04:52.080 --> 04:59.500 So it was hoped that this technology could carry all sorts of information up from the trailer to the tractor, not just the ABS fault info. 04:59.600 --> 05:04.300 Around June 1998, ATATMC actually approved PLC for trucks. 05:04.300 --> 05:07.880 This is the American Trucking Association's Technical Maintenance Council. 05:07.880 --> 05:12.220 They are responsible for making recommended practices in the commercial vehicle space. 05:12.360 --> 05:18.100 And eventually, SAE published J2497 in 2002. 05:18.400 --> 05:26.740 And what they did was add high-frequency signals onto these power lines that run the length of the truck. 05:26.740 --> 05:36.100 So they would couple them onto their either transformer or capacitor, just AC couple them, and send these high-frequency signals with enough of a voltage that they would propagate. 05:37.060 --> 05:43.000 Now, there was an issue with PLC for trucks that was a patent. 05:43.000 --> 05:44.560 It was actually patent incumbent. 05:44.900 --> 05:48.260 And at the time that they started the work on this, they didn't know. 05:48.560 --> 05:55.360 Eventually, it became known, and SAE actually, at one point, just canceled the working group to create J2497. 05:55.840 --> 05:57.820 And eventually, it was resolved. 05:57.820 --> 06:05.500 The technology was patented for a long time, and there were royalties that had to be paid, but the standard did go forward. 06:05.900 --> 06:14.620 Now, if you go to SAE meetings or ATATMC meetings like I do, you've probably seen these patent disclosure and IP statements at the beginning of the meetings. 06:14.620 --> 06:27.280 I've been told that for ATATMC, those passages actually exist because of what happened with PLC for trucks, whereas with SAE, those statements actually predated the PLC for trucks issue. 06:28.120 --> 06:30.780 So it took the industry a while to get it done. 06:30.780 --> 06:31.840 It was quite complicated. 06:31.840 --> 06:35.100 There was a lot of tests that happened, you know, over the winter and otherwise. 06:35.160 --> 06:43.400 And as I mentioned, there was other technologies that wanted to get, like, you know, axle weighing and door sensors and things like that up from the trailer into the tractor. 06:43.400 --> 06:51.620 So they had interoperability tests, and it ended up 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:16.820 So it is funny to look at the technology that way, but it's also important to recognize that the calculus that the fleets were looking at was whether they would have to retrofit all their trailers, which typically have, you know, 30-year service lifetimes, 07:16.820 --> 07:20.160 just to get another light up into the cab. 07:20.160 --> 07:28.580 So creating this technology, even though it seems like it was an expensive light bulb, still, from their point of view, what they wanted was cheaper. 07:28.580 --> 07:32.340 And that's going to be true today as it was back then. 07:32.400 --> 07:43.020 The trailers last for a very long time, the connectors are still the J560 connector, and trying to change any of that might prove to be more expensive than anyone would want to spend. 07:43.840 --> 07:53.880 So now you know a lot of the history about J2497 and why it came about, and why are we sending these high-frequency signals on power lines, let's talk more about what it is, how it's put together. 07:53.940 --> 08:00.620 You can think of J2497 like an alternate physical layer for J1708. 08:00.620 --> 08:06.160 And we're not 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:19.120 J2497 has its own arbitration scheme that it employs around J1708. 08:19.120 --> 08:23.340 The PLC for trucks 2497 is always 9600 bauds. 08:23.340 --> 08:29.720 And the way it takes these 1708 signals is it'll actually encode them into spread spectrum chirps. 08:30.020 --> 08:34.560 So another way to think about 2497 is by an analogy. 08:34.640 --> 08:37.980 You can see a couple analogies that I'm making here. 08:39.680 --> 08:42.620 J1939 is a lot like J1587. 08:42.840 --> 08:50.220 And J1939 can sit on top of high-speed or low-speed canned buses, twisted or unshielded. 08:50.520 --> 08:58.020 So similarly can J1587 sit on top of either J2497 or just J1708. 08:58.020 --> 09:02.460 And you'll probably have diagnostics or some other applications on top of those. 09:02.460 --> 09:08.860 Which if you're not an automotive person, you can think of it by an analogy to DNS, which is built on top of UDP. 09:08.880 --> 09:17.120 And UDP IP can run on either like Ethernet or 802.11 infrared, for example. 09:17.740 --> 09:21.180 So let's talk a little bit more about these spread spectrum chirps. 09:21.180 --> 09:27.080 The specification of J2497 by SAE actually includes a definition of the chirp. 09:27.080 --> 09:34.660 And they have to sweep from 200 to 400 kilohertz, then from 400 to 100 kilohertz, and then from 100 to 203 kilohertz. 09:34.660 --> 09:39.120 You can see a picture here of a rendering of a couple possible chirps. 09:39.120 --> 09:43.160 Different possibilities result by how you treat these discontinuities here. 09:43.400 --> 09:47.520 The chirps themselves are about 100 microseconds total. 09:47.520 --> 09:51.760 They start and end at value zero so that they can be concatenated. 09:52.220 --> 09:58.460 And when they're transmitted, they should be transmitted in amplitude between 2.5 to 7 volts peak-to-peak, according to the spec. 09:58.460 --> 10:10.820 Now in practice the transmitters on trailer equipment tend to send them even higher than 7 volts peak-to-peak, just to make sure that they'll make it from one end of the tractor-trailer to the other. 10:12.240 --> 10:19.100 The chirps are put together into frame encodings that will let them actually send J1708 frames. 10:19.100 --> 10:22.720 And the way the frames are encoded is broken up into a preamble and a body. 10:22.720 --> 10:36.140 The purpose of the preamble is there to realize that alternate arbitration method, so that if two PLC devices are trying to talk at the same time, there's a way to determine who has the highest priority and which one should back off. 10:36.140 --> 10:37.780 It's very similar to CAN. 10:37.820 --> 10:44.300 It involves, you know, that very first byte being sent and the lower byte is the higher priority. 10:44.480 --> 10:52.720 So here you can see two renderings of frames, the first being OA00, the second being OBFF. 10:52.840 --> 11:02.080 The OA00 frame and the OBFF 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:16.120 And this is because the chirps are 100 microseconds, but the time for the symbols is 104 microseconds, these little gaps. 11:16.200 --> 11:23.060 In the preamble, the presence of the chirp indicates, you know, the logic value. 11:23.060 --> 11:26.600 So logic 0 means chirp present, logic 1 is chirp absent. 11:26.820 --> 11:38.060 But then when you get into the body, it's actually 100 microseconds with no gaps, and the encoding is actually determined by phase. 11:38.280 --> 11:40.820 So this is phase shift keying in the body. 11:40.920 --> 11:49.440 The phase of logic 0 is arbitrary per device, and it's actually given by the phase that's transmitted here in the amplitude shift keying section. 11:50.720 --> 11:56.860 There's a checksum at the end, and then there's all these sync bits, you can see in orange and in green. 11:57.300 --> 12:05.640 And some of these sizes are variable, so there could be one to two initial symbols, and there could be zero to four gap symbols. 12:08.220 --> 12:09.760 So why is it like that? 12:09.760 --> 12:14.820 Well, J2497 was designed for J1708. 12:15.260 --> 12:24.080 This whole PLC for trucks scheme was actually accomplished by a particular piece of silicon, the Intelon SSC P485. 12:24.280 --> 12:35.200 And this particular chip was designed to take J1708 frames and wrap them around with some extra information and re-encode them into these spread spectrum chirps. 12:35.200 --> 12:44.180 So the Intelon P485 actually adds, you know, these sync bits and adds all the preamble highlighted here in orange. 12:44.180 --> 12:53.420 It will then send, you know, the actual encoded information in chirps as the body, which matches exactly what you would see on the J1708 line. 12:53.420 --> 12:58.560 And then it adds these terminators with the gaps and the sync bits. 12:58.700 --> 13:05.080 So the checksum is actually part of J1708 and part of J2497. 13:05.660 --> 13:10.120 And you can see there's a duplication of MIDs. 13:10.120 --> 13:13.180 You can think of MIDs like arbitration IDs in CAN. 13:13.180 --> 13:14.120 It's that first byte. 13:14.120 --> 13:20.740 It determines arbitration on the bus and the data is duplicated twice. 13:20.900 --> 13:29.200 It turns out that this information here in the preamble is used for arbitration of the PLC bus only. 13:29.300 --> 13:40.480 And what gets sent on J1708 is this byte that's put right here, which means that you can send things where those two don't equal each other and you can override priority. 13:40.480 --> 13:49.720 So you could send a very low priority MID with an all zero PLC MID and it would margin on top of anyone else that was talking on PLC. 13:51.180 --> 13:53.280 So a little bit about J1587. 13:53.280 --> 13:55.640 This is that next layer above. 13:55.640 --> 13:58.100 You can think of it akin to J1939. 13:59.040 --> 14:03.400 If you look at the J1587 spec, there's a lot of really interesting highlights. 14:03.880 --> 14:08.620 They say that you shouldn't send more than 21 bytes at a time unless the vehicle is stationary. 14:08.620 --> 14:10.440 I wonder what happens if you don't. 14:10.560 --> 14:15.520 There's a factory test MID that should never be sent by any vehicle system. 14:15.760 --> 14:19.540 There are bridging and forwarding schemes defined in the spec. 14:19.540 --> 14:21.800 There's a dynamic address claim. 14:22.100 --> 14:32.520 There are cold and warm reset commands and lots of support for interesting kind of peripherals on commercial vehicles like toll systems and display signage and climate control. 14:32.840 --> 14:45.660 Now for some more details on how to decode J1587 automatically, please see our team's presentation which should be up today or look at the pretty J1587 repository. 14:47.140 --> 15:00.760 Even though J1587 defines a lot of interesting things that could be in there, all we've seen in our testing for the most part is the ABS fault lamp on and off messages and manufacturer diagnostic messages. 15:00.760 --> 15:16.220 There was a report by the FMCSA that suggested that there should also be axleway yaw sensor and door latch sensor traffic on the PLC bus, but we haven't run into it yet. 15:17.200 --> 15:21.520 So how do you connect to PLC? 15:21.520 --> 15:24.560 There are some great options out there. 15:24.560 --> 15:29.300 The DG Technologies PLC TESCON is very rugged and reliable. 15:29.300 --> 15:30.640 I love mine. 15:31.280 --> 15:41.360 There is also a NEXIC PLC adapter which has the advantage of being able to go in line on a cable so you can test it in place. 15:41.420 --> 15:46.760 The problem with these sort of classic diagnostic adapters is that they aren't cheap. 15:47.080 --> 15:51.720 You will need them for running manufacturer diagnostic tools though. 15:52.140 --> 15:58.500 And also the Intelon P485 I'm told is becoming harder to source, which is not going to help with the cost of these tools. 15:58.940 --> 16:12.220 Finally, the limitation of these tools is that you can't do anything strange to PLC with these tools because they just have an Intelon P485 chip in them, and so you can't make arbitrary PLC waveforms. 16:12.220 --> 16:19.120 For example, you can't do different PLC MID from J1708 MID on the bus. 16:20.120 --> 16:25.860 So how do you interface with J1708 so that you can interface with PLC? 16:26.160 --> 16:35.420 The first one up is another one of those RP1210 adapters such as the DGTEK DPA4, DPA5, or a NEXIC USB link. 16:35.420 --> 16:40.080 These things are necessary for the manufacturer diagnostics. 16:40.220 --> 16:51.320 An option that I really like that's really cool that was presented here at DEF CON 24 is the TruckDuck, which is a BeagleBone cape by 6Volt and Haystack. 16:51.400 --> 16:56.280 There's been some revisions to this board since the DEF CON 24 presentation. 16:56.280 --> 17:00.220 There's the 1.5 EET version and the Mega version. 17:00.600 --> 17:12.260 These BeagleBone capes enable communication with both J1939, or any CAN network actually, and J1708 networks through the PiHV networks module that Haystack authored. 17:12.660 --> 17:17.920 And we are going to talk about some ways to use these to write PLC. 17:18.080 --> 17:22.880 So our PLC writing tool, what we wanted was something that would be low cost. 17:22.880 --> 17:24.440 We wanted it to be open. 17:24.660 --> 17:27.700 We wanted it to be capable of doing weird things. 17:27.700 --> 17:30.340 We weren't so concerned about arbitration. 17:30.340 --> 17:37.500 The J1708 stack that Haystack put together for the TruckDuck originally didn't have any arbitration. 17:37.500 --> 17:42.500 It just had frame detect and it works fairly well on systems that aren't highly loaded. 17:43.940 --> 17:52.400 And we didn't want to worry about getting read in right now, and the reason for that you'll see will be clear later. 17:52.660 --> 18:10.760 So our approach that we elected, mostly because we're biased and we like the TruckDuck, is let's make some small mods to the TruckDuck and push them upstream and try to stick with very small BOM changes and hopefully 6V can integrate those into the next mega-mega-yeet version of the TruckDuck. 18:12.180 --> 18:15.740 So, bit banging PWM on the PRU. 18:15.740 --> 18:21.900 Bit banging is the process of toggling a GPIO in order to create whatever protocol you're after. 18:21.920 --> 18:26.400 GPIOs are general purpose input output pins, of which there are many on the BeagleBone. 18:26.400 --> 18:30.040 And the PRU is a programmable real-time unit on the BeagleBone. 18:30.040 --> 18:42.380 It runs jitter-free, like deterministic code with no interrupts stopping execution at 200 MHz, which is plenty for the 400 kHz-ish signal of PLC. 18:42.940 --> 18:53.600 And also the PRU was used originally on the TruckDuck for the J1708 stack itself, so there's already precedent there for using the PRU in this system. 18:54.200 --> 19:10.360 It turns out that the TruckDuck J1708 channel 2 has pretty much been broken since release, which is actually good for us because it lets us reuse, repurpose, one of the PRU cores for the PLC application instead. 19:11.620 --> 19:21.400 And in trying to find pins, we needed to find one that we knew we could bit bang from the PRU, which is a certain class of pins. 19:21.400 --> 19:31.320 But we also wanted to eventually maybe get rid of the PRU if possible and use the integrated PWM unit in the BeagleBone, although that hasn't been done yet. 19:31.320 --> 19:35.900 So trying to find the pin that would work was one of these fun processes. 19:35.900 --> 19:38.440 I found it best to just do it with markers. 19:38.760 --> 19:41.540 We wanted to make sure that it could be accessed from the PRU. 19:41.540 --> 19:43.480 It could migrate to PWM. 19:43.540 --> 19:47.080 We wanted to make sure it didn't conflict with any other TruckDuck pins. 19:47.580 --> 19:51.280 So for synthesizing PLC, we settled eventually on P928. 19:51.280 --> 20:00.660 We had a backup, and then we also planned for doing frame detect and PLC read via an ADC, but we haven't implemented that. 20:00.660 --> 20:03.280 That's just kind of allocated for later. 20:03.420 --> 20:07.340 So in creating PLC signals, there's two main parts. 20:07.340 --> 20:14.220 You have to synthesize this PLC with PWM, and then you have to couple this signal that you've created onto the PLC network. 20:14.220 --> 20:17.280 So there's these two clouds that we're going to reveal. 20:18.820 --> 20:22.040 I don't often do this, but I thought I would this time. 20:22.040 --> 20:28.280 I would try the dumbest thing first, and my friends will tell you that I'm not very good at doing that, but I did it this time. 20:28.440 --> 20:31.620 The first thing we tried was the dumbest PWM possible. 20:31.620 --> 20:39.280 You just turn it on when the signal that you're trying to realize is above zero, and turn it off when the signal you're trying to realize is below zero. 20:39.440 --> 20:40.740 So you can see that picture here. 20:40.740 --> 20:47.220 The orange waveform is the dumb PWM, and the blue waveform is the true CHIRP, and it turns out that actually worked. 20:47.220 --> 20:50.220 So we said yay and moved on. 20:50.300 --> 21:08.960 The next part was coupling, and you can see here in the DGTech PLC test con, the coupling network they created is just gorgeous, and compared to what we were using, it is amazing because we found out that 100 nanofarad capacitor was enough, and that was our filtering as well. 21:08.960 --> 21:13.780 So the dumbest filtering and the dumbest PWM got us what we needed, and we moved on. 21:14.080 --> 21:17.140 The results were pretty good, actually. 21:17.140 --> 21:27.340 We did run into one issue with undocumented cycle counts for some of the instructions that we we had to use in assembly, but the results were fine. 21:27.340 --> 21:37.840 You can see down here the orange signal is a recording on an oscilloscope of the PLC signal that we synthesized after filtering on a receiver. 21:37.840 --> 21:41.880 Same with the purple, this is just a larger zoomed out trace. 21:42.400 --> 21:46.280 So this is post-filtering of the signal that we realized. 21:46.280 --> 21:58.540 The signal that we realized is much more like these square waves up here in the tuning edge delays diagram, and this is just a representation of how we had to tune some of the assembly instructions to make sure that the signal would line up, you know, 21:58.540 --> 22:04.480 all the way into the realization like bit 54 of the PLC CHIRP train that we had to create. 22:04.780 --> 22:06.640 So it worked pretty well. 22:07.900 --> 22:08.840 The code. 22:08.840 --> 22:10.240 You can get this tool. 22:10.240 --> 22:12.220 It's MIT-licensed. 22:12.620 --> 22:16.480 It's available on GitHub as of today. 22:16.880 --> 22:20.520 What it does is it adds a new J1708 server. 22:20.520 --> 22:31.360 That's the way that the 1708 was set up on the truck ducks, is they receive and send UDP frames and will send or receive those onto J1708. 22:31.360 --> 22:38.820 What we did was create a whole new one that's completely compatible, but what it does is send PLC signals instead. 22:38.940 --> 22:42.380 We also created some command line utilities. 22:42.700 --> 22:53.420 The network, the Pi HV networks that Haystack created as a really nice programming interface for Python, but I just like to have really simple command line tools like dump and send. 22:53.420 --> 22:58.740 So we drafted those and they're compatible with the existing stack as well. 23:00.200 --> 23:10.360 And so to get your truck ducks to connect to PLC, you actually do need to do some PCB changes to your truck duck for now until 6V rolls us into the next revision. 23:11.180 --> 23:20.240 And this led to probably one of my favorite kind of bodge jobs because I love to do rework of PCBs and I also really like it when things have to be MacGyvered. 23:20.240 --> 23:32.960 When we were connecting this up to PLC, we discovered that it would work when there was a really long length of cable in between the power supply of the truck duck and the point where we were coupling to the network. 23:32.960 --> 23:52.800 And if we didn't have that long piece of cable, the truck duck power supply just seemed to attenuate the PLC signals to almost nothing, which led me to this great bodge job right here where I wrapped 40 inches of wire and soldered that down to the board in between the input to the power supply and the connector and that actually solved the problem, 23:52.800 --> 23:54.820 which is fun. 23:56.280 --> 24:02.220 Okay, so next up we're going to show you how you can use some adapters to connect your truck duck up to the power lines. 24:02.220 --> 24:03.740 There's a lot of different options. 24:03.740 --> 24:08.460 The first is this J560 to DB15 in Deutsch 2 pin. 24:09.000 --> 24:16.160 So these DB15 connectors, you can find them in a lot of different diagnostics adapters, the DPA4 and the truck duck both have them. 24:16.160 --> 24:20.800 This is a 560 connector here, which is useful to be plugged into the back of your tractor. 24:20.800 --> 24:30.200 You can also plug into the back of your trailer if you have an adapter to connect to the batteries up here on the Deutsch 2 pin and the whole set is in the DG Tech PLC TESCON. 24:30.440 --> 24:38.520 Next up is these battery clip the DB15 adapters and these ones can be found in the Nexic adapter sets on the internet. 24:39.080 --> 24:48.180 There's also these Y adapters for J560 where they give you a Deutsch 9 pin connector in line with two J560 connectors. 24:48.180 --> 24:52.360 So these can be used like in line with a tractor and trailer that are connected. 24:52.360 --> 25:07.240 You got to watch out that some of these actually do contain an Intelon P485 and what they're doing is converting PLC to J1708 and routing that to the J1708 pins instead of PLC onto the power pins. 25:08.460 --> 25:14.000 Another one that's useful is one of these inline jack and plug which is very similar to the previous one. 25:14.000 --> 25:18.560 None of these have the Intelon P485 inside them. 25:19.880 --> 25:29.700 You can also build your own umbilical so these J560 plugs you can take them apart by removing the set screw and you can wire any kind of a pigtail you like. 25:29.700 --> 25:40.220 I like to use these Deutsch 2 pins because they work with the DG Tech sets and then you can close it all back up and you can have a connector that can be used with a tractor and trailer connected. 25:41.480 --> 25:49.960 So we also created a PLC reading tool and Chris Poore is going to tell you some more details about that. 25:49.960 --> 25:50.860 Chris? 25:51.000 --> 25:52.460 Thanks Ben. 25:52.600 --> 26:01.300 One of our goals was to develop a low-cost tool for reading J2497 messages with SDRs and open source software. 26:01.460 --> 26:07.900 We wanted a solution to let just about anybody tap into a line and see messages all for little cost. 26:08.520 --> 26:10.600 Next slide please. 26:12.850 --> 26:29.810 Again the J2497 signals primarily consist of a series of 100 microsecond chirps that start at 203 kilohertz, ramp up to 400 kilohertz, quickly drop down to 100 kilohertz, and back to 203 kilohertz. 26:29.930 --> 26:36.930 The 100 to 400 kilohertz frequency range is lower than most SDRs can handle. 26:37.050 --> 26:49.730 For example, the starting frequency of the RTL2832U dongles vary depending on the model, but they can range from 500 kilohertz to around 50 megahertz. 26:50.830 --> 26:52.990 Next slide please. 26:55.490 --> 26:59.490 To get around this problem we used up converters. 26:59.490 --> 27:06.730 The Hammet up-up converter will take our signal and mix it with an intermediate frequency of 125 megahertz. 27:06.730 --> 27:11.470 I believe the SPIverter uses 120 megahertz. 27:11.790 --> 27:20.190 Once it's near 125 megahertz we can receive it with our radios and begin to condition the signal in software. 27:20.230 --> 27:29.550 We improved the quality of the signal if we didn't tune our radio directly on 125 megahertz but instead at 126. 27:29.830 --> 27:36.610 This allowed us to 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:50.830 We achieved most of our success with an RTL and a Hammet up, but there are solutions out there that could be promising that don't use up converters. 27:50.830 --> 28:00.190 We tried the Lime SDR which starts 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:17.670 They also make some that have a direct receive mode that can tune down to 500 kilohertz, but they say the performance is reduced when operating them there. 28:19.070 --> 28:29.430 The AirSpy HF Plus is supposed to start at 9 kilohertz, 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:44.090 Next slide, please. 28:45.410 --> 28:47.230 Back to our setup. 28:47.230 --> 28:55.170 When tapped to the line, we used a coupling adapter to remove the 12 volt DC offset that exists. 28:55.430 --> 29:00.550 This was to be on the safe side and avoid any chance of damaging our up converter. 29:01.290 --> 29:14.870 Next, the output of the up converter went to the RTL SDR and was sampled and filtered in GNU Radio, producing a J1708 looking message like you see in the bottom right. 29:15.550 --> 29:24.790 Note how the preamble has visible silent periods and the body is the continuous section at the end of the message. 29:26.290 --> 29:28.510 Next slide, please. 29:30.580 --> 29:35.350 We developed three methods for demodulating those signals into bits. 29:35.350 --> 29:39.030 One method examines the instantaneous frequency. 29:39.030 --> 29:43.910 The other two rely on correlating the signal with specific sequences. 29:43.910 --> 29:46.670 I'll go over them in the next few slides. 29:47.210 --> 29:49.430 Next slide, please. 29:51.410 --> 29:59.250 Our first attempts took advantage of GNU Radio's quadrature demod block to produce the plot you see in the bottom right. 29:59.330 --> 30:06.970 The sawtooth pattern you see down there represents the frequency over time for chirps in the body of the message. 30:06.990 --> 30:13.150 The circled spikes indicate sudden changes in phase at the start of a new chirp. 30:13.410 --> 30:17.770 This is what we use to distinguish the ones and zeros. 30:18.010 --> 30:26.710 No change in phase means keeps the value of the previous bit, while phase change means flip the bit. 30:26.950 --> 30:39.770 We framed the start and stop of each message based on the amplitude and tried to ignore the preamble sections of each message since the body contains the whole J1708 message anyway. 30:40.610 --> 30:42.850 Next slide, please. 30:44.500 --> 30:54.510 We started developing alternative methods because the previous one did not work well with noise and relied heavily on a consistent signal amplitude. 30:54.510 --> 30:59.730 So to get around that, we correlated the signal with a 203 kilohertz reference. 31:00.310 --> 31:05.770 Now, 203 kilohertz is the precise frequency where each chirp begins. 31:05.990 --> 31:13.930 If there's no phase change, there's a smooth 203 kilohertz signal, which are the higher peaks you see in the output down there. 31:14.650 --> 31:21.010 However, when there's a phase change present, the frequency gets disrupted for a short period of time. 31:21.010 --> 31:25.550 It results in a value close to zero when correlated with the reference. 31:26.290 --> 31:35.870 That's why you kind of see those mini spikes where it's ramping up and down as it approaches the location where 203 kilohertz should be in the chirp. 31:36.810 --> 31:44.550 Likewise, anything outside the message, like the noise, is going to be reduced to a value close to zero. 31:45.290 --> 31:53.170 We use a moving average filter on the correlation output to frame the message and ignore the preamble part of it. 31:53.490 --> 31:55.490 Next slide, please. 31:58.250 --> 32:06.190 Now, for situations where the signal is completely buried in the noise, the previous two methods are not very effective. 32:06.190 --> 32:15.370 Instead, we tried a new method which begins by correlating the signal with a python-generated chirp designed to mimic a real one. 32:15.410 --> 32:22.550 The result produces much larger peaks, like you see down there, which helps distinguish it from the noise. 32:22.850 --> 32:32.490 We use this technique to frame the message and reuse the 203 kilohertz reference in the previous method to distinguish the ones and zeros. 32:33.650 --> 32:35.450 Next slide, please. 32:36.990 --> 32:41.450 We call it all GRJ2497. 32:41.650 --> 32:48.210 It contains the blocks and flow graphs that will read the traffic and print out messages like what you see on the right. 32:48.430 --> 32:54.110 The values for the MID, data, and checksum are pulled right from the messages. 32:54.750 --> 33:05.050 Additionally, there is an option built into the blocks to send the messages in hex over to a UDP port for other potential tools to use. 33:05.390 --> 33:08.130 Now, back to Ben to continue on. 33:09.030 --> 33:09.970 Thanks, Chris. 33:09.970 --> 33:20.690 So, you've got G&E radio and you can now read your PLC signals, but how do you connect your Hammet up or some direct receiver onto PLC? 33:21.270 --> 33:25.750 Turns out, once again, just 100 nanofarad capacitor is going to do the trick. 33:25.930 --> 33:34.050 I have used and like to use the 100 volt ones just to be safe because we don't really want to get battery currents connected to our receivers. 33:34.510 --> 33:39.690 And then you just need a way to connect those PLC wires onto this coupling network. 33:39.710 --> 33:44.930 So, all of those previous adapters that we talked about all apply in this case. 33:44.930 --> 33:46.930 But then, how do you connect the wires up? 33:46.930 --> 33:52.470 And I think one of the nice solutions we came up with is modifying these Valon 1.9 adapters. 33:52.650 --> 34:13.060 So, you can actually take the transformer off of the board and cut the trace right here at the back, replace that transformer with a surface mount capacitor, bridge the ground here, and then cover it all with solder resist to avoid ever touching 12 volt battery currents for trucks. 34:14.390 --> 34:17.770 Another one that's an adapter that works is an antenna. 34:17.770 --> 34:21.750 You actually can read these signals wirelessly. 34:21.750 --> 34:32.710 We experimented with a whole bunch of different antennas, but we found that this form of active antenna, pictured here, works pretty good and is pretty darn cheap. 34:32.710 --> 34:40.690 The power 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:50.070 And we believe that there's a lot more options out there because really anything that's made for 2200 meters or low FER is in the right band. 34:50.070 --> 34:59.790 But we stuck with portable options because a lot low FER and 2200 meter stuff is giant masts and you're not going to move that around with you, but there are loops and whips and mini-whips. 35:00.650 --> 35:06.290 But really, if you just want to do quick and dirty, these mini-whips work really great for the price. 35:06.510 --> 35:18.170 Over here you can actually see, you know, we're receiving a pretty clear PLC signal on top of the background noise using just this mini-whip taped to the side of a box next to a truck. 35:19.410 --> 35:23.350 So, we're able to read these signals wirelessly, but how far? 35:23.350 --> 35:31.850 In our testing, we can reliably receive six feet away from a position next to the gap between the tractor and the trailer. 35:32.090 --> 35:41.890 Now, this was using our first version of the GNU radio receiver, the one that does the phase measurements and not the new cool stuff that Chris talked about with correlation. 35:42.030 --> 35:44.950 So, we feel pretty confident this can be extended. 35:44.950 --> 35:51.210 We don't know how far and, we're going to find out. 35:52.470 --> 35:54.350 Why do we think this works? 35:54.810 --> 36:01.610 It's a bit strange because, you know, these trailers, or maybe the long ones that we were testing on, were 40 feet. 36:02.050 --> 36:13.850 And a half-wave resonator at 40 feet is really only 12 megahertz, which is way, way above the 400 kilohertz top end of the PLC for trucks. 36:13.850 --> 36:17.410 So, it really shouldn't be a good radiator. 36:17.410 --> 36:22.010 But when we tested it, certainly is good enough at this point. 36:22.010 --> 36:36.830 And we think that may be a combination of factors, but possibly primarily due to that very large voltage that they transmit, that these devices transmit at, to make sure they can make it across the whole range of the tractor and the trailer. 36:39.110 --> 36:49.690 So, yeah, the long wires, the high transmit voltages, I think also contributing this is maybe PLC transmitters are actually left alone to be noisy. 36:49.690 --> 36:57.830 The spec for J2497 allows any conducted noise to be beyond any other restrictions. 36:57.830 --> 37:12.090 And then also FCC's regulations on unintentional radiators actually exempt vehicles, any digital device utilized exclusively in any transportation vehicle from the unintended radiator status. 37:12.090 --> 37:21.890 Now, they do still have to turn off if they're found to be in violation, but it's hard to understand how that could be enforced with a large moving vehicle. 37:21.990 --> 37:32.830 So, it seems like maybe these are radiators that are beyond spec and no one's been testing for them because they're exempt or because it's in spec. 37:34.330 --> 37:38.490 There are some impacts to this, but the good news is the impacts aren't very large. 37:38.490 --> 37:40.110 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:57.190 And if that's the only information that's being disclosed by these radiators on a remote read, then you're not really losing confidentiality much. 37:57.490 --> 38:11.810 Now, if you are a fleet that's deploying other technologies like way axles or maybe even your door sensors, any canvassing technology in the trailer, this kind of stuff might be more confidential. 38:11.810 --> 38:13.790 You wouldn't want to have it disclosed. 38:13.910 --> 38:20.930 In terms of the impact in other technologies, other applications of the Intel on P485, we don't really know. 38:21.050 --> 38:27.470 Now, one of the reasons we wanted to do this talk is that there are future impacts that really matter. 38:27.830 --> 38:39.010 The ATATMC is working on putting together a new next generation tractor-trailer interface, and one of the propositions include exchanging keys over PLC. 38:39.010 --> 38:54.270 Not that you can't do key exchange without guarantees of confidentiality, but we just want everyone designing those systems to be aware of the fact that you can't assume that what you exchange over these buses will be confidential. 38:54.670 --> 38:57.510 So, it could be a problem if it's not implemented correctly. 38:57.750 --> 39:02.710 And then, as we mentioned at the beginning of the presentation, this is not unique to PLC for trucks. 39:02.710 --> 39:12.950 This behavior is present in other powerline technologies, and we encourage you to look at the work of Baker and Martinovic, who showed that this happens in plug-in electric vehicle chargers. 39:13.810 --> 39:15.730 Now, what can we do about it? 39:16.290 --> 39:25.050 Presently, there's not a whole lot you could do on existing trailers, because we think that really it's these long wires and the high voltage levels that are contributing to this. 39:25.230 --> 39:29.310 But for the future, there is something you could do. 39:29.690 --> 39:34.750 You also should, if you're a fleet, consider what kind of information is flowing on your trailers. 39:34.750 --> 39:46.930 If you are using airway, if you are using door sensors or canvassing systems, you might want to be aware that that kind of information can't be considered confidential when your trucks are rolling down the road. 39:47.510 --> 40:02.430 You also should be aware if your maintenance departments configure your trailer ECUs to do any streaming of readings, which is possible on several of the manufacturers, where you can configure them to continuously stream wheel speed readings or temperature or voltage readings. 40:02.430 --> 40:05.870 Those wouldn't be considered confidential anymore on those buses. 40:05.890 --> 40:15.730 But for the future, when they're designing the next tractor-trailer interface, I think the main mitigation that needs to be taken into place is reducing those emissions. 40:15.810 --> 40:25.850 And that should be able to be achieved by using PLC on power lines only between the connections where those J560 connectors are. 40:25.850 --> 40:29.250 We recognize that the J560 connector is not going anywhere. 40:29.250 --> 40:33.570 It's going to be too expensive to try to get fleets to move off of it. 40:33.570 --> 40:40.670 So if we only use PLC in between the J560 connectors, that should reduce the radiated emissions. 40:40.670 --> 40:58.730 If we only use it in between those J560 connectors, it also affords designers the opportunity to use lower transmit voltages because the signals don't have to reach across the entire tractor-trailer or multiple, especially multiple trailers in tandem. 41:00.210 --> 41:08.230 So this issue has, throughout the process, has been disclosed to various parties over the past eight months or so. 41:08.230 --> 41:12.190 We've been in contact with trailer equipment manufacturers, all three of the major ones. 41:12.190 --> 41:15.070 We have reached out to all the trailer builders. 41:15.070 --> 41:17.370 Only one of them responded to us. 41:17.610 --> 41:22.170 We have coordinated disclosure with NMFTA members and our sponsors. 41:22.350 --> 41:30.110 We've also done it with what 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:50.490 At this time, CISA BDP has assigned CVE-2020-14514, and there is a advisory on this issue of trailer powerline communications to raise awareness forthcoming. 41:50.810 --> 41:55.310 So in terms of future work, it's kind of got two different directions. 41:55.310 --> 42:08.110 I know our AIS friends here do a lot of industrial control systems work, and they're very interested in looking at applications of the same method to various other powerline communication technologies, some of them listed here. 42:08.330 --> 42:19.030 On the transportation side, very much would like to improve those truck duct features, you know, get some PLC read going, maybe use the PWM unit instead. 42:19.690 --> 42:27.790 I recognize that those DC blocks could be implemented differently, maybe capacitive coupling on one side of the transformer instead of removing the transformer. 42:28.030 --> 42:35.070 Also, the new Balin-19s have really great screw terminals, so you could have a much more rugged connection to the powerline. 42:35.490 --> 42:48.570 We also would like to take Chris's receiver code and figure out just how far the reception can be done reasonably using one of these cheap active antennas, and maybe some of the other more fancy active antennas that we've bought since then. 42:48.950 --> 42:53.150 And then there's also looking at the other places where you find PLC. 42:53.150 --> 43:04.990 We're told that PLC is also used in intramodal, which is where people take containers and put those on top of flat cars or put them on top of trailers on the road as well. 43:04.990 --> 43:07.930 So we'd like to have a look at how PLC integrates in that space. 43:08.870 --> 43:12.890 And there's also this thing, which should be really fun to look at. 43:13.010 --> 43:18.790 Someone took a trailer brake controller and of course added Wi-Fi to it, because that's a great idea. 43:19.250 --> 43:24.430 If anyone wants to have fun with a trailer brake controller, check this one out. 43:25.850 --> 43:31.830 But also at the Car Hacking Village, we have two brake controllers hooked up to pressured air. 43:31.830 --> 43:33.630 I'll tell you about that a little more in a minute. 43:34.350 --> 43:39.390 So yeah, in summary, in conclusion, we got you two tools. 43:39.390 --> 43:47.030 There's PLC for TruckDuck, which enables you to write to PLC using 1-bit PLC chirps that we did with bit banging. 43:47.030 --> 43:53.510 You can make an arbitrary waveform, you know, you can have different PLC MIDs than you do for the J1708 payloads. 43:53.510 --> 43:57.790 Everything we put together is compatible with Haystack's PyHV Networks modules. 43:58.370 --> 44:02.230 There's also the ability to read PLC traffic remotely. 44:02.250 --> 44:09.870 And this is tracked also internally as ICSVU-227452, and I gave you the CVE earlier. 44:09.870 --> 44:19.410 And the GR-J2497 tool that Chris told you all about, he is capable of receiving this traffic at a distance of six feet. 44:19.450 --> 44:27.130 And also that GR-2497 tool is itself compatible with the PyHV Networks modules from Haystack. 44:27.130 --> 44:28.990 So this is what I was trying to tell you about. 44:28.990 --> 44:48.570 We actually have a couple trailer brake controllers turned upside down, and we've connected Nerf dart firing cactuses to the exhaust ports on the bottom, and we're running pressurized air on them so that if you can figure out how to do a valve test or do an ECU reset on one of these things, 44:48.570 --> 44:53.010 it should push air through that exhaust port, and you should fire those Nerf darts. 44:53.090 --> 44:59.610 And they're connected up on the Virtual Car Hacking Builder system, so there's a Twitch stream and remote logins to the shells. 44:59.910 --> 45:07.990 We do hope that you log in and have a try, and maybe if you get familiar with them, have a try at that Wi-Fi trailer unit. 45:07.990 --> 45:10.030 I know I'd like to someday, too. 45:12.390 --> 45:27.150 What we did here was, you know, not the result of just Chris and I's effort, but really the result of a lot of people committing a lot of resources and assistance over the past few months, and I really want to take an opportunity to put all their names up here and thank them. 45:27.690 --> 45:36.010 Really, this wouldn't be possible without, you know, support of a team and a community, and I feel really lucky to be a part of both. 45:36.010 --> 45:38.370 So thank you very much for your time. 45:38.670 --> 45:46.430 I'll be over in chat with Chris, hopefully answering any questions you have, and I'll see you at the Virtual Car Hacking Village later. 45:46.430 --> 45:47.270 Bye!