Decoders and Protospecs: A Tale of Two Islands

Protospecs are written in XML and executed for
each packet when the packet is either captured or loaded from a file.
All of the Protospecs are in the pspecs.xml file. This file is shipped
with the product and can be extended with new protocols by the user as
well as other third parties.This a story about the marriage of Protospecs and Decoders. It is a love story that begins as a tragedy and ends in harmonial bliss.  The tragedy is that Protospecs and Decoders are separate subsystems that should be able to leverage each other, but until recently could not.  The harmonial bliss is a way to write Decoders as a C Plug-in that can use Protospecs.

The result of the protospecs is the name of the
highest known protocol layer and a unique ID that represents it.
Protospecs are very fast. Internally, protospecs are represented as a
highly optimized binary tree. From the user point of view, the
Protospec is the protocol name displayed in the Protocol Column of the
Packet List as well as the names of the protocols in the Protocols Tab. The protospec id for a packet is also used by virtually every other feature of the program.   This is important, because it means that modifications and extensions made to protospecs are highly leveraged.

Decoders are written in a specialized language that
is appropriately called The Decoder Language. It is a hybrid language,
a melting pot if you will, consisting of legacy syntax resembling 68000
assembler as well as newer syntax that looks a lot like C++. Decoders
are found in the decodes folder and are separated into files called
.dcd files. When OmniPeek is run, all of the dcd files in the decode
directory are loaded and compiled into binary form. Decoders are fast,
but they are still interpreted and thus are slower than machine code.

From the user point of view, the decoder is the
detailed break down of a packet in the Decode View of the Packets Tab
as well as the Decode Column of the Packet List.  The two technologies, Protospecs and Decoders,
provide similar but different functions and thus many moons ago were
implemented as completely different libraries without any connection or
integration between the two. And that, my friends, is where our story
of a tale of two islands begins.

For millennia, in fly years anyway, man has
searched for magic to use the great knowledge of the protospecs from
the decoders.  It is believed by many wise men that if one
knows the protospec of a packet while in a decoder, less work has to be
exerted by the decoder programmer to write the decode. And of course
doing less work is the holy grail of the programmer, making this an
honorable and worthwhile journey. However, this quest has been made
many times and has always ended in frustration, futility, and
ultimately failure. Years have passed since the journey has been made.

But today we enter a new era, a Decoder
Renaissance. Today, thanks to a premium developer support customer, a
phone call for developer support was made and in the process a
realization formed that there is a place in the universe where decoders
and protospecs can meet. This place is the C Decoder Plugin where the
decoder programmer has access to both the decoder functions and the
packet, which includes the almighty powerful protospec id. It is in
this special place, the “Protocoder”, that the protospec id can be used
to make important decisions about the decode without having to rewrite
logic that the protospec library has already executed.

As the story goes, the customer had extended the
pspecs.xml file to include a number of new application layer protocols.
Their protocol types are figured out by looking at the IP address, not
the protocol type. This is odd, but true, and they have their reasons.
So now that they had worked so hard on the protospecs, it was time to
write the decoder.

They were tired, for they had labored long and
hard, and when they begun writing the decoder they did not want to work
so hard again. They also, for other reasons, had decided to write their
decoder as a C Decoder Plugin. And although it was not evident early on
what the advantages would be, it was realized in a moment of great
insight that by writing the decoder in C, the protospec along with
other valuable information about the packet is passed into the C
decoder function.

So believe it or not, that’s how the story goes.
And from that moment on it was realized that this special place in a plug-in where Protospecs and Decoders meet, could be used to
enhance decoders in many other ways. Who knows, maybe those stories
will be passed down through the ages as well.

The End.

*The feature described in this story is available in OmniPeek 4.0.2 and above.

For more information about Protospecs and Decoders, please visit the following URL:



  Customer Solutions



Leave a Reply