Thanks for the info!
OK, this will be A LOT of work.
I thought, that the UUID binding info must be handled by the DCOM dissector,
but I agree to you. I will have a look at the sunrpc, how they do this job.
It will also be necessary to keep the Call and Context ID between Request
and Response in mind, as this is at least in DCOM needed to handle the Response
data.
A basic IDL info in the first step could be hold in a static data struct
inside the dissector.
Do you know, if the .idl syntax for the DCE-RPC and DCOM are identical? If
not, do you have an example DCE-RPC idl file (just for my information at this
devel stage)?
Do you have some further information about the DCE-RPC protocol?
Is the "handoff stage" on your to-do list, or are you already working on it?
ULFL
> ulf.lamping@xxxxxx writes:
>
> > Hi!
> >
> > I think, it could base upon the DCE-RPC dissector, already running quite
> > good.
> >
>
> There's still a fair bit to be done with the base dce-rpc dissector
> before trying to handle DCOM would be feasible. It needs to keep
> track of conversations and bindings to UUIDs, and then have a handoff
> table based on the interface UUID, similar to the way the sunrpc
> dissector works.
>
> Once that's done, then something like the idl2eth for GIOP could, in
> theory, be written for dce-rpc .idl files, and possibly DCOM .idls,
> too. That'd be ideal, but is probably quite a ways off.
>
> Another big improvement would be getting the SMB dissector to handoff
> the appropriate stuff to packet-dcerpc.
>
> The first step above (getting to the handoff stage) is on my to-do
> list, but feel free to pitch in. :)
>
>
> Todd
>
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
GMX Tipp:
Machen Sie Ihr Hobby zu Geld bei unserem Partner 1&1!
http://profiseller.de/info/index.php3?ac=OM.PS.PS003K00596T0409a
