Firestorm is extensible through a series of plugins. A developer can write their own plugins to implement new functionality in the system. Each plugin is implemented as a shared library (DSO). Any given plugin can implement zero or more of any of the 6 types of pluggable objects:
capdev: A capture device (or capdev) provides the main I/O loop for packet retrieval within the firestorm NIDS sensor. Examples of capdevs are pcap which reads packets from the network using libpcap or tcpdump which reads packets from a tcpdump saved capture file.
decoder: Protocol decoders are responsible for demultiplexing a specific protocol. The decoder plugin is also responsible for coordinating rule tree construction, any state tracking or message reassembly that may be required and the (de-)serialization of state information to and from elog files. Examples of decoders are ip, tcp and http.
preprocessor: Preprocessors provide a way for a plugin to hook in to all packets containing a given protocol in order to implement new detection routines. The preprocessor infrastructure is such that it can be utilized for almost any new sensor functionality such as statistics gathering or performance monitoring.
matcher: A matcher provides a criteria by which one can construct a rule. An example of a matcher would be ip_src, http_method, and itype which match IP source address, HTTP method, and ICMP type respectively.
target: A target converts firestorms internal representation of a packet in to some other format. Examples of targets are ascii, and dump which convert in to an ascii log file format and the libpcap tcpdump format respectively.
parser: A parser reads in signatures in some format or other and convert the information in to firestorms internal format. The only parser currently available reads snort rulesets.
Firestorm is currently in development and as such the ABI is not fully documented and defined. This means that the ABI will change from version to version and a plugin is only guaranteed to work with the the version of firestorm it was compiled against.
Firestorm plugins will usually fall under the GPL derived works clause meaning that any plugins you distribute should fall under the licensing terms of the GPL. However this may not always be the case and if you are planning on releasing non-GPL plugins you should get legal advice.
Any code which aims for inclusion with the official Firestorm release must roughly adhere to the Firestorm coding style. Firestorm code is always written in C and follows the K&R / Torvalds coding conventions. This is codified in Documentation/CodingStyle in the Linux source code package. If in doubt just follow the coding style of the code you are modifying.
If you wish to submit code for inclusion with the official Firestorm release you should make a patch of your tree against the latest point release. The patch should be made to be applied with GNU patch with the -p1 option. The patch should be posted to the mailing list. MIME is OK, but no compression. If the patch is sufficiently large upload to a website and just post the URL. Code must be GPL licensed and patent unencumbered in the UK. No copyright assignment is necessary.