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.
