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).
