Wireshark · Ethereal-dev: [Ethereal-dev] UNKUUID in DCE RPC dissector side-effect with Windows UUID resolution

[Jean-Baptiste Marchand <Jean-Baptiste.Marchand@xxxxxx>]

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/