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 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:
https://mypeek.wildpackets.com/documentation/index.php
Chris
Bloom
Customer Solutions
Expert
WildPackets,
Inc.
925-274-5443
Leave a comment