[Guy Harris <gharris@xxxxxxxxx>]

Bhatia, Deepak wrote:

> A key component of the is the Protocol Sequence Replayer (PSR).

A key component of what?  (The CITI paper you sent just describes 
extending a 1993-vintage version of the Network General Sniffer 
software, and AIX's "iptrace", to decode DCE RPC-based protocols; it 
doesn't say anything about replaying traces, much less replaying 
operation sequences, so, for what you're describing, you need to do a 
*LOT* more than what that paper describes.)

> The first task requires the ability to decode all protocol fields in
> the various packet types used in the DCE RPC protocol.

Ethereal can do that for fields in DCE RPC itself (at least to the 
extent that it's publicly specified, which it is for DCE RPC 1.1, 
although particular authentication flavors might not be documented)...

> This implies reverse-engineering these fields for protocols that are
> not fully or adequately documented.

...but it can only do that for fields in protocols that *use* DCE RPC if 
they're documented or reverse-engineered.

> Typically, these are the protocols that are embedded in widely used
> software, such as the various versions of the Windows operating system,
> the various versions of the Linux operating system, Oracle database software etc.

What not-fully-documented DCE RPC protocols are used in Oracle?  (The 
only ones I know of in Linux are those used by Samba, which are the 
Windows protocols.)

In any case, Ethereal knows nothing about replaying packet sequences. 
You could perhaps use Ethereal's dissectors to analyze DCE RPC-based 
protocols (if they're documented or reverse-engineered), but you'd have 
to write your own code either to modify those packets or to generate 
your own packets, and to send them - Ethereal contains no code 
whatsoever to help with that.

> The second task requires understanding which fields in the protocol
> are Dynamic Session Variables. A dynamic session variable is a field
> whose value may change in multiple identical runs of the same
> protocol sequence. Examples of dynamic session variables include the
> dynamically assigned TCP port for FTP data channels, session or
> transaction IDs in RPC or database protocols, dynamically assigned
> ports in RPC protocols, etc. Once a set of DSVs have been identified
> for a protocol, the plug-in needs to be able to dynamically
> substitute these values from recorded traces into the packets that
> are sent for replay based on the requirements of the protocol.

Ethereal - and its dissectors - contain no code whatsoever to do any of 
that, nor does it have a framework for doing any of that.  You would 
have to implement all of that yourself.

BTW, FTP is not a DCE RPC-based protocol; does this question really have 
anything to do with DCE RPC in particular, or is this really a question 
about Etheral dissectors as a whole?  Even if it does, the same answers 
apply.