[Bro] BRO and CANBUS Protocols

[Ludwig Goon]

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.

On Sat, Aug 11, 2018 at 14:05 Clark Gaylord <cgaylord at vt.edu> wrote:

> 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
>
> On Sat, Aug 11, 2018, 11:55 Ludwig Goon <lagoon7 at gmail.com> wrote:
>
>> 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?
>>
>> On Fri, Aug 10, 2018 at 6:33 PM, Johanna Amann <johanna at icir.org> wrote:
>>
>>> 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
>>>
>>
>> _______________________________________________
>> Bro mailing list
>> bro at bro-ids.org
>> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/bro
>
> --
>
> --
> Clark Gaylord
> cgaylord at vt.edu
> ... Autocorrect may have improved this message ...
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/bro/attachments/20180811/fc3f0bb4/attachment-0001.html