Does anyone have any experience with CANBUS protocol specifically using the J1939 standards? Is this something that BRO can process?
Hi,
Does anyone have any experience with CANBUS protocol specifically using the
J1939 standards? Is this something that BRO can process?
from what I can tell, J1939 is not an IP-based protocol - Bro is currently
limited to IP communication.
Note that this is not really an inherent design problem of Bro - it is
just that no one implemented that yet.
In case I am wrong and this is somehow layered over IP - we also sadly
don't have any analyzers for that.
Johanna
Thanks Johanna,
I do see that the protocol does have some affiliation with the OSI model. I will keep researching as well.
How difficult is it to create an analyzer? Is it possible to use some of the baselevel frameworks?
I’m curious what you would do with a bro canbus analyzer.
I expect Ludwig probably knows all this, but in the interest of our discussion, I’ll give a short intro to CAN, since I suspect view of us straddle their respective worlds as I do. Apologies for any errors or if it’s too basic.
From our IP-centric perspective, CAN can be thought of as a coupling of ethernet and udp, specifying what we would see analogously as phy, link, MAC, and udp. (My description is intentionally without referring to the J1939 terms and should be thought of by analogy.) It is the dominant communication network in the vast majority of automobiles and trucks, though it can be thought of more generally an “assembly line” or instrumentation network. It is very different from, though performs a somewhat similar function to, modbus, which is a TCP based instrumentation protocol, and is an abomination.
CAN has a MAC type layer and header that includes a “message type” or message ID. This id field doubles as a priority, used to arbitrate collisions (lower message wins), and determines how to decode the payload. Payload is 0 to 8 bytes. You can think of CAN packets as TLV messages. It is common to have multiple instruments multiplexed into the payload, decoded based on the data spec (for example, maybe a GPS message will encode lat and lon at different bit offsets in the same message). In our (VTTI) business, where we are interested in the time series of the various instruments’ values, we demultiplex the various instruments; oddly enough, we call this “demuxing”. 
So, in the example, we pull out lat and lon as two separate “fields” that we might sniff off the Can and store as distinct “variables” (yes in the case of lat+lon it would actually be more convenient to keep them together, but it is more general this way).
There is very little standardization of the data, indeed in the automotive industry the manufacturers are extremely protective of these data standards (arguably in part because they would be so mortally embarrassed if anyone knew how bad these standards were.) J1939 often refers to the more standard subset of messages used on commercial vehicles; these are required on trucks and motor coaches and in my experience universally unimplemented on passenger vehicles. There are a (tiny) handful of CAN messages related to emissions that are implemented on all vehicles in the US.
Most of my engineer colleagues who live inside CAN use canalyzer or some other CAN-specific tool (or the C++ code we use in-house for data acquisition). There is a mythical “libpcan” that can theoretically be used to create pcap compatible data that can be consumed by tcpdump, Wireshark, and friends, but when I last tried to build it I could not get it into a usable state. This would be widely regarded as a valuable contribution to the community.
So, yes as Johanna notes, bro could potentially be adapted, but I would suggest chasing it down from the “pcan” perspective. Putting J1939 decodes on top of that would be a good thing, but I would suggest you build a modular decode system where you could provide other message decode capability, so, for example, a given OEM’s data (or subset) could be decoded.
Back to the bigger question, though, I find the notion intriguing but I’m curious what you’re thinking in terms of what you’d like the application to accomplish, etc.
Regards
Clark
My interest primarily is to determine if an automotive intrusion detection system is possible and if Bro can be used in some development capacity.
In addition bro is probably implemented in embedded systems so I think there should be a link there as well.