Wireshark-dev: Re: [Wireshark-dev] [RFC] Vendor-specific dissector extension for EtherNet/IP

From: Samuel GROOT <groot.samuel@xxxxxxxxx>
Date: Thu, 31 Aug 2017 14:58:11 +0200
Hi,

I was already looking at CCO and the heuristic function when I received your last email. After some reading of the C dissector and some tests I arrived at the same conclusions, I will see now what I will implement, and how.

In the CIP specs, they focus on <identifier> being an object class and instance, but for some Rockwell PLCs, the <identifier> is just a string (and there is no class in the message).
That's what I mean when I refer to "classless" requests.

I never encountered this case but indeed this notion of segment is present in the CIP documentation, I didn't read it enough!

 >> 2. If you want to add vendor specific services to already supported
 >> objects, that would be more difficult to do in Lua because there isn't a
 >> dissector table hook for them.  I'm not sure there would be a way to
 >> handle the "general" case of registering service + class into a
 >> dissector table, but you could add dissector tables (patching
 >> packet-cip.c) for specific objects (Identity, ConnectionManager, etc)
>> and submit just that part as a patch for inclusion in base Wireshark code. This is where I started to steer you incorrectly.  The heuristic functionality should
be able to handle this case without issue.

I think in this case it would be the dissector, since the heuristic only triggers for common services (and we want to support vendor-specific services for common objects).

I think the intent of the cip.data_segment.iface dissector table was to handle the "string" identifiers I mentioned with the Rockwell PLCs.  It's probably something that should actually
be removed from the dissector.

It makes sense. Why remove it though, since it can be used to support "classless" services?

 >> 4. I believe Lua will "override" any value registered to a dissector
 >> table, so you could write the "vendor specific" portion, for say the
 >> Identity object, but then you'd have to duplicate all of the dissection
 >> currently being done for it in your Lua script.
> I did test with setting a lua dissector for Identity in the cip.class.iface, and on packets > with common services it wasn't triggered (I didn't have packets with vendor-specific > services call for Identity).  So apparently it does not override the default dissector
 > with the lua one (at least with a common service).
Again, this issue can be handled with the heuristic dissection mentioned above.

True in this case.


So to clarify I could now cover the following cases:
- Vendor-specific class, vendor-specific services with a dissector (one per class) - Vendor-specific class, common services with a heuristic (to handle the epath and attributes) - Common class, vendor-specific services with a dissector (again, one per class)

An implementation in lua seems extremely tedious, since I will have to re-write most of the dissection code already present in C (status, epath, and attribute-related services).