Hello,
I've just tried the Windows-only feature of UUID name resolution using
the Windows registry in the dcerpc dissector.
However, there is a small side-effect with the UNKUUID string displayed
in the info column when a DCERPC request packet is seen for an
unsupported interface:
- UUID is resolved in Bind or Alter_context PDUs, using the Windows
registry on Windows systems.
- As we do not dissect ORPC, subsequents request are displayed with
UNKUUID.
Small example (tethereal output):
46 DCERPC Alter_context: call_id: 5 [IWbemServices] UUID: 9556dc99-828c-11cf-a37e-00aa003240c7 ver 0.0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
48 DCERPC Alter_context_resp: call_id: 5 accept max_xmit: 5840 max_recv: 5840
49 DCERPC Request: call_id: 5 opnum: 20 ctx_id: 3 UNKUUID: 9556dc99-828c-11cf-a37e-00aa003240c7 rpcver: 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
50 DCERPC Response: call_id: 5 ctx_id: 3 UNKUUID: 9556dc99-828c-11cf-a37e-00aa003240c7 rpcver: 0
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not really important, just a bit surprising to see one UUID
correctly identified at the Bind/Alter_context level and then later
displayed as UNKUUID.
We might want to try to resolve UUID also in request/response PDUs,
using the same mechanism as the one used in bind/alter_context PDUs, no
?
I know that the point of UNKUUID is to highlight that we don't have a
dissector for a specific interface. However, in that case, the Protocol
column is already set to DCERPC.
What do you think?
Jean-Baptiste Marchand
--
Jean-Baptiste.Marchand@xxxxxx
HSC - http://www.hsc.fr/