Car Hacking Village - Before J1939
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 374 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/51653 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Asynchronous Transfer ModeInformation securitySystem programmingComputing platformComputer hardwareCommunications protocolParsingMultiplication signPresentation of a groupAsynchronous Transfer ModeInterprozesskommunikationMathematicsHacker (term)Component-based software engineeringParsing
00:44
Standard deviationMessage passingParameter (computer programming)File formatLink (knot theory)Serial portComputer networkAsynchronous Transfer ModeAuthenticationConfiguration spaceAbsolute valueDevice driverInformationFunction (mathematics)SoftwareNetwork socketoutputASCIIDatabaseComputer fileSoftware testingInterprozesskommunikationCommunications protocolMessage passingSoftwareFunction (mathematics)Absolute valueBitPrincipal ideal domainPressureImage resolutionRange (statistics)File formatMIDIField (computer science)Sheaf (mathematics)PhysicalismConfiguration spaceExecution unitParametrische ErregungExtension (kinesiology)Computer programComputing platformCartesian coordinate systemSerial portDevice driverInterface (computing)Real numberoutputArithmetic meanStandard deviationForm (programming)Computer configurationProjective planeRepository (publishing)Arithmetic progressionSharewareComputer filePoint (geometry)Electronic program guideSampling (statistics)Default (computer science)Exploratory data analysisBus (computing)Parameter (computer programming)Latent heatCumulative distribution functionFlagMereologyError messageGame controllerDecimalIntegerCanonical ensembleElectronic mailing listLink (knot theory)Probability density functionQuicksortMoment (mathematics)Integrated development environmentUniform resource locatorSoftware repositoryProper mapCategory of beingInformationPhysical systemString (computer science)DatabaseFuzzy logicOrder (biology)Codierung <Programmierung>Information securityReverse engineeringType theoryDifferent (Kate Ryan album)Table (information)Charge carrierCodeNumberMaxima and minimaContent (media)SummierbarkeitElectric power transmissionComputer hardwareSoftware maintenanceComputer engineering2 (number)Wave functionMultiplication signRotationDataflowStandard errorIdentifiabilityRegulärer Ausdruck <Textverarbeitung>Presentation of a groupRing (mathematics)Assembly languageLengthUtility softwareMedical imagingParsingStreaming mediaReading (process)AnalogyProof theoryDigitizingBoss CorporationArmCASE <Informatik>First-person shooterTraffic reportingFilm editingPhysical lawOvalWebsiteTrailMetropolitan area networkEndliche ModelltheorieProcess (computing)Noise (electronics)Thomas BayesSelf-organizationObject (grammar)View (database)Daylight saving timeData structureDirection (geometry)Moving averageControl systemParsingStress (mechanics)Group actionNetwork topologyFigurate numberMusical ensembleMixed realityRight angleFrequencyFreewareOnline helpTerm (mathematics)Shared memoryGame theoryMathematics40 (number)Intrusion detection systemMobile WebWordComputer animation
Transcript: English(auto-generated)
00:03
Hi everyone, today I'd like to welcome you guys to Car Hacking Village of DEFCON 2020, Safe Mode. Today's presentation is going to be a throwback to the times before J1939. If you don't know what that is, that is a protocol that runs on top of CAM
00:25
and is primarily used in heavy vehicle component communications. So we will be talking about how we came about the creation of a decoder slash parser for J1708 and J1587.
00:46
So just a quick breakdown of how this presentation is going to pan out. First, we will let you know who we are. We're going to let you know how this project came about. And then we're going to give a brief recap of the protocols that are interesting to us.
01:06
And you will then see how we came across these protocols. Afterward, we're going to talk about the decoder slash parser and we'll give you a quick demo. Last, we'll conclude this talk with the info you'll need to pick up where we are leaving off.
01:29
Okay, so my name is Daniel Saloum. I'm a reverse engineer at Assured Information Security. We're based out of Rome, New York. I've been with them for a little over a year and a half at this point.
01:45
And I spend my days analyzing the security of things, digging into protocols, and developing anything to support these efforts. You can see in the images, I'm on the right-hand side,
02:01
and there's an image of Thomas on the left-hand side. So now you have proof that we actually work. Yeah, hi. So my name is Thomas Hayes. I'm a hardware engineer at Bendex Commercial Vehicle Systems based out of Illyria, Ohio. I spend most of my days designing hardware, so PCBs and digital and analog interfaces for brake control systems.
02:28
And I've been there for almost five years now. Okay, so what are we doing here? Well, we discovered that there are more than just J1939 messages
02:45
that cross the networks in heavy trucks. And within this traffic, there's some very interesting data. So we're here to show you how it came about as we needed a simple way to see it.
03:01
And I can imagine you guys want to see how the decoder works as well. So is there a backstory? We know trucks, I've been playing them for a while. This project started off in mid-2019 when we started to do some exploratory testing on heavy vehicle systems.
03:23
We noticed multiple networks and the interconnection between all of these modules. We started to explore some tools and decoders that are already out there, available for use for people in industry. And these legacy protocols of J1708 and J1587 are still being sent across the bus,
03:43
even though now J1939 is much more prevalent in newer vehicles. And it looks like it could be very interesting as it is a very important bus that happens on the vehicle with a lot of useful information that we were interested in looking at.
04:04
Okay, so how do we, I'm sorry, what do we need in order to get things rolling? First is an understanding of the protocols involved. In this case, we mentioned J1708 and J1587.
04:22
They kind of work together. We also need a hassle-free way of analyzing the traffic that we see. And at that point, we can decide what may or may not be done with this data. So what are J1708 and J1587?
04:43
So they are SAE, the Society for Automotive Engineers, standards for medium and heavy-duty vehicles post-1985. J1708 describes the physical layer and data links layer and defines a bidirectional serial vehicle network. J1708 defines how the messages are structured and how they're distributed over the network.
05:02
And J1587 makes up a transport application layer and describes messages format and parameters. So that's almost a big dictionary for all the possible messages that can be sent over this communication protocol. So J1708 is almost always used in conjunction with the application layer protocol, J1587.
05:22
It's based on an RS-45 bus. We can have a max of 20 nodes on a vehicle and it runs at 9600 baud. One message contains a one-byte-long MID, a message identifier, followed by some data related to that MID and a one-byte checksum.
05:41
The message can be up to 21 bytes long. However, if the vehicle is stopped and no movement is detected, the messages can be longer if required. So J1708 MIDs, we go up to 0 to 127, defined by J1708.
06:01
And these are defined by SAE for important vehicle systems. And then from 128 to 255 are defined by J1587. And these are used a little bit more for maintenance and information on the vehicle, more from a diagnostic side. It's very cool. The MIDs also serve as an arbitration method for the communication.
06:22
So the lower your MID number is, so let's say 0 to 7 for engine, that means it's a very high important message and will be passed before perhaps the trip recorder message when MID 56 and 61. The checksum is quite simple. It's a two's complement of the sum of the message and the data content is defined by the application document given by the supplier.
06:43
So you can send the messages defined by SAE or possibly something, something defined by you as a manufacturer if you need to send something specific or proprietary across the bus. So J1587 defines the PID, the parameter identifier.
07:04
So that's a little bit of a complement to the MID. So if you have an MID for the engine, a PID can be related to your engine oil or a NOx sensor or something in your camshaft. So it's a little bit more information for the PID for the system to recognize if there's a fault and direct where that fault can be.
07:26
So it consists of one MID, one or more PIDs and a checksum. The data length of 1587 message is mostly limited to 21 bytes according to J1708. And if a message needs to be longer than 21 bytes, we can use the C-C-O-T-S, the TP4.
07:46
So that can be used to segment and reassemble large messages if needed. And a lot of the PIDs are standard. So the PIDs range from zero to four bytes and the unit's resolution range will be defined in the spec or by whoever is sending them out.
08:03
So if you're one engine manufacturer could say the PID for oil pressure is one PSI per bit or another one could say it's five. So it just depends on the manufacturer for that PID. There's also SIDs. These are related to the MID, but these are more related to anything that can be used
08:22
to identify a section that is not necessarily covered under a PID, but covered under a diagnostic MID. So the MIDs for using SIDs will begin at 128 as defined by 1587. And these are really used for something that can be troubleshooted or replaced by a field technician if needed.
08:46
So what's in the data? Now, a lot of our testing was in the communication between trucks and trailers. So the trailer has an ABS ECU and the trailer also has an ABS ECU and those two will talk to each other using this protocol.
09:02
The trailer ABS can have all kinds of diagnostic message. A truck test is a test of the system. It will modulate the air solenoids a little bit and dispense a bit of air. When you hear a truck break, you hear a large air release sound and that's kind of just making sure that your system's working properly. You can restart the ECU.
09:21
You can check the status of the ECU and most importantly, demonstrate an ABS fault. So as per SAE standard, the ABS fault, if the trailer has an issue, the trailer ECU has to communicate to the truck ECU and illuminate a light on the dash as well as a light on the trailer itself, indicating that there is an issue with the ABS and it needs to be resolved.
09:47
Diving a little bit deeper, there's also configuration options on the ECU. So wheel size, which then relate to the speed of the vehicle, as there's a tone ring that counts the amount of rotations done. And driver info, so where the trailer is going and what truck it is connected to at the lot.
10:05
And sensor data. So it's the speed, mileage, your odometer stored on the ABS, trailer ABS, location, temperature, and many proprietary vendor messages. So who uses J1708 and 1587? So any kind of heavy vehicles that we all know, but also school buses follow that same platform, military vehicles.
10:24
And we even found that yachts will be using the same communication platform. So our use case, we were observing exchanges with a tractor and a trailer. They said the brake controls communicate over J1708 and J1587. And these messages actually pass over a power line, which is very cool.
10:42
Trailer manufacturers did not want to add another wire or two needed for an ABS communication. So they superimpose a sinusoidal wave on the power line going from the trailer, which then gets filtered out on the trailer side and on the truck side, depending if it's using that communication. It's very cool, but Dan and I did not focus our time on this.
11:03
We were working on the J1708 and J1587 protocol. Okay, so the question comes up now, how do we look at these messages? There's a couple of options. We can use tools that were developed for J1939 and are backward compatible with the other two protocols we mentioned.
11:30
Or we can get our hands on an RS-485 transceiver, some bubble gum, a paperclip, maybe a tinfoil hat, and see what we can hack up.
11:41
But what happens when our bus is a power line? In this case, you need a specialty diagnostic tool. Some of the larger companies like Nexic, Haldex, Digitech, they provide these. But the problem with this approach is it's going to cost you some moolah. And flow between programs is not really there, as software is kind of tied with the hardware and it's all proprietary.
12:08
Which means minimal flexibility. So our solution is pretty J1587. This is a decoder that helps with at least part of the problem.
12:25
By default, this takes in hexadecimal bytes, which are comma delimited, but really it can take in a stream of any bytes. And a user can define how to manipulate that data to be parsed correctly by the decoder.
12:45
It also supports reading from standard in files or sockets, UDP or TCP. And what it does is it takes this information, these messages, and it will break them down into a human tolerable format.
13:03
So they can be easily analyzed by an end user. So to start off, what happens is the parser will read the SAE documentation PDFs.
13:20
Okay, and it will do this to set up a primary database, which is used for interpreting the data that's coming in. And this is needed because there's no simple database holding the data that we need in a convenient format. Okay, it's all in the specifications or proprietary by vendors.
13:43
So there is an option for an end user to create custom messages with this tool. And this will be handy for working with proprietary data. The benefit of this, using this tool, is that it can be piped from or to other programs, as it's just a command line utility.
14:08
So there are some requirements. What do we need to get this off the ground? Well, the first part is on you guys. You're going to need an interface to some bus to get the traffic.
14:20
The next part is, it uses the program PDF2Text, which is contained within the popular udos package standard on most Linux distributions. Okay, and what happens with this is we use this tool to convert the SAE portable document format specifications into formatted text files.
14:49
Okay, then you need Python 2. We are hoping to port this to Python 3, but it started as a spaghetti code project that we just needed up and running, and Python 2 was default here, and that's what we stuck with until now when we realized it's actually useful.
15:09
There's still some minor issues with it. The spec obviously was not written with being parsed in mind. Okay, so there's a lot of regular expressions and things that parse this information out of these files.
15:28
Okay, so I think at this point I'm going to give you guys a quick demo about how this thing works. It's a repository which will be made public after this talk, and you can just clone it,
15:46
and at that point you will set up the configuration file to point at the text files that you've created from using PDF2Text on the SAE J1587 and 1708 specifications.
16:02
Okay, so the first thing that I'll mention is this repository, within it we have a tool called Fuzzy Messages, which I'll be using for the demo. Alright, this program just creates random bytes, I believe 1 to 19 bytes in length,
16:21
and this winds up working out as a nice test environment to create a robust program. That way it's not just failing on any sort of messages, as you might see when running different types of hardware, you'll get funky bytes that aren't actually part of the message at times.
16:43
So we've decided to make this program a little bit robust, and that it won't just error out on an incorrect message. It might print a warning to standard out, and it'll keep chugging. Okay, so the first thing I'm going to do is I'm going to create a file with, let's say 100 messages,
17:08
and I'm going to write that to temp. Okay, let me just make sure that that worked. Yep, seems like I got messages in there. Alright, so now to run the tool, I just point it at that file that I created with all the messages.
17:28
I'm also going to give it a flag to print delimiters between the messages. So you can see when there are errors, it gets printed to standard error.
17:42
So these could be piped to dev null if you're not interested. But you can also see here the original message, MID in hexadecimal, and these also are accompanied by decimal forms. And then the PIDs and the meanings of the PIDs along with the accompanying bytes.
18:02
Okay, so that's pretty good, but if you want more information, you can give this program a little bit more verbosity, like so, and you'll get details. This is the same message here that we saw previously, but now you can see it's giving details about the individual bytes related to a PID.
18:27
So here we can see there's one byte, and this has to do with the extended range parametric pressure. Okay, and here are the units right here. I just want to mention one thing. We are using random bytes for this data.
18:41
So this MID says idle adjust system, and it's not necessarily, in a real world scenario, this PID is probably not going to be matched with this MID. Okay, but we don't error out, we just want to parse the data as it comes.
19:03
There's a couple of other options I wanted to mention. So some people prefer JSON. We added a flag for JSON. I will disable the output that you just saw, which can be easily grepped, and I will print these messages in JSON format,
19:23
and I'm also going to pipe the standard out to dev null. Okay, so you can see in here, same messages, but these are output as JSON formatted messages.
19:40
This could be convenient if you use the JQ tool, and you want to filter these messages the way you'd wish. But there's another option for you, and that is, we have a whitelist here. So, what we can do is specify specific PIDs,
20:02
like if we are interested in certain PIDs within a message, and we only want to print those messages, we use the whitelist option. So I will just grab one from here, and let it roll. So you can see it printed out one message with that PID, 48.
20:25
And that is in, actually, decimal form for that. Okay, so there's a couple other things that this can do. If you just give it the dash H, if you use some help,
20:41
one of the options is for a custom database. Now this means if you want to define your own messages, and overwrite those that are provided by the spec, or let's say you're working with some proprietary messages,
21:01
and you have a good idea what it means, you can define that. We provide a sample file in the repo, and you can see here that, basically, this is the format. It's just JSON, and you just give it your definitions. You can use this file as a guide.
21:21
Okay, there are still some issues. There are a few PIDs that are a little bit more tricky to work with, and those might not have their individual byte definitions over it, but it's a work in progress there. I wanted to mention that, okay, if you want to read from standard input,
21:46
the way that you do it is you just pipe hexadecimal delimited bytes, as I mentioned, to this, and you will use this usual format for reading from standard input, okay?
22:04
I'll also use the packet delimiters here, and you can see what the meaning is. But one of my colleagues came to me and he said, well, you know what? We have an issue because the output that I'm getting from my program
22:21
is not set up like that. It doesn't have the comma delimited values. It's all just a string of hexadecimal bytes. So what we did was we added the option here. If you look in this file called cannon functions, an end user can define a function to be called on the command line
22:43
that will manipulate this format, and the only requirement is that the output would be a Python list of bytes, okay, or a Python list of integers. So in this case, we can use the dash J option
23:02
and say cannon no delims, I believe I called it, and you can see that it will just parse the message in that format, okay, so it doesn't really matter. All you need to do is know what your input looks like and figure out how to get that into a Python list of integers.
23:26
Let me see if there's anything else I wanted to mention. I think that's it for now. I'll let you guys play with the rest of those options as you see fit.
23:41
So, getting back, what are the benefits of using this decoder? Well, there's no real software investment other than getting your hands on the SAE specs, okay? I'm sorry we can't just provide them for free,
24:02
but SAE would not be happy with this, and they take the intellectual property very seriously, so I'm sorry about that. You can handle it though, I'm sure. The other benefit is that you can work with anything that outputs 1708-1587 messages.
24:25
So where can you get it? If you want to get your hands on this tool, you'll go to this URL. After the talk, we will make this a public repo. We're rolling with an MIT license, so don't forget where it came from,
24:40
and feel free to make money on it. But remember that there are a few dependencies, so you need the specs, you need PDF Detect's tool, and Python 2 at the moment. We wanted to give a special thank you to NMFTA for giving us the opportunity to do this work,
25:02
and our friendly motor freight carriers for allowing us to play with their trucks. Also, the Hilton Executive Lounge for hosting a nice, hacktacular atmosphere by letting this group meet and set up mobile test benches. We only left a few solder burns
25:21
under nice wood grain tables. We just want to thank you for joining us, and enjoy the rest of your DEFCON Talks.