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