summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorErmal Luçi <eri@pfsense.org>2008-08-02 22:24:45 +0000
committerErmal Luçi <eri@pfsense.org>2008-08-02 22:24:45 +0000
commit4ae45b1093b1a2fda98b263a5cffce9689ad109a (patch)
treec770e69156a527cbe1deb11a288dc3315c9423ca
parentb5a7edb1ca42023606cde872cb8b5339d3b9837a (diff)
downloadpfsense-4ae45b1093b1a2fda98b263a5cffce9689ad109a.zip
pfsense-4ae45b1093b1a2fda98b263a5cffce9689ad109a.tar.gz
Add protocol definitions needed by ipfw-classifyd. Basically they are copied from the ipfw-classifyd pfPort which inherits them from l7-filter project on sf.net.
-rw-r--r--usr/local/share/protocols/100bao.pat11
-rw-r--r--usr/local/share/protocols/aim.pat27
-rw-r--r--usr/local/share/protocols/aimwebcontent.pat9
-rw-r--r--usr/local/share/protocols/applejuice.pat11
-rw-r--r--usr/local/share/protocols/ares.pat62
-rw-r--r--usr/local/share/protocols/armagetron.pat11
-rw-r--r--usr/local/share/protocols/battlefield1942.pat13
-rw-r--r--usr/local/share/protocols/battlefield2.pat25
-rw-r--r--usr/local/share/protocols/battlefield2142.pat13
-rw-r--r--usr/local/share/protocols/bgp.pat18
-rw-r--r--usr/local/share/protocols/biff.pat15
-rw-r--r--usr/local/share/protocols/bittorrent.pat27
-rw-r--r--usr/local/share/protocols/chikka.pat16
-rw-r--r--usr/local/share/protocols/cimd.pat18
-rw-r--r--usr/local/share/protocols/ciscovpn.pat10
-rw-r--r--usr/local/share/protocols/citrix.pat11
-rw-r--r--usr/local/share/protocols/counterstrike-source.pat41
-rw-r--r--usr/local/share/protocols/cvs.pat13
-rw-r--r--usr/local/share/protocols/dayofdefeat-source.pat10
-rw-r--r--usr/local/share/protocols/dhcp.pat35
-rw-r--r--usr/local/share/protocols/directconnect.pat13
-rw-r--r--usr/local/share/protocols/dns.pat62
-rw-r--r--usr/local/share/protocols/doom3.pat9
-rw-r--r--usr/local/share/protocols/edonkey.pat36
-rw-r--r--usr/local/share/protocols/fasttrack.pat22
-rw-r--r--usr/local/share/protocols/finger.pat14
-rw-r--r--usr/local/share/protocols/freenet.pat9
-rw-r--r--usr/local/share/protocols/ftp.pat45
-rw-r--r--usr/local/share/protocols/gkrellm.pat12
-rw-r--r--usr/local/share/protocols/gnucleuslan.pat9
-rw-r--r--usr/local/share/protocols/gnutella.pat33
-rw-r--r--usr/local/share/protocols/goboogy.pat12
-rw-r--r--usr/local/share/protocols/gopher.pat24
-rw-r--r--usr/local/share/protocols/h323.pat35
-rw-r--r--usr/local/share/protocols/halflife2-deathmatch.pat9
-rw-r--r--usr/local/share/protocols/hddtemp.pat13
-rw-r--r--usr/local/share/protocols/hotline.pat11
-rw-r--r--usr/local/share/protocols/http-rtsp.pat15
-rw-r--r--usr/local/share/protocols/http.pat27
-rw-r--r--usr/local/share/protocols/ident.pat14
-rw-r--r--usr/local/share/protocols/imap.pat13
-rw-r--r--usr/local/share/protocols/imesh.pat14
-rw-r--r--usr/local/share/protocols/ipp.pat11
-rw-r--r--usr/local/share/protocols/irc.pat19
-rw-r--r--usr/local/share/protocols/jabber.pat23
-rw-r--r--usr/local/share/protocols/kugoo.pat14
-rw-r--r--usr/local/share/protocols/live365.pat14
-rw-r--r--usr/local/share/protocols/liveforspeed.pat12
-rw-r--r--usr/local/share/protocols/lpd.pat17
-rw-r--r--usr/local/share/protocols/mohaa.pat10
-rw-r--r--usr/local/share/protocols/msn-filetransfer.pat29
-rw-r--r--usr/local/share/protocols/msnmessenger.pat27
-rw-r--r--usr/local/share/protocols/mute.pat10
-rw-r--r--usr/local/share/protocols/napster.pat23
-rw-r--r--usr/local/share/protocols/nbns.pat19
-rw-r--r--usr/local/share/protocols/ncp.pat22
-rw-r--r--usr/local/share/protocols/netbios.pat28
-rw-r--r--usr/local/share/protocols/nntp.pat20
-rw-r--r--usr/local/share/protocols/ntp.pat16
-rw-r--r--usr/local/share/protocols/openft.pat12
-rw-r--r--usr/local/share/protocols/pcanywhere.pat11
-rw-r--r--usr/local/share/protocols/poco.pat11
-rw-r--r--usr/local/share/protocols/pop3.pat49
-rw-r--r--usr/local/share/protocols/qq.pat25
-rw-r--r--usr/local/share/protocols/quake-halflife.pat26
-rw-r--r--usr/local/share/protocols/quake1.pat18
-rw-r--r--usr/local/share/protocols/radmin.pat16
-rw-r--r--usr/local/share/protocols/rdp.pat19
-rw-r--r--usr/local/share/protocols/replaytv-ivs.pat10
-rw-r--r--usr/local/share/protocols/rlogin.pat18
-rw-r--r--usr/local/share/protocols/rtp.pat40
-rw-r--r--usr/local/share/protocols/rtsp.pat14
-rw-r--r--usr/local/share/protocols/shoutcast.pat26
-rw-r--r--usr/local/share/protocols/sip.pat18
-rw-r--r--usr/local/share/protocols/skypeout.pat49
-rw-r--r--usr/local/share/protocols/skypetoskype.pat13
-rw-r--r--usr/local/share/protocols/smb.pat18
-rw-r--r--usr/local/share/protocols/smtp.pat39
-rw-r--r--usr/local/share/protocols/snmp.pat18
-rw-r--r--usr/local/share/protocols/socks.pat31
-rw-r--r--usr/local/share/protocols/soribada.pat50
-rw-r--r--usr/local/share/protocols/soulseek.pat16
-rw-r--r--usr/local/share/protocols/ssdp.pat20
-rw-r--r--usr/local/share/protocols/ssh.pat16
-rw-r--r--usr/local/share/protocols/ssl.pat15
-rw-r--r--usr/local/share/protocols/stun.pat45
-rw-r--r--usr/local/share/protocols/subspace.pat20
-rw-r--r--usr/local/share/protocols/subversion.pat12
-rw-r--r--usr/local/share/protocols/teamfortress2.pat10
-rw-r--r--usr/local/share/protocols/teamspeak.pat14
-rw-r--r--usr/local/share/protocols/telnet.pat15
-rw-r--r--usr/local/share/protocols/tesla.pat14
-rw-r--r--usr/local/share/protocols/tftp.pat20
-rw-r--r--usr/local/share/protocols/thecircle.pat11
-rw-r--r--usr/local/share/protocols/tor.pat16
-rw-r--r--usr/local/share/protocols/tsp.pat13
-rw-r--r--usr/local/share/protocols/unknown.pat7
-rw-r--r--usr/local/share/protocols/unset.pat8
-rw-r--r--usr/local/share/protocols/uucp.pat11
-rw-r--r--usr/local/share/protocols/validcertssl.pat24
-rw-r--r--usr/local/share/protocols/ventrilo.pat17
-rw-r--r--usr/local/share/protocols/vnc.pat22
-rw-r--r--usr/local/share/protocols/whois.pat13
-rw-r--r--usr/local/share/protocols/worldofwarcraft.pat65
-rw-r--r--usr/local/share/protocols/x11.pat22
-rw-r--r--usr/local/share/protocols/xboxlive.pat40
-rw-r--r--usr/local/share/protocols/xunlei.pat14
-rw-r--r--usr/local/share/protocols/yahoo.pat26
-rw-r--r--usr/local/share/protocols/zmaap.pat17
109 files changed, 2235 insertions, 0 deletions
diff --git a/usr/local/share/protocols/100bao.pat b/usr/local/share/protocols/100bao.pat
new file mode 100644
index 0000000..66bb5c9
--- /dev/null
+++ b/usr/local/share/protocols/100bao.pat
@@ -0,0 +1,11 @@
+# 100bao - a Chinese P2P protocol/program - http://www.100bao.com
+# Pattern attributes: ok veryfast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/100Bao
+#
+# Pattern written by www.routerclub.com's wsgtrsys.
+# The author of this pattern says it works, but this is unconfirmed.
+
+100bao
+^\x01\x01\x05\x0a
+
diff --git a/usr/local/share/protocols/aim.pat b/usr/local/share/protocols/aim.pat
new file mode 100644
index 0000000..e26a3c4
--- /dev/null
+++ b/usr/local/share/protocols/aim.pat
@@ -0,0 +1,27 @@
+# AIM - AOL instant messenger (OSCAR and TOC)
+# Pattern attributes: good slow notsofast
+# Protocol groups: chat proprietary
+# Wiki: http://www.protocolinfo.org/wiki/AIM
+#
+# Usually runs on port 5190
+#
+# This may also match ICQ traffic.
+#
+# This pattern has been tested and is believed to work well.
+
+aim
+# See http://gridley.res.carleton.edu/~straitm/final (and various other places)
+# The first bit matches OSCAR signon and data commands, but not sure what
+# \x03\x0b matches, but it works apparently.
+# The next three bits match various parts of the TOC signon process.
+# The third one is the magic number "*", then 0x01 for "signon", then up to four
+# bytes ("up to" because l7-filter strips out nulls) which contain a sequence
+# number (2 bytes) the data length (2 more) and 3 nulls (which don't count),
+# then 0x01 for the version number (not sure if there ever has been another
+# version)
+# The fourth one is a command string, followed by some stuff, then the
+# beginning of the "roasted" password
+
+# This pattern is too slow!
+
+^(\*[\x01\x02].*\x03\x0b|\*\x01.?.?.?.?\x01)|flapon|toc_signon.*0x
diff --git a/usr/local/share/protocols/aimwebcontent.pat b/usr/local/share/protocols/aimwebcontent.pat
new file mode 100644
index 0000000..af34d5b
--- /dev/null
+++ b/usr/local/share/protocols/aimwebcontent.pat
@@ -0,0 +1,9 @@
+# AIM web content - ads/news content downloaded by AOL Instant Messenger
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: chat document_retrieval proprietary
+# Wiki: http://www.protocolinfo.org/wiki/AIM
+#
+# This pattern has been tested and is believed to work well.
+
+aimwebcontent
+user-agent:aim/
diff --git a/usr/local/share/protocols/applejuice.pat b/usr/local/share/protocols/applejuice.pat
new file mode 100644
index 0000000..8158bc6
--- /dev/null
+++ b/usr/local/share/protocols/applejuice.pat
@@ -0,0 +1,11 @@
+# Apple Juice - P2P filesharing - http://www.applejuicenet.de
+# Pattern attributes: great veryfast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/AppleJuice
+#
+# This pattern has been tested with the Linux version (version
+# 0,29,142,229). It matches search reqests and file transfers.
+
+applejuice
+# this pattern extracted from ipp2p, by Eicke Friedrich.
+^ajprot\x0d\x0a
diff --git a/usr/local/share/protocols/ares.pat b/usr/local/share/protocols/ares.pat
new file mode 100644
index 0000000..2e89a90
--- /dev/null
+++ b/usr/local/share/protocols/ares.pat
@@ -0,0 +1,62 @@
+# Ares - P2P filesharing - http://aresgalaxy.sf.net
+# Pattern attributes: good veryfast fast undermatch
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/Ares
+
+# This pattern catches only client-server connect messages. This is
+# sufficient for blocking, but not for shaping, since it doesn't catch
+# the actual file transfers (see below).
+
+# Original pattern by Brandon Enright <bmenrigh at the server known as ucsd.edu>
+
+# This pattern has been tested with Ares 1.8.8.2998.
+
+ares
+# regular expression madness: "[]Z]" means ']' or 'Z'.
+^\x03[]Z].?.?\x05$
+
+# It appears that the general packet format is:
+# - Two byte little endian integer giving the data length
+# - One byte packet type
+# - data
+#
+# Login packets (TCP) have the following format:
+# - \x03\x00 (the length appears to always be 3)
+# - \x5a - The login packet type.
+# The source code suggests that for supernodes \x5d is used instead.
+# - Three more bytes. I don't know the meaning of these, but for me they
+# are always \x06\x06\x05 (in Ares 1.8.8.2998). From the comments in IPP2P,
+# it seems that they are not always exactly that, but seem to always end in
+# \x05.
+#
+# Search packets have the following format:
+# - Two byte little endian integer giving the data length
+# A single two letter word make this \x0a
+# The biggest I could get it was \x4f
+# - Packet type = \x09
+# - One byte document type:
+# - "all" = 00
+# - "audio" = 01
+# - "software" = 03
+# - "video" = 05
+# - "document" = 06
+# - "image" = 07
+# - "other" = 08
+# - \x0f - I don't know what this means, but it is always this for me
+# - Two bytes of unknown meaning that change
+# - Some number search words:
+# - \x14 - I don't know what this means, but it is always this for me
+# - One byte length of the first search word
+# Between 2 and \x14 in my tests with Ares 1.8.8.2998
+# It ignores single letter words and truncates ones longer than \x14
+# - Two bytes of unknown meaning that change
+# - The search word (not null terminated)
+# This was all investigated by searching for strings in "all". Searches
+# can also be performed in "title" and "author". I'm not going to
+# bother to research these because I new realize that searches are done
+# on the same TCP connection as the login packets, so there is no need
+# to match them separately.
+#
+# File transfers appear to be encrypted or at least obfuscated. (The
+# files themselves, at least, are not transmitted in the clear.) I
+# haven't found any patterns.
diff --git a/usr/local/share/protocols/armagetron.pat b/usr/local/share/protocols/armagetron.pat
new file mode 100644
index 0000000..fb4cc1e
--- /dev/null
+++ b/usr/local/share/protocols/armagetron.pat
@@ -0,0 +1,11 @@
+# Armagetron Advanced - open source Tron/snake based multiplayer game
+# Pattern attributes: good slow notsofast
+# Protocol groups: open_source game
+# Wiki: http://protocolinfo.org/wiki/Armagetron
+
+# Contributed to protocolinfo.org, possibly by joda.bot, who says "The
+# filter matches the initial transfer of configuration data. Very early
+# versions might not transfer the CYCLE_ Settings (before 0.2.5.x)."
+
+armagetron
+YCLC_E|CYEL
diff --git a/usr/local/share/protocols/battlefield1942.pat b/usr/local/share/protocols/battlefield1942.pat
new file mode 100644
index 0000000..1a4d9c0
--- /dev/null
+++ b/usr/local/share/protocols/battlefield1942.pat
@@ -0,0 +1,13 @@
+# Battlefield 1942 - An EA game
+# Pattern attributes: ok veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Battlefield_1942
+#
+# Contributed by Myles Uyema <mylesuyema AT gmail.com>
+#
+# This pattern has only been tested by one person.
+
+# tested on two original EA battlefield 1942 servers
+# matches the first two packets of joining a server
+battlefield1942
+^\x01\x11\x10\|\xf8\x02\x10\x40\x06
diff --git a/usr/local/share/protocols/battlefield2.pat b/usr/local/share/protocols/battlefield2.pat
new file mode 100644
index 0000000..088714c
--- /dev/null
+++ b/usr/local/share/protocols/battlefield2.pat
@@ -0,0 +1,25 @@
+# Battlefield 2 - An EA game.
+# Pattern attributes: ok slow notsofast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Battlefield_2
+#
+# This pattern is unconfirmed except implicitly by a comment on protocolinfo.
+
+battlefield2
+# gameplay|account-login|server browsing/information
+# See http://protocolinfo.org/wiki/Battlefield_2
+# Can we put a ^ on the last branch? If so, nosofast --> veryfast
+
+# 193.85.217.35 on protocolinfo says:
+# The first part of the pattern, \x11\x20\x01\xa0\x98\x11, has to be
+# modified for different version of Battlefield 2. The gameplay part of
+# pattern for BF2 v1.4 is \x11\x20\x01\x30\xb9\x10\x11, and for BF2
+# v1.41 is \x11\x20\x01\x50\xb9\x10\x11
+#
+# Rather than put all of those in, I've just gone with "...?" in the
+# middle.
+
+^(\x11\x20\x01...?\x11|\xfe\xfd.?.?.?.?.?.?(\x14\x01\x06|\xff\xff\xff))|[]\x01].?battlefield2
+
+# Pattern prior to 193.85.217.35's comment on protocolinfo:
+#^(\x11\x20\x01\xa0\x98\x11|\xfe\xfd.?.?.?.?.?.?(\x14\x01\x06|\xff\xff\xff))|[]\x01].?battlefield2
diff --git a/usr/local/share/protocols/battlefield2142.pat b/usr/local/share/protocols/battlefield2142.pat
new file mode 100644
index 0000000..6794cff
--- /dev/null
+++ b/usr/local/share/protocols/battlefield2142.pat
@@ -0,0 +1,13 @@
+# Battlefield 2142 - An EA game.
+# Pattern attributes: ok fast fast
+# Protocol groups: proprietary game
+# Wiki: http://protocolinfo.org/wiki/Battlefield_2142
+
+# Submitted by Telsin. Not confirmed.
+
+battlefield2142
+# gameplay|account-login|server browsing/information
+# Can't put a ^ on the last branch: it fails to match if you do.
+# This branch seems to matter very rarely, though
+^(\x11\x20\x01\x90\x50\x64\x10|\xfe\xfd.?.?.?\x18|[\x01\\].?battlefield2)
+
diff --git a/usr/local/share/protocols/bgp.pat b/usr/local/share/protocols/bgp.pat
new file mode 100644
index 0000000..d7985c0
--- /dev/null
+++ b/usr/local/share/protocols/bgp.pat
@@ -0,0 +1,18 @@
+# BGP - Border Gateway Protocol - RFC 1771
+# Pattern attributes: ok veryfast fast
+# Protocol groups: networking ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/BGP
+#
+# This pattern is UNTESTED.
+
+bgp
+# "After a transport protocol connection is established, the first
+# message sent by each side is an OPEN message."
+# "If the Type of the message is OPEN, or if the Authentication Code used
+# in the OPEN message of the connection is zero, then the Marker must be
+# all ones."
+# Then the 2 byte length field, then the 1 byte type field (1 = OPEN).
+# Then the BGP version: 3 was RFC'd in 1991, 4 was RFC'd in 1995.
+# Could keep going, but that should be sufficient.
+^\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff\xff..?\x01[\x03\x04]
+
diff --git a/usr/local/share/protocols/biff.pat b/usr/local/share/protocols/biff.pat
new file mode 100644
index 0000000..7df399a
--- /dev/null
+++ b/usr/local/share/protocols/biff.pat
@@ -0,0 +1,15 @@
+# Biff - new mail notification
+# Pattern attributes: good veryfast fast undermatch overmatch
+# Protocol groups: mail
+# Wiki: http://www.protocolinfo.org/wiki/Biff
+#
+# Usually runs on port 512
+#
+# This pattern is completely untested.
+
+biff
+# This is a rare case where we will specify a $ (end of line), since
+# this is the entirety of the communication.
+# something that looks like a username, an @, a number.
+# won't catch usernames that have strange characters in them.
+^[a-z][a-z0-9]+@[1-9][0-9]+$
diff --git a/usr/local/share/protocols/bittorrent.pat b/usr/local/share/protocols/bittorrent.pat
new file mode 100644
index 0000000..e5aa5bc
--- /dev/null
+++ b/usr/local/share/protocols/bittorrent.pat
@@ -0,0 +1,27 @@
+# Bittorrent - P2P filesharing / publishing tool - http://www.bittorrent.com
+# Pattern attributes: good slow notsofast undermatch
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/Bittorrent
+#
+# This pattern has been tested and is believed to work well.
+# It will, however, not work on bittorrent streams that are encrypted, since
+# it's impossible to match encrypted data (unless the encryption is extremely
+# weak, like rot13 or something...).
+
+bittorrent
+
+# Does not attempt to match the HTTP download of the tracker
+# 0x13 is the length of "bittorrent protocol"
+# Second two bits match UDP wierdness
+# Next bit matches something Azureus does
+# Ditto on the next bit. Could also match on "user-agent: azureus", but that's in the next
+# packet and perhaps this will match multiple clients.
+
+# Recently the ^ was removed from before \x13. I think this was an accident,
+# so I have restored it.
+
+# This is not a valid GNU basic regular expression (but that's ok).
+^(\x13bittorrent protocol|azver\x01$|get /scrape\?info_hash=)|d1:ad2:id20:|\x08'7P\)[RP]
+
+# This pattern is "fast", but won't catch as much
+#^(\x13bittorrent protocol|azver\x01$|get /scrape\?info_hash=)
diff --git a/usr/local/share/protocols/chikka.pat b/usr/local/share/protocols/chikka.pat
new file mode 100644
index 0000000..c7259a7
--- /dev/null
+++ b/usr/local/share/protocols/chikka.pat
@@ -0,0 +1,16 @@
+# Chikka - SMS service which can be used without phones - http://chikka.com
+# Pattern attributes: good veryfast fast superset
+# Protocol groups: proprietary chat
+# Wiki: http://www.protocolinfo.org/wiki/Chikka
+
+# Tested with Chikka Javalite on 14 Jan 2007.
+# The login and chat use the same TCP connection.
+
+# "Kamusta" means "Hello" in Tagalog, apparently, so that will probably
+# stay the same. I've only seen v1.2, but I've given it some leeway for
+# past and future versions.
+
+# Chikka uses CIMD as part of the login process, see cimd.pat
+
+chikka
+^CTPv1.[123] Kamusta.*\x0d\x0a$
diff --git a/usr/local/share/protocols/cimd.pat b/usr/local/share/protocols/cimd.pat
new file mode 100644
index 0000000..6df274f
--- /dev/null
+++ b/usr/local/share/protocols/cimd.pat
@@ -0,0 +1,18 @@
+# Computer Interface to Message Distribution, an SMSC protocol by Nokia
+# Pattern attributes: good notsofast notsofast subset
+# Protocol groups: proprietary chat
+# Wiki: http://www.protocolinfo.org/wiki/CIMD
+
+# I don't know whether CIMD is ever found by itself in a TCP connection.
+# I have only seen it myself as part of the Chikka login process, in
+# which the second and third packets (at least) are CIMD. So I am not
+# using a '^' at the beginning.
+#
+# This pretty well explains the pattern:
+# http://en.wikipedia.org/w/index.php?title=CIMD&oldid=42707583
+# However, Chikka does NOT terminate the last field with a tab.
+#
+# Tested with Chikka Javalite on 14 Jan 2007.
+
+cimd
+\x02[0-4][0-9]:[0-9]+.*\x03$
diff --git a/usr/local/share/protocols/ciscovpn.pat b/usr/local/share/protocols/ciscovpn.pat
new file mode 100644
index 0000000..c15725e
--- /dev/null
+++ b/usr/local/share/protocols/ciscovpn.pat
@@ -0,0 +1,10 @@
+# Cisco VPN - VPN client software to a Cisco VPN server
+# Pattern attributes: ok veryfast fast
+# Protocol groups: remote_access proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Cisco_VPN
+#
+# This pattern contributed by Myles Uyema <myles AT uyema.net>
+
+ciscovpn
+^\x01\xf4\x01\xf4
+
diff --git a/usr/local/share/protocols/citrix.pat b/usr/local/share/protocols/citrix.pat
new file mode 100644
index 0000000..1215c22
--- /dev/null
+++ b/usr/local/share/protocols/citrix.pat
@@ -0,0 +1,11 @@
+# Citrix ICA - proprietary remote desktop application - http://citrix.com
+# Pattern attributes: marginal notsofast notsofast
+# Protocol groups: remote_access proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Citrix
+#
+# This pattern is UNTESTED.
+
+# This is based on decode_citrix in dsniff 2.4.
+
+citrix
+\x32\x26\x85\x92\x58
diff --git a/usr/local/share/protocols/counterstrike-source.pat b/usr/local/share/protocols/counterstrike-source.pat
new file mode 100644
index 0000000..94aa07a
--- /dev/null
+++ b/usr/local/share/protocols/counterstrike-source.pat
@@ -0,0 +1,41 @@
+# Counterstrike (using the new "Source" engine) - network game
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Counter-Strike
+#
+# By adam.randazzoATgmail.com
+
+counterstrike-source
+^\xff\xff\xff\xff.*cstrikeCounter-Strike
+
+# These games use Steam, which is developed by Valve Software.
+#
+# This was based off of the following captured data from ethereal:
+# --Source--
+# 0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 20 ...*.y...,?...E
+# 0010 00 72 b9 f6 00 00 6b 11 b6 78 18 0e 04 cc c0 a8 .r....k..x......
+# 0020 01 6a 69 87 04 65 00 5e 01 ac ff ff ff ff 49 07 .ji..e.^......I.
+# 0030 54 4a 27 73 20 50 6c 61 63 65 20 6f 66 20 50 61 TJ's Place of Pa
+# 0040 69 6e 00 64 65 5f 70 69 72 61 6e 65 73 69 00 63 in.de_piranesi.c
+# 0050 73 74 72 69 6b 65 00 43 6f 75 6e 74 65 72 2d 53 strike.Counter-S
+# 0060 74 72 69 6b 65 3a 20 53 6f 75 72 63 65 00 dc 00 trike: Source...
+# 0070 08 10 06 64 77 00 00 31 2e 30 2e 30 2e 31 38 00 ...dw..1.0.0.18.
+# 0080
+#
+# --1.6--
+# 0000 00 11 09 2a a8 79 00 13 10 2c 3f d7 08 00 45 00 ...*.y...,?...E.
+# 0010 00 8e c4 1a 00 00 76 11 b3 85 08 09 02 fa c0 a8 ......v.........
+# 0020 01 14 69 91 04 37 00 7a c9 90 ff ff ff ff 6d 38 ..i..7.z......m8
+# 0030 2e 39 2e 32 2e 32 35 30 3a 32 37 30 32 35 00 49 .9.2.250:27025.I
+# 0040 50 20 2d 20 43 6c 61 6e 20 73 65 72 76 65 72 00 P - Clan server.
+# 0050 64 65 5f 64 75 73 74 32 00 63 73 74 72 69 6b 65 de_dust2.cstrike
+# 0060 00 43 6f 75 6e 74 65 72 2d 53 74 72 69 6b 65 00 .Counter-Strike.
+# 0070 0a 0c 2f 64 77 00 01 77 77 77 2e 63 6f 75 6e 74 ../dw..www.count
+# 0080 65 72 2d 73 74 72 69 6b 65 2e 6e 65 74 00 00 00 er-strike.net...
+# 0090 01 00 00 00 00 9e f7 0a 00 01 00 00 ............
+
+
+# Old pattern. (Adam Randazzo says "CS 1.6 and CS: Source are the
+# only two versions that are playable on the Internet since Valve
+# disabled the WON system in favor of steam.")
+# cs .*dl.www.counter-strike.net
diff --git a/usr/local/share/protocols/cvs.pat b/usr/local/share/protocols/cvs.pat
new file mode 100644
index 0000000..d6cf503
--- /dev/null
+++ b/usr/local/share/protocols/cvs.pat
@@ -0,0 +1,13 @@
+# CVS - Concurrent Versions System
+# Pattern attributes: good veryfast fast
+# Protocol groups: version_control open_source
+# Wiki: http://www.protocolinfo.org/wiki/CVS
+
+cvs
+
+# Matches pserver login. AUTH is for actually starting the protocol
+# VERIFICATION is for authenticating without starting the protocols
+# and GSSAPI is for using security services such as kerberos.
+# http://www.loria.fr/~molli/cvs/doc/cvsclient_3.html
+
+^BEGIN (AUTH|VERIFICATION|GSSAPI) REQUEST\x0a
diff --git a/usr/local/share/protocols/dayofdefeat-source.pat b/usr/local/share/protocols/dayofdefeat-source.pat
new file mode 100644
index 0000000..1a90b4d
--- /dev/null
+++ b/usr/local/share/protocols/dayofdefeat-source.pat
@@ -0,0 +1,10 @@
+# Day of Defeat: Source - game (Half-Life 2 mod) - http://www.valvesoftware.com
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Day_of_Defeat:Source
+#
+# By Clayton Macleod <cherry twist at gmail dot com>
+
+dayofdefeat-source
+^\xff\xff\xff\xff.*dodDay of Defeat
+
diff --git a/usr/local/share/protocols/dhcp.pat b/usr/local/share/protocols/dhcp.pat
new file mode 100644
index 0000000..9594ea4
--- /dev/null
+++ b/usr/local/share/protocols/dhcp.pat
@@ -0,0 +1,35 @@
+# DHCP - Dynamic Host Configuration Protocol - RFC 1541
+# Pattern attributes: good veryfast fast
+# Protocol groups: networking ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/DHCP
+#
+# Usually runs on ports 67 (server) and 68 (client)
+#
+# Also matches BOOTP (Bootstrap Protocol (RFC 951)) in the case that
+# the "vendor specific options" are used (these options were made standard
+# for DHCP).
+#
+# This pattern is lightly tested.
+
+dhcp
+^[\x01\x02][\x01- ]\x06.*c\x82sc
+
+# Let's break that down:
+#
+# (\x01|\x02) is for BOOTREQUEST or BOOTREPLY
+# Is there a demand for doing these seperately? The Packeteer does.
+#
+# [\x01-\x20] is for any of the hardware address types listed at
+# (http://www.iana.org/assignments/arp-parameters) and hopefully faster
+# ethernets too (100, 1000 and 10000mb) as well (do they share the 10mb
+# number?).
+#
+# \x06 for "hardware address length = 6 bytes". Does anyone use other lengths
+# these days? If so, this pattern won't match it as it stands.
+#
+# .* covers the hops, xid, secs, flags, ciaddr, yiaddr, siaddr, giaddr,
+# chaddr, sname and file fields. While this can't really be "any number
+# of characters" long, it doesn't seem worth it to count.
+# Can we make this more specific by restricting the number of hops or seconds?
+#
+# 0x63825363 is the "magic cookie" which begins the DHCP options field.
diff --git a/usr/local/share/protocols/directconnect.pat b/usr/local/share/protocols/directconnect.pat
new file mode 100644
index 0000000..41631f7
--- /dev/null
+++ b/usr/local/share/protocols/directconnect.pat
@@ -0,0 +1,13 @@
+# Direct Connect - P2P filesharing - http://www.neo-modus.com
+# Pattern attributes: good fast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Direct_Connect
+#
+# Direct Connect "hubs" listen on port 411
+# http://www.dcpp.net/wiki/
+# I've verified that this pattern can be used to limit direct connect
+# bandwidth using DC:PRO 0.2.3.149R11.
+
+directconnect
+# client-to-client handshake|client-to-hub login, hub speaking|client-to-hub login, client speaking
+^(\$mynick |\$lock |\$key )
diff --git a/usr/local/share/protocols/dns.pat b/usr/local/share/protocols/dns.pat
new file mode 100644
index 0000000..5bc0ac0
--- /dev/null
+++ b/usr/local/share/protocols/dns.pat
@@ -0,0 +1,62 @@
+# DNS - Domain Name System - RFC 1035
+# Pattern attributes: great slow fast
+# Protocol groups: networking ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/DNS
+
+# Thanks to Sebastien Bechet <s.bechet AT av7.net> for TLD detection
+# improvements
+
+# While RFC 2181 says "Occasionally it is assumed that the Domain Name
+# System serves only the purpose of mapping Internet host names to data,
+# and mapping Internet addresses to host names. This is not correct, the
+# DNS is a general (if somewhat limited) hierarchical database, and can
+# store almost any kind of data, for almost any purpose.", we will assume
+# just that, because that represents the vast majority of DNS traffic.
+
+# The packet starts with a 2 byte random ID number and 2 bytes of flags that
+# aren't easy to match on.
+
+# The first thing that is matchable is QDCOUNT, the number of queries.
+# Despite the fact that you can apparently ask for up to 65535
+# things at a time, usually you only ask for one and I doubt you ever ask for
+# zero. Let's allow up to two, just in case (even though I can't find any
+# situation that generates more than one).
+
+# Next comes the ANCOUNT, NSCOUNT, and ARCOUNT fields, which could be null
+# or some smallish number, not matchable except by length (up to 6)
+
+# The next matchable thing is the query address. The first byte indicates the
+# length of the first part of the address, which is limited to 63 (0x3F == '?').
+# The next byte has to be a letter (for domain names) or number (for reverse lookups).
+# Then there can be an combination of
+# letters, digits, hyphens, and 0x01-0x3F length markers.
+# Then we check for the presence of a top-level-domain at some later point.
+# This is indicated by a 0x02-0x06 and at least two letters, followed by no
+# more than four more letters.
+# Note that this will miss a very few queries that are for a TLD alone.
+# i.e. "host museum" (195.7.77.17)
+#
+# http://www.icann.org/tlds http://www.iana.org/cctld/cctld-whois.htm
+
+# next is the QTYPE field, which has valid values 1-16 (although this
+# could probably be restricted further since many are rare) and \x1c for
+# IPv6 (and maybe more?). It should follow immediately after the TLD
+# (and some stripped-out nulls)
+
+# next is QCLASS, which has valid values 1-4 and 255, except 2 is never used.
+# I'm not sure if 3 and 4 are used, so I'll include them. 1=Internet 255=any
+
+# If we wanted to match queries and responses separately, there could be
+# more specifics after this for the responses.
+
+dns
+# here's a sane way of doing it
+^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][fglmoprstuvz]?[aeop]?(um)?[\x01-\x10\x1c][\x01\x03\x04\xFF]
+
+# This way assumes that TLDs are any alpha string 2-6 characters long.
+# If TLDs are added, this is a good fallback.
+#^.?.?.?.?[\x01\x02].?.?.?.?.?.?[\x01-?][a-z0-9][\x01-?a-z]*[\x02-\x06][a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]?[\x01-\x10][\x01\x03\x04\xFF]
+
+# If you have more processing power than me, you can substitute this for
+# the [a-z][a-z][a-z]?[a-z]?[a-z]?[a-z]?
+#(aero|arpa|biz|com|coop|edu|gov|info|int|mil|museum|name|net|org|pro|arpa|ac|ad|ae|af|ag|ai|al|am|an|ao|aq|ar|as|at|au|aw|az|ba|bb|bd|be|bf|bg|bh|bi|bj|bm|bn|bo|br|bs|bt|bv|bw|by|bz|ca|cc|cd|cf|cg|ch|ci|ck|cl|cm|cn|co|cr|cu|cv|cx|cy|cz|de|dj|dk|dm|do|dz|ec|ee|eg|eh|er|es|et|fi|fj|fk|fm|fo|fr|ga|gd|ge|gf|gg|gh|gi|gl|gm|gn|gp|gq|gr|gs|gt|gu|gw|gy|hk|hm|hn|hr|ht|hu|id|ie|il|im|in|io|iq|ir|is|it|je|jm|jo|jp|ke|kg|kh|ki|km|kn|kp|kr|kw|ky|kz|la|lb|lc|li|lk|lr|ls|lt|lu|lv|ly|ma|mc|md|mg|mh|mk|ml|mm|mn|mo|mp|mq|mr|ms|mt|mu|mv|mw|mx|my|mz|na|nc|ne|nf|ng|ni|nl|no|np|nr|nu|nz|om|pa|pe|pf|pg|ph|pk|pl|pm|pn|pr|ps|pt|pw|py|qa|re|ro|ru|rw|sa|sb|sc|sd|se|sg|sh|si|sj|sk|sl|sm|sn|so|sr|st|sv|sy|sz|tc|td|tf|tg|th|tj|tk|tm|tn|to|tp|tr|tt|tv|tw|tz|ua|ug|uk|um|us|uy|uz|va|vc|ve|vg|vi|vn|vu|wf|ws|ye|yt|yu|za|zm|zw)
diff --git a/usr/local/share/protocols/doom3.pat b/usr/local/share/protocols/doom3.pat
new file mode 100644
index 0000000..ef59ee7
--- /dev/null
+++ b/usr/local/share/protocols/doom3.pat
@@ -0,0 +1,9 @@
+# Doom 3 - computer game
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Doom
+#
+# Thanks to Clayton Macleod (cherrytwist at gmail.com).
+
+doom3
+^\xff\xffchallenge
diff --git a/usr/local/share/protocols/edonkey.pat b/usr/local/share/protocols/edonkey.pat
new file mode 100644
index 0000000..50a072c
--- /dev/null
+++ b/usr/local/share/protocols/edonkey.pat
@@ -0,0 +1,36 @@
+# eDonkey2000 - P2P filesharing - http://edonkey2000.com and others
+# Pattern attributes: good veryfast fast overmatch
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/EDonkey
+#
+# Tested recently (April/May 2006) with eMule 0.47a and eDonkey2000 1.4
+# and a long time ago with something else.
+#
+# In addition to matching what you might expect, this matches much of
+# what eMule does when you tell it to only connect to the KAD network.
+# I don't quite know what to make of this.
+
+# Thanks to Matt Skidmore <fox AT woozle.org>
+
+edonkey
+
+# http://gd.tuwien.ac.at/opsys/linux/sf/p/pdonkey/eDonkey-protocol-0.6
+#
+# In addition to \xe3, \xc5 and \xd4, I see a lot of \xe5.
+# As of April 2006, I also see some \xe4.
+#
+# God this is a mess. What an irritating protocol.
+# This will match about 2% of streams with random data in them!
+# (But fortunately much fewer than 2% of streams that are other protocols.
+# You can test this with the data in ../testing/)
+
+^[\xc5\xd4\xe3-\xe5].?.?.?.?([\x01\x02\x05\x14\x15\x16\x18\x19\x1a\x1b\x1c\x20\x21\x32\x33\x34\x35\x36\x38\x40\x41\x42\x43\x46\x47\x48\x49\x4a\x4b\x4c\x4d\x4e\x4f\x50\x51\x52\x53\x54\x55\x56\x57\x58[\x60\x81\x82\x90\x91\x93\x96\x97\x98\x99\x9a\x9b\x9c\x9e\xa0\xa1\xa2\xa3\xa4]|\x59................?[ -~]|\x96....$)
+
+# matches everything and too much
+# ^(\xe3|\xc5|\xd4)
+
+# ipp2p essentially uses "\xe3....\x47", which doesn't seem at all right to me.
+
+# bandwidtharbitrator uses
+# e0.*@.*6[a-z].*p$|e0.*@.*[a-z]6[a-z].*p0$|e.*@.*[0-9]6.*p$|emule|edonkey
+# no comments to explain what all the mush is, of course...
diff --git a/usr/local/share/protocols/fasttrack.pat b/usr/local/share/protocols/fasttrack.pat
new file mode 100644
index 0000000..c821ae4
--- /dev/null
+++ b/usr/local/share/protocols/fasttrack.pat
@@ -0,0 +1,22 @@
+# FastTrack - P2P filesharing (Kazaa, Morpheus, iMesh, Grokster, etc)
+# Pattern attributes: good slow notsofast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Fasttrack
+#
+# Tested with Kazaa Lite Resurrection 0.0.7.6F
+#
+# This appears to match the download connections well, but not the search
+# connections (I think they are encrypted :-( ).
+
+fasttrack
+# while this is a valid http request, this will be caught because
+# the http pattern matches the response (and therefore the next packet)
+# Even so, it's best to put this match earlier in the chain.
+# http://cvs.berlios.de/cgi-bin/viewcvs.cgi/gift-fasttrack/giFT-FastTrack/PROTOCOL?rev=HEAD&content-type=text/vnd.viewcvs-markup
+
+# This pattern is kinda slow, but not too bad.
+^get (/.download/[ -~]*|/.supernode[ -~]|/.status[ -~]|/.network[ -~]*|/.files|/.hash=[0-9a-f]*/[ -~]*) http/1.1|user-agent: kazaa|x-kazaa(-username|-network|-ip|-supernodeip|-xferid|-xferuid|tag)|^give [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]?[0-9]?[0-9]?
+
+# This isn't much faster:
+#^get (/.download/.*|/.supernode.|/.status.|/.network.*|/.files|/.hash=[0-9a-f]*/.*) http/1.1|user-agent: kazaa|x-kazaa(-username|-network|-ip|-supernodeip|-xferid|-xferuid|tag)|^give [0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]?[0-9]?[0-9]?
+
diff --git a/usr/local/share/protocols/finger.pat b/usr/local/share/protocols/finger.pat
new file mode 100644
index 0000000..b2b59d8
--- /dev/null
+++ b/usr/local/share/protocols/finger.pat
@@ -0,0 +1,14 @@
+# Finger - User information server - RFC 1288
+# Pattern attributes: good slow slow undermatch overmatch
+# Protocol groups: ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/Finger
+#
+# Usually runs on port 79
+#
+# This pattern is lightly tested.
+
+finger
+# The first matches the client request, which should look like a username.
+# The second matches the usual UNIX reply (but remember that they are
+# allowed to say whatever they want)
+^[a-z][a-z0-9\-_]+|login: [\x09-\x0d -~]* name: [\x09-\x0d -~]* Directory:
diff --git a/usr/local/share/protocols/freenet.pat b/usr/local/share/protocols/freenet.pat
new file mode 100644
index 0000000..626acb9
--- /dev/null
+++ b/usr/local/share/protocols/freenet.pat
@@ -0,0 +1,9 @@
+# Freenet - Anonymous information retrieval - http://freenetproject.org
+# Pattern attributes: poor veryfast fast
+# Protocol groups: p2p document_retrieval open_source
+# Wiki: http://www.protocolinfo.org/wiki/Freenet
+
+freenet
+# Freenet is intentionally hard to identify...
+# This is empirical, only tested on one computer, and unlikely to work anymore.
+^\x01[\x08\x09][\x03\x04]
diff --git a/usr/local/share/protocols/ftp.pat b/usr/local/share/protocols/ftp.pat
new file mode 100644
index 0000000..a7f9e0e
--- /dev/null
+++ b/usr/local/share/protocols/ftp.pat
@@ -0,0 +1,45 @@
+# FTP - File Transfer Protocol - RFC 959
+# Pattern attributes: great notsofast fast
+# Protocol groups: document_retrieval ietf_internet_standard
+# Wiki: http://protocolinfo.org/wiki/FTP
+#
+# Usually runs on port 21. Note that the data stream is on a dynamically
+# assigned port, which means that you will need the FTP connection
+# tracking module in your kernel to usefully match FTP data transfers.
+#
+# This pattern is well tested.
+#
+# Handles the first two things a server should say:
+#
+# First, the server says it's ready by sending "220". Most servers say
+# something after 220, even though they don't have to, and it usually
+# includes the string "ftp" (l7-filter is case insensitive). This
+# includes proftpd, vsftpd, wuftpd, warftpd, pureftpd, Bulletproof FTP
+# Server, and whatever ftp.microsoft.com uses. Almost all servers use only
+# ASCII printable characters between the "220" and the "FTP", but non-English
+# ones might use others.
+#
+# The next thing the server sends is a 331. All the above servers also
+# send something including "password" after this code. By default, we
+# do not match on this because it takes another packet and is more work
+# for regexec.
+
+ftp
+# by default, we allow only ASCII
+^220[\x09-\x0d -~]*ftp
+
+# This covers UTF-8 as well
+#^220[\x09-\x0d -~\x80-\xfd]*ftp
+
+# This allows any characters and is about 4x faster than either of the above
+# (which are about the same as each other)
+#^220.*ftp
+
+# This is much slower
+#^220[\x09-\x0d -~]*ftp|331[\x09-\x0d -~]*password
+
+# This pattern is more precise, but takes longer to match. (3 packets vs. 1)
+#^220[\x09-\x0d -~]*\x0d\x0aUSER[\x09-\x0d -~]*\x0d\x0a331
+
+# same as above, but slightly less precise and only takes 2 packets.
+#^220[\x09-\x0d -~]*\x0d\x0aUSER[\x09-\x0d -~]*\x0d\x0a
diff --git a/usr/local/share/protocols/gkrellm.pat b/usr/local/share/protocols/gkrellm.pat
new file mode 100644
index 0000000..2acf73b
--- /dev/null
+++ b/usr/local/share/protocols/gkrellm.pat
@@ -0,0 +1,12 @@
+# Gkrellm - a system monitor - http://gkrellm.net
+# Pattern attributes: great veryfast fast
+# Protocol groups: monitoring open_source
+# Wiki: http://www.protocolinfo.org/wiki/Gkrellm
+#
+# This pattern has been tested and is believed to work well.
+# Since this is not anything resembling a published protocol, it may change without
+# warning in new versions of gkrellm.
+
+gkrellm
+# tested with gkrellm 2.2.7
+^gkrellm [23].[0-9].[0-9]\x0a$
diff --git a/usr/local/share/protocols/gnucleuslan.pat b/usr/local/share/protocols/gnucleuslan.pat
new file mode 100644
index 0000000..2a106f4
--- /dev/null
+++ b/usr/local/share/protocols/gnucleuslan.pat
@@ -0,0 +1,9 @@
+# GnucleusLAN - LAN-only P2P filesharing
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/GnucleusLAN
+#
+# This pattern has been tested and is believed to work well.
+
+gnucleuslan
+gnuclear connect/[\x09-\x0d -~]*user-agent: gnucleus [\x09-\x0d -~]*lan:
diff --git a/usr/local/share/protocols/gnutella.pat b/usr/local/share/protocols/gnutella.pat
new file mode 100644
index 0000000..57a76de
--- /dev/null
+++ b/usr/local/share/protocols/gnutella.pat
@@ -0,0 +1,33 @@
+# Gnutella - P2P filesharing
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/Gnutella
+#
+# This should match both Gnutella and "Gnutella2" ("Mike's protocol")
+#
+# Various clients use this protocol including Mactella, Shareaza,
+# GTK-gnutella, Gnucleus, Gnotella, LimeWire, iMesh and BearShare.
+#
+# This is tested with gtk-gnutella and Shareaza.
+
+# http://www.gnutella2.com/tiki-index.php?page=UDP%20Transceiver
+# http://rfc-gnutella.sf.net/
+# http://www.gnutella2.com/tiki-index.php?page=Gnutella2%20Specification
+# http://en.wikipedia.org/wiki/Shareaza
+
+gnutella
+
+# The first part matches UDP messages - All start with "GND", then have
+# a flag byte which is either \x00, \x01 or \x02, then two sequence bytes
+# that can be anything, then a fragment number, which must start at 1.
+# The rest matches TCP first client message or first server message (in case
+# we can't see client messages). Some parts of this are empirical rather than
+# document based. Assumes version is between 0.0 and 2.9. (usually is
+# 0.4 or 0.6). I'm guessing at many of the user-agents.
+# The last bit is emprical and probably only matches Limewire.
+^(gnd[\x01\x02]?.?.?\x01|gnutella connect/[012]\.[0-9]\x0d\x0a|get /uri-res/n2r\?urn:sha1:|get /.*user-agent: (gtk-gnutella|bearshare|mactella|gnucleus|gnotella|limewire|imesh)|get /.*content-type: application/x-gnutella-packets|giv [0-9]*:[0-9a-f]*/|queue [0-9a-f]* [1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?:[1-9][0-9]?[0-9]?[0-9]?|gnutella.*content-type: application/x-gnutella|...................?lime)
+
+# Needlessly precise, at the expense of time
+#^(gnd[\x01\x02]?.?.?\x01|gnutella connect/[012]\.[0-9]\x0d\x0a|get /uri-res/n2r\?urn:sha1:|get /[\x09-\x0d -~]*user-agent: (gtk-gnutella|bearshare|mactella|gnucleus|gnotella|limewire|imesh)|get /[\x09-\x0d -~]*content-type: application/x-gnutella-packets|giv [0-9]*:[0-9a-f]*/|queue [0-9a-f]* [1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?\.[1-9][0-9]?[0-9]?:[1-9][0-9]?[0-9]?[0-9]?|gnutella[\x09-\x0d -~]*content-type: application/x-gnutella|..................lime)
+
+
diff --git a/usr/local/share/protocols/goboogy.pat b/usr/local/share/protocols/goboogy.pat
new file mode 100644
index 0000000..2cc93da
--- /dev/null
+++ b/usr/local/share/protocols/goboogy.pat
@@ -0,0 +1,12 @@
+# GoBoogy - a Korean P2P protocol
+# Pattern attributes: marginal slow notsofast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/GoBoogy
+#
+# This pattern is untested and likely does not work in all cases!
+#
+# By Adam Przybyla, modified by Matthew Strait. Possibly lifted from
+# Josh Ballard (oofle.com).
+
+goboogy
+<peerplat>|^get /getfilebyhash\.cgi\?|^get /queue_register\.cgi\?|^get /getupdowninfo\.cgi\?
diff --git a/usr/local/share/protocols/gopher.pat b/usr/local/share/protocols/gopher.pat
new file mode 100644
index 0000000..3f49757
--- /dev/null
+++ b/usr/local/share/protocols/gopher.pat
@@ -0,0 +1,24 @@
+# Gopher - A precursor to HTTP - RFC 1436
+# Pattern attributes: good slow notsofast undermatch
+# Protocol groups: document_retrieval obsolete ietf_rfc_documented
+# Wiki: http://www.protocolinfo.org/wiki/Gopher
+#
+# Gopher servers usually run on TCP port 70.
+#
+# This pattern is lightly tested using gopher.dna.affrc.go.jp .
+
+gopher
+# This matches the server's response, but naturally only if it is a
+# directory listing, not if it is sending a file, because then the data
+# is totally arbitrary.
+
+# Matches the client saying "list what you have", then the server
+# response: one of the file type characters, any printable characters, a
+# tab, any printable characters, a tab, something that looks like a
+# domain name, a tab, and then a number which could be the start of a
+# port number.
+
+# "0About internet Gopher\tStuff:About us\trawBits.micro.umn.edu\t70"
+# "\r7search by keywords on protein data using wais\twaissrc:/protein_all/protein\tgopher.dna.affrc.go.jp\t70"
+
+^[\x09-\x0d]*[1-9,+tgi][\x09-\x0d -~]*\x09[\x09-\x0d -~]*\x09[a-z0-9.]*\.[a-z][a-z].?.?\x09[1-9]
diff --git a/usr/local/share/protocols/h323.pat b/usr/local/share/protocols/h323.pat
new file mode 100644
index 0000000..d3f59c5
--- /dev/null
+++ b/usr/local/share/protocols/h323.pat
@@ -0,0 +1,35 @@
+# H.323 - Voice over IP.
+# Pattern attributes: ok veryfast fast
+# Protocol groups: voip itu-t_standard
+# Wiki: http://www.protocolinfo.org/wiki/H.323
+#
+# This pattern is written without knowledge of the principles of H.323.
+# It has only been tested with gnomemeeting and may not work for other
+# clients.
+#
+# Also, it has been reported that:
+# "the pattern ... match[es] only first H.323 stream (conntrack for H.323 was
+# enabled). Also the major chunk of traffic was of RTP which went untracked."
+#
+# Also, it may very well match other things that use TPKT and
+# Q.931.
+
+# Note that to take full advantage of this pattern, you will need to
+# have connection tracking of H.323 support in your kernel. This
+# support is not in the stock kernel. A patch can be found at
+# http://netfilter.org
+
+h323
+# TPKT format: http://www.ietf.org/rfc/rfc1006.txt
+# \x03 = TPKT version. It was 3 in May 1987 and gnomemeeting still uses 3.
+# ..? = null reserved byte and packet length field.
+# Q.931 format: http://www.freesoft.org/CIE/Topics/126.htm
+# \x08 = Q.931
+# . = length of call reference
+# The next byte was: \x18 = message sent from originating side.
+# But based on experimentation, it seems that just . is better.
+# .?.?.?.?.?.?.?.?.?.?.?.?.?.?.? = call reference (0-15 bytes (0 for nulls))
+# \x05 = setup message
+#
+# Yup, it doesn't actually include any H.323 protocol information.
+^\x03..?\x08...?.?.?.?.?.?.?.?.?.?.?.?.?.?.?\x05
diff --git a/usr/local/share/protocols/halflife2-deathmatch.pat b/usr/local/share/protocols/halflife2-deathmatch.pat
new file mode 100644
index 0000000..6efe59e
--- /dev/null
+++ b/usr/local/share/protocols/halflife2-deathmatch.pat
@@ -0,0 +1,9 @@
+# Half-Life 2 Deathmatch - popular computer game
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Half-Life
+#
+# By Clayton Macleod <cherrytwist TA gmail.com>
+
+halflife2-deathmatch
+^\xff\xff\xff\xff.*hl2mpDeathmatch
diff --git a/usr/local/share/protocols/hddtemp.pat b/usr/local/share/protocols/hddtemp.pat
new file mode 100644
index 0000000..31a640f
--- /dev/null
+++ b/usr/local/share/protocols/hddtemp.pat
@@ -0,0 +1,13 @@
+# hddtemp - Hard drive temperature reporting
+# Pattern attributes: great veryfast fast
+# Protocol groups: monitoring open_source
+# Wiki: http://www.protocolinfo.org/wiki/HDDtemp
+#
+# Usually runs on port 7634
+#
+# You're a silly person if you use this pattern.
+#
+# This pattern has been tested and is believed to work well.
+
+hddtemp
+^\|/dev/[a-z][a-z][a-z]\|[0-9a-z]*\|[0-9][0-9]\|[cfk]\|
diff --git a/usr/local/share/protocols/hotline.pat b/usr/local/share/protocols/hotline.pat
new file mode 100644
index 0000000..1c11c62
--- /dev/null
+++ b/usr/local/share/protocols/hotline.pat
@@ -0,0 +1,11 @@
+# Hotline - An old P2P filesharing protocol
+# Pattern attributes: marginal fast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Hotline
+#
+# This pattern is untested!
+#
+# This is lifted from http://oofle.com/filesharing.php?app=hotline
+
+hotline
+^....................TRTPHOTL\x01\x02
diff --git a/usr/local/share/protocols/http-rtsp.pat b/usr/local/share/protocols/http-rtsp.pat
new file mode 100644
index 0000000..3cb65fb
--- /dev/null
+++ b/usr/local/share/protocols/http-rtsp.pat
@@ -0,0 +1,15 @@
+# RTSP tunneled within HTTP
+# Pattern attributes: ok notsofast notsofast subset
+# Protocol groups: streaming_audio streaming_video ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/RTSP
+#
+# Apple's documentation on what Quicktime does:
+# http://developer.apple.com/quicktime/icefloe/dispatch028.html
+# This is what the first part of the pattern is about
+#
+# The second part is based on the example in RFC 2326. For this part to
+# work, this pattern MUST be earlier in the iptables rules chain than
+# HTTP. Otherwise, the stream will be identified as HTTP.
+
+http-rtsp
+^(get[\x09-\x0d -~]* Accept: application/x-rtsp-tunnelled|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*a=control:rtsp://)
diff --git a/usr/local/share/protocols/http.pat b/usr/local/share/protocols/http.pat
new file mode 100644
index 0000000..550aa0b
--- /dev/null
+++ b/usr/local/share/protocols/http.pat
@@ -0,0 +1,27 @@
+# HTTP - HyperText Transfer Protocol - RFC 2616
+# Pattern attributes: great slow notsofast superset
+# Protocol groups: document_retrieval ietf_draft_standard
+# Wiki: http://protocolinfo.org/wiki/HTTP
+#
+# Usually runs on port 80
+#
+# This pattern has been tested and is believed to work well.
+#
+# this intentionally catches the response from the server rather than
+# the request so that other protocols which use http (like kazaa) can be
+# caught based on specific http requests regardless of the ordering of
+# filters... also matches posts
+
+# Sites that serve really long cookies may break this by pushing the
+# server response too far away from the beginning of the connection. To
+# fix this, increase the kernel's data buffer length.
+
+http
+# Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF (rfc 2616)
+# As specified in rfc 2616 a status code is preceeded and followed by a
+# space.
+http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*(connection:|content-type:|content-length:|date:)|post [\x09-\x0d -~]* http/[01]\.[019]
+# A slightly faster version that might be good enough:
+#http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9]|post [\x09-\x0d -~]* http/[01]\.[019]
+# old pattern(s):
+#(http[\x09-\x0d -~]*(200 ok|302 |304 )[\x09-\x0d -~]*(connection:|content-type:|content-length:))|^(post [\x09-\x0d -~]* http/)
diff --git a/usr/local/share/protocols/ident.pat b/usr/local/share/protocols/ident.pat
new file mode 100644
index 0000000..d6d89c3
--- /dev/null
+++ b/usr/local/share/protocols/ident.pat
@@ -0,0 +1,14 @@
+# Ident - Identification Protocol - RFC 1413
+# Pattern attributes: good fast fast
+# Protocol groups: networking ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/Ident
+#
+# Usually runs on port 113
+#
+# This pattern is believed to work.
+
+ident
+# "number , numberCRLF" possibly without the CR and/or LF.
+# ^$ is appropriate because the first packet should never have anything
+# else in it.
+^[1-9][0-9]?[0-9]?[0-9]?[0-9]?[\x09-\x0d]*,[\x09-\x0d]*[1-9][0-9]?[0-9]?[0-9]?[0-9]?(\x0d\x0a|[\x0d\x0a])?$
diff --git a/usr/local/share/protocols/imap.pat b/usr/local/share/protocols/imap.pat
new file mode 100644
index 0000000..eac620d
--- /dev/null
+++ b/usr/local/share/protocols/imap.pat
@@ -0,0 +1,13 @@
+# IMAP - Internet Message Access Protocol (A common e-mail protocol)
+# Pattern attributes: great veryfast fast
+# Protocol groups: mail ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/IMAP
+#
+# This matches IMAP4 (RFC 3501) and probably IMAP2 (RFC 1176)
+#
+# This pattern has been tested and is believed to work well.
+#
+# This matches the IMAP welcome message or a noop command (which for
+# some unknown reason can happen at the start of a connection?)
+imap
+^(\* ok|a[0-9]+ noop)
diff --git a/usr/local/share/protocols/imesh.pat b/usr/local/share/protocols/imesh.pat
new file mode 100644
index 0000000..782047f
--- /dev/null
+++ b/usr/local/share/protocols/imesh.pat
@@ -0,0 +1,14 @@
+# iMesh - the native protocol of iMesh, a P2P application - http://imesh.com
+# Pattern attributes: ok notsofast notsofast
+# Protocol groups: p2p
+# Wiki: http://protocolinfo.org/wiki/iMesh
+#
+# depending on the version of iMesh (the program), it can also use fasttrack,
+# gnutella and edonkey in addition to iMesh (the protocol).
+
+imesh
+# The first branch matches the login
+# The second branch matches the main non-download connection (searches, etc)
+# The third branch matches downloads of "premium" content
+# The fourth branch matches peer downloads.
+^(post[\x09-\x0d -~]*<PasswordHash>................................</PasswordHash><ClientVer>|\x34\x80?\x0d?\xfc\xff\x04|get[\x09-\x0d -~]*Host: imsh\.download-prod\.musicnet\.com|\x02[\x01\x02]\x83.*\x02[\x01\x02]\x83)
diff --git a/usr/local/share/protocols/ipp.pat b/usr/local/share/protocols/ipp.pat
new file mode 100644
index 0000000..a4a4d14
--- /dev/null
+++ b/usr/local/share/protocols/ipp.pat
@@ -0,0 +1,11 @@
+# IP printing - a new standard for UNIX printing - RFC 2911
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: printer ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/IPP
+#
+# This pattern has been tested and is believed to work well.
+
+ipp
+# It's unlikely that anything else has this string, but I think we could
+# do a bit better...
+ipp://
diff --git a/usr/local/share/protocols/irc.pat b/usr/local/share/protocols/irc.pat
new file mode 100644
index 0000000..2767336
--- /dev/null
+++ b/usr/local/share/protocols/irc.pat
@@ -0,0 +1,19 @@
+# IRC - Internet Relay Chat - RFC 1459
+# Pattern attributes: great veryfast fast
+# Protocol groups: chat ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/IRC
+#
+# Usually runs on port 6666 or 6667
+# Note that chat traffic runs on these ports, but IRC-DCC traffic (which
+# can use much more bandwidth) uses a dynamically assigned port, so you
+# must have the IRC connection tracking module in your kernel to classify
+# this.
+#
+# This pattern has been tested and is believed to work well.
+
+irc
+# First thing that happens is that the client sends NICK and USER, in
+# either order. This allows MIRC color codes (\x02-\x0d instead of
+# \x09-\x0d).
+^(nick[\x09-\x0d -~]*user[\x09-\x0d -~]*:|user[\x09-\x0d -~]*:[\x02-\x0d -~]*nick[\x09-\x0d -~]*\x0d\x0a)
+
diff --git a/usr/local/share/protocols/jabber.pat b/usr/local/share/protocols/jabber.pat
new file mode 100644
index 0000000..aa51c76
--- /dev/null
+++ b/usr/local/share/protocols/jabber.pat
@@ -0,0 +1,23 @@
+# Jabber (XMPP) - open instant messenger protocol - RFC 3920 - http://jabber.org
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: chat ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/Jabber
+#
+# This pattern has been tested with Gaim and Gabber. It is only tested
+# with non-SSL mode Jabber with no proxies.
+
+# Thanks to Jan Hudec for some improvements.
+
+# Jabber seems to take a long time to set up a connection. I'm
+# connecting with Gabber 0.8.8 to 12jabber.org and the first 8 packets
+# is this:
+# <stream:stream to='12jabber.com' xmlns='jabber:client'
+# xmlns:stream='http://etherx.jabber.org/streams'><?xml
+# version='1.0'?><stream:stream
+# xmlns:stream='http://etherx.jabber.org/streams' id='3f73e951'
+# xmlns='jabber:client' from='12jabber.com'>
+#
+# No mention of my username or password yet, you'll note.
+
+jabber
+<stream:stream[\x09-\x0d ][ -~]*[\x09-\x0d ]xmlns=['"]jabber
diff --git a/usr/local/share/protocols/kugoo.pat b/usr/local/share/protocols/kugoo.pat
new file mode 100644
index 0000000..be15ad5
--- /dev/null
+++ b/usr/local/share/protocols/kugoo.pat
@@ -0,0 +1,14 @@
+# KuGoo - a Chinese P2P program - http://www.kugoo.com
+# Pattern attributes: ok veryfast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/KuGoo
+#
+# The author of this pattern says it works, but this is unconfirmed.
+# Written by www.routerclub.com wsgtrsys.
+#
+# LanTian submitted \x64.+\x74\x47\x50\x37 for "KuGoo2", but adding as
+# another branch makes the pattern REALLY slow. If it could have a ^, that'd
+# be ok (still veryfast/fast). Waiting to hear.
+
+kugoo
+^(\x31..\x8e|\x64.+\x74\x47\x50\x37)
diff --git a/usr/local/share/protocols/live365.pat b/usr/local/share/protocols/live365.pat
new file mode 100644
index 0000000..9360892
--- /dev/null
+++ b/usr/local/share/protocols/live365.pat
@@ -0,0 +1,14 @@
+# live365 - An Internet radio site - http://live365.com
+# Pattern attributes: marginal notsofast notsofast
+# Protocol groups: streaming_audio
+# Wiki: http://www.protocolinfo.org/wiki/Live365
+#
+# This pattern was "contributed" (taken with permission) by the bandwidth
+# arbitrator project (www.bandwidtharbitrator.com).
+#
+# This pattern is unconfirmed.
+
+live365
+# FIXME: what's going on here?
+membername.*session.*player
+
diff --git a/usr/local/share/protocols/liveforspeed.pat b/usr/local/share/protocols/liveforspeed.pat
new file mode 100644
index 0000000..17b755d
--- /dev/null
+++ b/usr/local/share/protocols/liveforspeed.pat
@@ -0,0 +1,12 @@
+# Live For Speed - A racing game.
+# Pattern attributes: poor veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Live_For_Speed
+#
+# This pattern was submitted to protocolinfo.org by 80.55.238.74 with no
+# explanation. It is unconfirmed.
+
+# Live For Speed S2 Alpha 0.5 X10
+liveforspeed
+^..\x05\x58\x0a\x1d\x03
+# The same guy came by the next day and deleted the \x03 without comment...
diff --git a/usr/local/share/protocols/lpd.pat b/usr/local/share/protocols/lpd.pat
new file mode 100644
index 0000000..d1b8ae7
--- /dev/null
+++ b/usr/local/share/protocols/lpd.pat
@@ -0,0 +1,17 @@
+# LPD - Line Printer Daemon Protocol (old-style UNIX printing) - RFC 1179
+# Pattern attributes: ok fast fast
+# Protocol groups: printer ietf_rfc_documented
+# Wiki: http://www.protocolinfo.org/wiki/LPD
+#
+# This pattern is untested.
+
+lpd
+# print waiting jobs: ^\x01[!-~]+\x0a$
+# receive a print job: ^\x02[!-~]+\x0a.[\x01\x02\x03][\x01-\x0a -~]*\x0a$
+# Send queue state: ^[\x03\x04][!-~]+[\x09-\x0d]+[a-z][\x09-\x0d -~]*\x0a$
+# Remove jobs: ^\x05[!-~]+[\x09-\x0d]+([a-z][!-~]*[\x09-\x0d]+[1-9][0-9]?[0-9]?|root[\x09-\x0d]+[!-~]+).*\x0a$
+
+# This pattern looks like it might match random data once in a while, but
+# testing shows that this is not the case.
+
+^(\x01[!-~]+|\x02[!-~]+\x0a.[\x01\x02\x03][\x01-\x0a -~]*|[\x03\x04][!-~]+[\x09-\x0d]+[a-z][\x09-\x0d -~]*|\x05[!-~]+[\x09-\x0d]+([a-z][!-~]*[\x09-\x0d]+[1-9][0-9]?[0-9]?|root[\x09-\x0d]+[!-~]+).*)\x0a$
diff --git a/usr/local/share/protocols/mohaa.pat b/usr/local/share/protocols/mohaa.pat
new file mode 100644
index 0000000..aebe47a
--- /dev/null
+++ b/usr/local/share/protocols/mohaa.pat
@@ -0,0 +1,10 @@
+# Medal of Honor Allied Assault - an Electronic Arts game
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Medal_of_Honor_Allied_Assault
+#
+# This pattern is written and tested by Krzysztof Maciejewski.
+
+mohaa
+^\xff\xff\xff\xffgetstatus\x0a
+
diff --git a/usr/local/share/protocols/msn-filetransfer.pat b/usr/local/share/protocols/msn-filetransfer.pat
new file mode 100644
index 0000000..5ffddfc
--- /dev/null
+++ b/usr/local/share/protocols/msn-filetransfer.pat
@@ -0,0 +1,29 @@
+# MSN (Micosoft Network) Messenger file transfers (MSNFTP and MSNSLP)
+# Pattern attributes: good veryfast fast
+# Protocol groups: chat document_retrieval proprietary
+# Wiki: http://www.protocolinfo.org/wiki/MSN_Messenger
+#
+# http://www.hypothetic.org/docs/msn/client/file_transfer.php
+
+# NOTE! This pattern does not catch the modern type of MSN filetransfers
+# because they use the same TCP connection as the chat itself. See
+# ../example_traffic/msn_chat_and_file_transfer.txt for a demonstration.
+
+# This pattern has been tested and seems to work well. It, does,
+# however, require more testing with various versions of the official
+# MSN client as well as with clones such as Trillian, Miranda, Gaim,
+# etc. If you are using a MSN clone and this pattern DOES work for you,
+# please, also let us know.
+
+# First part matches the older MSNFTP: A MSN filetransfer is a normal
+# MSN connection except that the protocol is MSNFTP. Some clients
+# (especially Trillian) send other protocol versions besides MSNFTP
+# which should be matched by the [ -~]*.
+
+# Second part matches newer MSNSLP:
+# http://msnpiki.msnfanatic.com/index.php/MSNC:MSNSLP
+# This part is untested.
+
+msn-filetransfer
+^(ver [ -~]*msnftp\x0d\x0aver msnftp\x0d\x0ausr|method msnmsgr:)
+
diff --git a/usr/local/share/protocols/msnmessenger.pat b/usr/local/share/protocols/msnmessenger.pat
new file mode 100644
index 0000000..41f1075
--- /dev/null
+++ b/usr/local/share/protocols/msnmessenger.pat
@@ -0,0 +1,27 @@
+# MSN Messenger - Microsoft Network chat client
+# Pattern attributes: good slow notsofast
+# Protocol groups: chat proprietary
+# Wiki: http://www.protocolinfo.org/wiki/MSN_Messenger
+#
+# Usually uses TCP port 1863
+# http://www.hypothetic.org/docs/msn/index.php
+# http://msnpiki.msnfanatic.com/
+#
+# This pattern has been tested and is believed to work well.
+
+msnmessenger
+
+# First branch: login
+# ver: allow versions up to 99.
+# I've never seen a cvr other than cvr0. Maybe this will be trouble later?
+# Can't anchor at the beginning because sometimes this is encapsulated in
+# HTTP. But either way, the first packet ends like this.
+# Second/Third branches: accepting/sending a message
+# I will assume that these can also be encapsulated in HTTP, although I have
+# not checked. Example of each direction:
+# ANS 1 quadong@hotmail.com 1139803431.29427 17522047
+# USR 1 quadong@hotmail.com 530423708.968145.366138
+
+# Branches are written entirely separately for better performance.
+ver [0-9]+ msnp[1-9][0-9]? [\x09-\x0d -~]*cvr0\x0d\x0a$|usr 1 [!-~]+ [0-9. ]+\x0d\x0a$|ans 1 [!-~]+ [0-9. ]+\x0d\x0a$
+
diff --git a/usr/local/share/protocols/mute.pat b/usr/local/share/protocols/mute.pat
new file mode 100644
index 0000000..c803090
--- /dev/null
+++ b/usr/local/share/protocols/mute.pat
@@ -0,0 +1,10 @@
+# MUTE - P2P filesharing - http://mute-net.sourceforge.net
+# Pattern attributes: marginal veryfast fast
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/MUTE
+#
+# This pattern is lightly tested. I don't know for sure that it will
+# match the actual file transfers.
+
+mute
+^(Public|AES)Key: [0-9a-f]*\x0aEnd(Public|AES)Key\x0a$
diff --git a/usr/local/share/protocols/napster.pat b/usr/local/share/protocols/napster.pat
new file mode 100644
index 0000000..83005b8
--- /dev/null
+++ b/usr/local/share/protocols/napster.pat
@@ -0,0 +1,23 @@
+# Napster - P2P filesharing
+# Pattern attributes: good fast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Napster
+#
+# All my tests show that this pattern is fast, but one user has reported that
+# it is slow. Your milage may vary.
+#
+# Should work for any Napster offspring, like OpenNAP.
+# (Yes, people still use this!)
+# Matches both searches and downloads.
+#
+# http://opennap.sourceforge.net/napster.txt
+#
+# This pattern has been tested and is believed to work well.
+
+napster
+# (client-server: length, assumed to be less than 256, login or new user login,
+# username, password, port, client ID, link-type |
+# client-client: 1, firewalled or not, username, filename)
+# Assumes that filenames are well-behaved ASCII strings. I have found
+# one case where this assumptions fails (filename had \x99 in it).
+^(.[\x02\x06][!-~]+ [!-~]+ [0-9][0-9]?[0-9]?[0-9]?[0-9]? "[\x09-\x0d -~]+" ([0-9]|10)|1(send|get)[!-~]+ "[\x09-\x0d -~]+")
diff --git a/usr/local/share/protocols/nbns.pat b/usr/local/share/protocols/nbns.pat
new file mode 100644
index 0000000..d4fff4f
--- /dev/null
+++ b/usr/local/share/protocols/nbns.pat
@@ -0,0 +1,19 @@
+# NBNS - NetBIOS name service
+# Pattern attributes: good slow notsofast
+# Protocol groups: networking proprietary
+# Wiki: http://www.protocolinfo.org/wiki/NBNS
+#
+# This pattern has been tested and is believed to work well.
+#
+# name query
+# \x01\x10 means name query
+#
+# registration NB
+# (\x10 or )\x10 means registration
+#
+# release NB (merged with registration)
+# 0\x10 means release
+
+nbns
+# This is not a valid basic GNU regular expression.
+\x01\x10\x01|\)\x10\x01\x01|0\x10\x01
diff --git a/usr/local/share/protocols/ncp.pat b/usr/local/share/protocols/ncp.pat
new file mode 100644
index 0000000..b4788a1
--- /dev/null
+++ b/usr/local/share/protocols/ncp.pat
@@ -0,0 +1,22 @@
+# NCP - Novell Core Protocol
+# Pattern attributes: good veryfast fast
+# Protocol groups: networking proprietary
+# Wiki: http://www.protocolinfo.org/wiki/NCP
+#
+# This pattern has been tested and is believed to work well.
+
+# ncp request
+# dmdt means Request
+# *any length
+#
+# *any reply buffer size
+# "" means service request
+# | \x17\x17 means create a service connection
+# | uu means destroy service connection
+
+# ncp reply
+# tncp means reply
+# 33 means service reply
+
+ncp
+^(dmdt.*\x01.*(""|\x11\x11|uu)|tncp.*33)
diff --git a/usr/local/share/protocols/netbios.pat b/usr/local/share/protocols/netbios.pat
new file mode 100644
index 0000000..8e90074
--- /dev/null
+++ b/usr/local/share/protocols/netbios.pat
@@ -0,0 +1,28 @@
+# NetBIOS - Network Basic Input Output System
+# Pattern attributes: marginal notsofast notsofast
+# Protocol groups: networking ietf_internet_standard proprietary
+# Wiki: http://www.protocolinfo.org/wiki/NetBIOS
+#
+# As mentioned in smb.pat:
+#
+# "This protocol is sometimes also referred to as the Common Internet File
+# System (CIFS), LanManager or NetBIOS protocol." -- "man samba"
+#
+# Actually, SMB is a higher level protocol than NetBIOS. However, the
+# NetBIOS header is only 4 bytes: not much to match on.
+#
+# http://www.ubiqx.org/cifs/SMB.html
+# See also RFCs 1001 and 1002.
+#
+# This pattern attempts to match the (Session layer) NetBIOS Session request.
+# If sucessful, you may be able to match NetBIOS several packets earlier
+# than if you just waited for the easier-to-match SMB header.
+#
+# This pattern is untested.
+
+netbios
+# session request byte, three bytes of flags and length. Then
+# there should be a big mess of letters between A and P which represent
+# the NetBIOS names of the involved computers (with a null between them).
+# (40ish here, damn this regexp implementation and its lack of {40,})
+\x81.?.?.[A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P][A-P]
diff --git a/usr/local/share/protocols/nntp.pat b/usr/local/share/protocols/nntp.pat
new file mode 100644
index 0000000..769c8a5
--- /dev/null
+++ b/usr/local/share/protocols/nntp.pat
@@ -0,0 +1,20 @@
+# NNTP - Network News Transfer Protocol - RFCs 977 and 2980
+# Pattern attributes: good veryfast fast
+# Protocol groups: ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/NNTP
+#
+# usually runs on port 119
+
+# This pattern is tested and is believed to work well (but could use
+# more testing).
+
+nntp
+# matches authorized login
+# OR
+# matches unauthorized login if the server says "news" after 200/201
+# (Half of the 2 servers I tested did :-), but they both required authorization
+# so it's quite possible that this pattern will miss some nntp traffic.)
+^(20[01][\x09-\x0d -~]*AUTHINFO USER|20[01][\x09-\x0d -~]*news)
+
+# same thing, slightly more accurate, but 100+ times slower
+#^20[01][\x09-\x0d -~]*\x0d\x0a[\x09-\x0d -~]*AUTHINFO USER|20[01][\x09-\x0d -~]*news
diff --git a/usr/local/share/protocols/ntp.pat b/usr/local/share/protocols/ntp.pat
new file mode 100644
index 0000000..a24fb05
--- /dev/null
+++ b/usr/local/share/protocols/ntp.pat
@@ -0,0 +1,16 @@
+# (S)NTP - (Simple) Network Time Protocol - RFCs 1305 and 2030
+# Pattern attributes: good fast fast overmatch
+# Protocol groups: time_synchronization ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/NTP
+#
+# This pattern is tested and is believed to work.
+
+# client|server
+# Requires the server's timestamp to be in the present or future (of 2005).
+# Tested with ntpdate on Linux.
+# Assumes version 2, 3 or 4.
+
+# Note that ntp packets are always 48 bytes, so you should match on that too.
+
+ntp
+^([\x13\x1b\x23\xd3\xdb\xe3]|[\x14\x1c$].......?.?.?.?.?.?.?.?.?[\xc6-\xff])
diff --git a/usr/local/share/protocols/openft.pat b/usr/local/share/protocols/openft.pat
new file mode 100644
index 0000000..f81499a
--- /dev/null
+++ b/usr/local/share/protocols/openft.pat
@@ -0,0 +1,12 @@
+# OpenFT - P2P filesharing (implemented in giFT library)
+# Pattern attributes: good fast notsofast
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/OpenFT
+
+# Ben Efros <ben AT xgendev.com> says:
+# "This pattern identifies openFT P2P transfers fine. openFT is part of giFT
+# and is a pretty large p2p network. I would describe this pattern as pretty
+# weak, but it works for the giFT-based clients I've used."
+
+openft
+x-openftalias: [-)(0-9a-z ~.]
diff --git a/usr/local/share/protocols/pcanywhere.pat b/usr/local/share/protocols/pcanywhere.pat
new file mode 100644
index 0000000..86dae6b
--- /dev/null
+++ b/usr/local/share/protocols/pcanywhere.pat
@@ -0,0 +1,11 @@
+# pcAnywhere - Symantec remote access program
+# Pattern attributes: marginal veryfast fast
+# Protocol groups: remote_access proprietary
+# Wiki: http://www.protocolinfo.org/wiki/PcAnywhere
+
+# This is completely untested!
+# See http://www.unixwiz.net/tools/pcascan.txt
+
+pcanywhere
+# I think this only matches queries and not the bulk of the traffic!
+^(nq|st)$
diff --git a/usr/local/share/protocols/poco.pat b/usr/local/share/protocols/poco.pat
new file mode 100644
index 0000000..2bcf66d
--- /dev/null
+++ b/usr/local/share/protocols/poco.pat
@@ -0,0 +1,11 @@
+# POCO and PP365 - Chinese P2P filesharing - http://pp365.com http://poco.cn
+# Pattern attributes: ok veryfast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Poco
+#
+# The author of this pattern says it works, but this is unconfirmed.
+# Written by www.routerclub.com wsgtrsys.
+
+poco
+^\x80\x94\x0a\x01....\x1f\x9e
+
diff --git a/usr/local/share/protocols/pop3.pat b/usr/local/share/protocols/pop3.pat
new file mode 100644
index 0000000..b3d76e2
--- /dev/null
+++ b/usr/local/share/protocols/pop3.pat
@@ -0,0 +1,49 @@
+# POP3 - Post Office Protocol version 3 (popular e-mail protocol) - RFC 1939
+# Pattern attributes: great veryfast fast
+# Protocol groups: mail ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/POP
+#
+# This pattern has been tested somewhat.
+
+# this is a difficult protocol to match because of the relative lack of
+# distinguishing information. Read on.
+pop3
+
+# this the most conservative pattern. It should definitely work.
+#^(\+ok|-err)
+
+# this pattern assumes that the server says _something_ after +ok or -err
+# I think this is probably the way to go.
+^(\+ok |-err )
+
+# more that 90% of servers seem to say "pop" after "+ok", but not all.
+#^(\+ok .*pop)
+
+# Here's another tack. I think this is my second favorite.
+#^(\+ok [\x09-\x0d -~]*(ready|hello|pop|starting)|-err [\x09-\x0d -~]*(invalid|unknown|unimplemented|unrecognized|command))
+
+# this matches the server saying "you have N messages that are M bytes",
+# which the client probably asks for early in the session (not tested)
+#\+ok [0-9]+ [0-9]+
+
+# some sample servers:
+# RFC example: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
+# mail.dreamhost.com: +OK Hello there.
+# pop.carleton.edu: +OK POP3D(*) Server PMDFV6.2.2 at Fri, 12 Sep 2003 19:28:10 -0500 (CDT) (APOP disabled)
+# mail.earthlink.net: +OK NGPopper vEL_4_38 at earthlink.net ready <25509.1063412951@falcon>
+# *.email.umn.edu: +OK Cubic Circle's v1.22 1998/04/11 POP3 ready <7d1e0000da67623f@aquamarine.tc.umn.edu>
+# mail.yale.edu: +OK POP3 pantheon-po01 v2002.81 server ready
+# mail.gustavus.edu: +OK POP3 solen v2001.78 server ready
+# mail.reed.edu: +OK POP3 letra.reed.edu v2002.81 server ready
+# mail.bowdoin.edu: +OK mail.bowdoin.edu POP3 service (iPlanet Messaging Server 5.2 HotFix 1.15 (built Apr 28 2003))
+# pop.colby.edu: +OK Qpopper (version 4.0.5) at basalt starting.
+# mail.mac.com: +OK Netscape Messaging Multiplexor ready
+
+# various error strings:
+#-ERR Invalid command.
+#-ERR invalid command
+#-ERR unimplemented
+#-ERR Invalid command, try one of: USER name, PASS string, QUIT
+#-ERR Unknown AUTHORIZATION state command
+#-ERR Unrecognized command
+#-ERR Unknown command: "sadf'".
diff --git a/usr/local/share/protocols/qq.pat b/usr/local/share/protocols/qq.pat
new file mode 100644
index 0000000..7689439
--- /dev/null
+++ b/usr/local/share/protocols/qq.pat
@@ -0,0 +1,25 @@
+# Tencent QQ Protocol - Chinese instant messenger protocol - http://www.qq.com
+# Pattern attributes: good fast fast
+# Protocol groups: chat
+# Wiki: http://www.protocolinfo.org/wiki/QQ
+#
+# Over six million people use QQ in China, according to wsgtrsys.
+#
+# This pattern has been tested and is believed to work well.
+#
+# QQ uses three (two?) methods to connect to server(s?).
+# one is udp, and another is tcp
+# udp protocol: the first byte is 02 and last byte is 03
+# tcp protocol: the second byte is 02 and last byte is 03
+# tony on protocolinfo.org says that now the *third* byte is 02:
+# "but when I tested on my PC, I found that when qq2007/qq2008
+# use tcp protocol, the third byte instead of the second is always 02.
+#
+# So the QQ protocol changed again, or I have made a mistake, I wonder
+# that."
+# So now the pattern allows any of the first three bytes to be 02. Delete
+# one of the ".?" to restore to the old behaviour.
+# pattern written by www.routerclub.com wsgtrsys
+
+qq
+^.?.?\x02.+\x03$
diff --git a/usr/local/share/protocols/quake-halflife.pat b/usr/local/share/protocols/quake-halflife.pat
new file mode 100644
index 0000000..7e2b537
--- /dev/null
+++ b/usr/local/share/protocols/quake-halflife.pat
@@ -0,0 +1,26 @@
+# Half Life 1 engine games (HL 1, Quake 2/3/World, Counterstrike 1.6, etc.)
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Half-Life http://www.protocolinfo.org/wiki/Counter-Strike http://www.protocolinfo.org/wiki/Day_of_Defeat
+#
+# Contributed by Laurens Blankers <laurens AT blankersfamily.com>, who says:
+#
+# This pattern has been tested with QuakeWorld (2.30), Quake 2 (3.20),
+# Quake 3 (1.32), and Half-life (1.1.1.0). But may also work on other
+# games based on the Quake engine.
+#
+# Clayton Macleod <cherrytwist A gmail.com> says:
+# [This should match] Counter-Strike v1.6, [...] the slightly updated
+# Counter-Strike: Condition Zero, and the game Day Of Defeat, Team
+# Fortress Classic, Deathmatch Classic, Ricochet, Half-Life [1] Deathmatch,
+# and I imagine all the other 3rd party mods that also use this engine
+# will match that pattern.
+
+quake-halflife
+# All quake (like) protocols start with 4x 0xFF. Then the client either
+# issues getinfo or getchallenge.
+^\xff\xff\xff\xffget(info|challenge)
+
+# A previous quake pattern allowed the connection to start with only 2 bytes
+# of 0xFF. This doesn't seem to ever happen, but we should keep an eye out
+# for it.
diff --git a/usr/local/share/protocols/quake1.pat b/usr/local/share/protocols/quake1.pat
new file mode 100644
index 0000000..18e0ca0
--- /dev/null
+++ b/usr/local/share/protocols/quake1.pat
@@ -0,0 +1,18 @@
+# Quake 1 - A popular computer game.
+# Pattern attributes: marginal veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Quake
+#
+# This pattern is untested and unconfirmed.
+
+# Info taken from http://www.gamers.org/dEngine/quake/QDP/qnp.html,
+# which says that it "is incomplete, inaccurate and only applies to
+# versions 0.91, 0.92, 1.00 and 1.01 of QUAKE"
+
+quake1
+# Connection request: 80 00 00 0c 01 51 55 41 4b 45 00 03
+# \x80 = control packet.
+# \x0c = packet length
+# \x01 = CCREQ_CONNECT
+# \x03 = protocol version (3 == 0.91, 0.92, 1.00, 1.01)
+^\x80\x0c\x01quake\x03
diff --git a/usr/local/share/protocols/radmin.pat b/usr/local/share/protocols/radmin.pat
new file mode 100644
index 0000000..52ff6e0
--- /dev/null
+++ b/usr/local/share/protocols/radmin.pat
@@ -0,0 +1,16 @@
+# Famatech Remote Administrator - remote desktop for MS Windows
+# Pattern attributes: ok veryfast fast
+# Protocol groups: remote_access proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Radmin
+#
+# This pattern has been verified with Radmin v1.1 and v3.0beta on Win2000/XP
+# It has only been tested between a single pair of computers.
+
+# The first packet of every TCP stream appears to be either one of:
+#
+# 01 00 00 00 01 00 00 00 08 08
+# 01 00 00 00 01 00 00 00 1b 1b
+
+radmin
+^\x01\x01(\x08\x08|\x1b\x1b)$
+
diff --git a/usr/local/share/protocols/rdp.pat b/usr/local/share/protocols/rdp.pat
new file mode 100644
index 0000000..e10a81d
--- /dev/null
+++ b/usr/local/share/protocols/rdp.pat
@@ -0,0 +1,19 @@
+# RDP - Remote Desktop Protocol (used in Windows Terminal Services)
+# Pattern attributes: ok notsofast notsofast
+# Protocol groups: remote_access proprietary
+# Wiki: http://www.protocolinfo.org/wiki/RDP
+#
+# This pattern was submitted by Michael Leong. It has been tested under the
+# following conditions: "WinXP Pro with all the patches, rdesktop server
+# running on port 7000 instead of 3389 --> WinXP Pro Remote Desktop Client."
+# Also tested is WinXP to Win 2000 Server.
+
+# At least one other person has reported it to work as well.
+
+rdp
+rdpdr.*cliprdr.*rdpsnd
+
+# Old pattern, submitted by Daniel Weatherford.
+# rdpdr.*cliprdp.*rdpsnd
+
+
diff --git a/usr/local/share/protocols/replaytv-ivs.pat b/usr/local/share/protocols/replaytv-ivs.pat
new file mode 100644
index 0000000..4d44b0f
--- /dev/null
+++ b/usr/local/share/protocols/replaytv-ivs.pat
@@ -0,0 +1,10 @@
+# ReplayTV Internet Video Sharing - Digital Video Recorder - http://replaytv.com
+# Pattern attributes: good veryfast fast
+# Protocol groups:
+# Wiki: http://www.protocolinfo.org/wiki/ReplayTV
+#
+# Pattern by jm 409 at hot mail dot com, who says that this one "worked best".
+
+replaytv-ivs
+^(get /ivs-IVSGetFileChunk|http/(0\.9|1\.0|1\.1) [1-5][0-9][0-9] [\x09-\x0d -~]*\x23\x23\x23\x23\x23REPLAY_CHUNK_START\x23\x23\x23\x23\x23)
+
diff --git a/usr/local/share/protocols/rlogin.pat b/usr/local/share/protocols/rlogin.pat
new file mode 100644
index 0000000..92f3735
--- /dev/null
+++ b/usr/local/share/protocols/rlogin.pat
@@ -0,0 +1,18 @@
+# rlogin - remote login - RFC 1282
+# Pattern attributes: ok veryfast fast
+# Protocol groups: remote_access ietf_rfc_documented
+# Wiki: http://www.protocolinfo.org/wiki/Rlogin
+#
+# usually runs on port 443
+#
+# This pattern is untested.
+
+rlogin
+# At least three characters (user name, user name, terminal type),
+# the first of which could be the first character of a user name, a
+# slash, then a terminal speed. (Assumes that usernames and terminal
+# types are alphanumeric only. I'm sure there are usernames like
+# "straitm-47" out there, but it's not common.) All terminal speeds
+# I know of end in two zeros and are between 3 and 6 digits long.
+# This pattern is uncomfortably general.
+^[a-z][a-z0-9][a-z0-9]+/[1-9][0-9]?[0-9]?[0-9]?00
diff --git a/usr/local/share/protocols/rtp.pat b/usr/local/share/protocols/rtp.pat
new file mode 100644
index 0000000..d808e1e
--- /dev/null
+++ b/usr/local/share/protocols/rtp.pat
@@ -0,0 +1,40 @@
+# RTP - Real-time Transport Protocol - RFC 3550
+# Pattern attributes: marginal overmatch undermatch veryfast fast
+# Protocol groups: streaming_video ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/RTP
+#
+# RTP headers are *very* short and compact. They have almost nothing in
+# them that can be matched by l7-filter. If you want to match them
+# along with their associated SIP packets, I think the best way might be
+# to set up some iptables rules that watch for SIP packets and then also
+# match any other UDP packets that are going between the same two IP
+# addresses.
+#
+# However, I will attempt a pattern anyway. This is UNTESTED!
+#
+# I think we can count on the first bit being 1 and the second bit being
+# 0 (meaning protocol version 2). The next two bits could go either way,
+# but in the example I've seen, they are zero, so I'll assume they are
+# usually zero. The next four bits are a count of "contributing source
+# identifiers". I'm not sure how big that could be, but in the example
+# I've seen, they're zero, so I'll assume they're usually zero. So that
+# gives us ^\x80. The marker bit that comes next is probably zero for
+# the first packet, although that's not a sure thing. Next is the
+# payload type, 7 bits that might usually only take a few values, but
+# maybe not. In the example I've seen, it's zero, which (with a zero
+# marker bit) means it looks to l7-filter like it's not there at all.
+# The rest of the header is random numbers (sequence number, timestamp,
+# synchronization source identifier), so that's no help at all.
+#
+# I think the best we could do is to watch to see if several \x80 bytes
+# come in with a small number of bytes between them. This makes all the
+# above assumptions and also assumes that the first packet has no
+# payload and not too much trailing gargage. So this will definitely not
+# work all the time. It clearly also might match other stuff.
+
+rtp
+^\x80......?.?.?.?.?.?.?.?.?.?.?.?.?\x80
+
+# Might also try this. It's a bit slower (one packet and not too much extra
+# regexec load) and a bit more accurate:
+#^\x80......?.?.?.?.?.?.?.?.?.?.?.?.?\x80.*\x80
diff --git a/usr/local/share/protocols/rtsp.pat b/usr/local/share/protocols/rtsp.pat
new file mode 100644
index 0000000..a5f309c
--- /dev/null
+++ b/usr/local/share/protocols/rtsp.pat
@@ -0,0 +1,14 @@
+# RTSP - Real Time Streaming Protocol - http://www.rtsp.org - RFC 2326
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: streaming_video ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/RTSP
+#
+# usually runs on port 554
+#
+# To take full advantage of this pattern, please see the RTSP connection
+# tracking patch to the Linux kernel referenced at the above site.
+#
+# This pattern has been tested and is believed to work well.
+
+rtsp
+rtsp/1.0 200 ok
diff --git a/usr/local/share/protocols/shoutcast.pat b/usr/local/share/protocols/shoutcast.pat
new file mode 100644
index 0000000..6ae0824
--- /dev/null
+++ b/usr/local/share/protocols/shoutcast.pat
@@ -0,0 +1,26 @@
+# Shoutcast and Icecast - streaming audio
+# Pattern attributes: good slow notsofast
+# Protocol groups: streaming_audio
+# Wiki: http://www.protocolinfo.org/wiki/Icecast
+#
+# usually runs on port 80
+#
+# Original pattern contributed by Deepak Seshadri <dseshadri AT
+# broadbandmaritime.com> who says "The difference between [Shoutcast and
+# Icecast] is not clearly mentioned anywhere. According to this
+# document, my pattern would filter JUST shoutcast packets."
+#
+# Should now match both Shoutcast and Icecast. Tested with Winamp (in
+# 2005) and Totem using streams at dir.xiph.org (in Nov 2007).
+#
+# http://sander.vanzoest.com/talks/2002/audio_and_apache/
+# http://forums.radiotoolbox.com/viewtopic.php?t=74
+# http://www.icecast.org
+
+shoutcast
+# The first branch looks for an HTTP request that looks like it is asking for
+# a SHOUTcast stream. The second branch looks for the server's reply. However,
+# some (newer?) servers answer with "http/1.0 200 OK", not "ICY 200 OK", so
+# this will not work.
+# This pattern was discovered using Ethereal.
+^get /.*icy-metadata:1|icy [1-5][0-9][0-9] [\x09-\x0d -~]*(content-type:audio|icy-)
diff --git a/usr/local/share/protocols/sip.pat b/usr/local/share/protocols/sip.pat
new file mode 100644
index 0000000..3782e33
--- /dev/null
+++ b/usr/local/share/protocols/sip.pat
@@ -0,0 +1,18 @@
+# SIP - Session Initiation Protocol - Internet telephony - RFC 3261
+# Pattern attributes: ok fast fast
+# Protocol groups: voip ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/SIP
+#
+# This pattern has been tested with the Ubiquity SIP user agent.
+#
+# Thanks to Ankit Desai for this pattern.
+#
+# SIP typically uses port 5060.
+#
+# This pattern is based on SIP request format as per RFC 3261. I'm not
+# sure about the version part. The RFC doesn't say anything about it, so
+# I have allowed version ranging from 0.x to 2.x.
+
+#Request-Line = Method SP Request-URI SP SIP-Version CRLF
+sip
+^(invite|register|cancel) sip[\x09-\x0d -~]*sip/[0-2]\.[0-9]
diff --git a/usr/local/share/protocols/skypeout.pat b/usr/local/share/protocols/skypeout.pat
new file mode 100644
index 0000000..a6b6ba7
--- /dev/null
+++ b/usr/local/share/protocols/skypeout.pat
@@ -0,0 +1,49 @@
+# Skype to phone - UDP voice call (program to POTS phone) - http://skype.com
+# Pattern attributes: ok slow notsofast overmatch
+# Protocol groups: voip p2p proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Skype
+
+# Thanks to Myles Uyema, mylesuyema AT gmail.com
+
+# Taken using Ethereal traces of Windows Skype v1.2.037, same in v1.2.0.18_API
+#
+# Skype will attempt to use the same UDP port for all its connections as
+# configured in its options. However, this is a random port by default.
+# Skype has some preference for ports 80 and 443.
+#
+# Example sessions:
+#
+#SkypeOut <USA phone number>
+#c6 5c bf 41 8e 8d d6 d2 08 <-- this is sometimes as short as 1 byte and
+#c6 5c bf 41 8e 8d d6 d2 08 <-- sometimes as long as 9 (or more?)
+#00 6b 2c f5 87 f1 06
+#00 6b 2c f5 87 f1 06
+#00 6b 2c f5 36 ea 85
+#00 6b 2c f5 36 ea 85
+#00 6b 2c f5 57 27 d4
+#00 6b 2c f5 57 27 d4
+#00 6b 2c f5 43 5b 00
+#00 6b 2c f5 43 5b 00
+#
+#SkypeOut <USA phone number>
+#7e 4f e5 b8
+#7e 4f e5 b8
+#00 6b 88 61 80 52 93
+#00 6b 88 61 80 52 93
+#00 6b 88 61 1a 09 e9
+#00 6b 88 61 1a 09 e9
+#00 6b 88 61 47 43 c4
+#00 6b 88 61 47 43 c4
+
+skypeout
+
+# Scary. Our regular expressions suck. This is a prime candidate for
+# some sort of a scheme to support two different regular expressions
+# when there's a major difference between what the two libraries allow.
+# For the Henry Spencer library, there's not much that can be done
+# except requiring that we see the same byte twice.
+
+# This matches about %4 of random streams and 13% of printable random streams
+
+# This is slow, but not as bad as you might think.
+^(\x01.?.?.?.?.?.?.?.?\x01|\x02.?.?.?.?.?.?.?.?\x02|\x03.?.?.?.?.?.?.?.?\x03|\x04.?.?.?.?.?.?.?.?\x04|\x05.?.?.?.?.?.?.?.?\x05|\x06.?.?.?.?.?.?.?.?\x06|\x07.?.?.?.?.?.?.?.?\x07|\x08.?.?.?.?.?.?.?.?\x08|\x09.?.?.?.?.?.?.?.?\x09|\x0a.?.?.?.?.?.?.?.?\x0a|\x0b.?.?.?.?.?.?.?.?\x0b|\x0c.?.?.?.?.?.?.?.?\x0c|\x0d.?.?.?.?.?.?.?.?\x0d|\x0e.?.?.?.?.?.?.?.?\x0e|\x0f.?.?.?.?.?.?.?.?\x0f|\x10.?.?.?.?.?.?.?.?\x10|\x11.?.?.?.?.?.?.?.?\x11|\x12.?.?.?.?.?.?.?.?\x12|\x13.?.?.?.?.?.?.?.?\x13|\x14.?.?.?.?.?.?.?.?\x14|\x15.?.?.?.?.?.?.?.?\x15|\x16.?.?.?.?.?.?.?.?\x16|\x17.?.?.?.?.?.?.?.?\x17|\x18.?.?.?.?.?.?.?.?\x18|\x19.?.?.?.?.?.?.?.?\x19|\x1a.?.?.?.?.?.?.?.?\x1a|\x1b.?.?.?.?.?.?.?.?\x1b|\x1c.?.?.?.?.?.?.?.?\x1c|\x1d.?.?.?.?.?.?.?.?\x1d|\x1e.?.?.?.?.?.?.?.?\x1e|\x1f.?.?.?.?.?.?.?.?\x1f|\x20.?.?.?.?.?.?.?.?\x20|\x21.?.?.?.?.?.?.?.?\x21|\x22.?.?.?.?.?.?.?.?\x22|\x23.?.?.?.?.?.?.?.?\x23|\$.?.?.?.?.?.?.?.?\$|\x25.?.?.?.?.?.?.?.?\x25|\x26.?.?.?.?.?.?.?.?\x26|\x27.?.?.?.?.?.?.?.?\x27|\(.?.?.?.?.?.?.?.?\(|\).?.?.?.?.?.?.?.?\)|\*.?.?.?.?.?.?.?.?\*|\+.?.?.?.?.?.?.?.?\+|\x2c.?.?.?.?.?.?.?.?\x2c|\x2d.?.?.?.?.?.?.?.?\x2d|\..?.?.?.?.?.?.?.?\.|\x2f.?.?.?.?.?.?.?.?\x2f|\x30.?.?.?.?.?.?.?.?\x30|\x31.?.?.?.?.?.?.?.?\x31|\x32.?.?.?.?.?.?.?.?\x32|\x33.?.?.?.?.?.?.?.?\x33|\x34.?.?.?.?.?.?.?.?\x34|\x35.?.?.?.?.?.?.?.?\x35|\x36.?.?.?.?.?.?.?.?\x36|\x37.?.?.?.?.?.?.?.?\x37|\x38.?.?.?.?.?.?.?.?\x38|\x39.?.?.?.?.?.?.?.?\x39|\x3a.?.?.?.?.?.?.?.?\x3a|\x3b.?.?.?.?.?.?.?.?\x3b|\x3c.?.?.?.?.?.?.?.?\x3c|\x3d.?.?.?.?.?.?.?.?\x3d|\x3e.?.?.?.?.?.?.?.?\x3e|\?.?.?.?.?.?.?.?.?\?|\x40.?.?.?.?.?.?.?.?\x40|\x41.?.?.?.?.?.?.?.?\x41|\x42.?.?.?.?.?.?.?.?\x42|\x43.?.?.?.?.?.?.?.?\x43|\x44.?.?.?.?.?.?.?.?\x44|\x45.?.?.?.?.?.?.?.?\x45|\x46.?.?.?.?.?.?.?.?\x46|\x47.?.?.?.?.?.?.?.?\x47|\x48.?.?.?.?.?.?.?.?\x48|\x49.?.?.?.?.?.?.?.?\x49|\x4a.?.?.?.?.?.?.?.?\x4a|\x4b.?.?.?.?.?.?.?.?\x4b|\x4c.?.?.?.?.?.?.?.?\x4c|\x4d.?.?.?.?.?.?.?.?\x4d|\x4e.?.?.?.?.?.?.?.?\x4e|\x4f.?.?.?.?.?.?.?.?\x4f|\x50.?.?.?.?.?.?.?.?\x50|\x51.?.?.?.?.?.?.?.?\x51|\x52.?.?.?.?.?.?.?.?\x52|\x53.?.?.?.?.?.?.?.?\x53|\x54.?.?.?.?.?.?.?.?\x54|\x55.?.?.?.?.?.?.?.?\x55|\x56.?.?.?.?.?.?.?.?\x56|\x57.?.?.?.?.?.?.?.?\x57|\x58.?.?.?.?.?.?.?.?\x58|\x59.?.?.?.?.?.?.?.?\x59|\x5a.?.?.?.?.?.?.?.?\x5a|\[.?.?.?.?.?.?.?.?\[|\\.?.?.?.?.?.?.?.?\\|\].?.?.?.?.?.?.?.?\]|\^.?.?.?.?.?.?.?.?\^|\x5f.?.?.?.?.?.?.?.?\x5f|\x60.?.?.?.?.?.?.?.?\x60|\x61.?.?.?.?.?.?.?.?\x61|\x62.?.?.?.?.?.?.?.?\x62|\x63.?.?.?.?.?.?.?.?\x63|\x64.?.?.?.?.?.?.?.?\x64|\x65.?.?.?.?.?.?.?.?\x65|\x66.?.?.?.?.?.?.?.?\x66|\x67.?.?.?.?.?.?.?.?\x67|\x68.?.?.?.?.?.?.?.?\x68|\x69.?.?.?.?.?.?.?.?\x69|\x6a.?.?.?.?.?.?.?.?\x6a|\x6b.?.?.?.?.?.?.?.?\x6b|\x6c.?.?.?.?.?.?.?.?\x6c|\x6d.?.?.?.?.?.?.?.?\x6d|\x6e.?.?.?.?.?.?.?.?\x6e|\x6f.?.?.?.?.?.?.?.?\x6f|\x70.?.?.?.?.?.?.?.?\x70|\x71.?.?.?.?.?.?.?.?\x71|\x72.?.?.?.?.?.?.?.?\x72|\x73.?.?.?.?.?.?.?.?\x73|\x74.?.?.?.?.?.?.?.?\x74|\x75.?.?.?.?.?.?.?.?\x75|\x76.?.?.?.?.?.?.?.?\x76|\x77.?.?.?.?.?.?.?.?\x77|\x78.?.?.?.?.?.?.?.?\x78|\x79.?.?.?.?.?.?.?.?\x79|\x7a.?.?.?.?.?.?.?.?\x7a|\{.?.?.?.?.?.?.?.?\{|\|.?.?.?.?.?.?.?.?\||\}.?.?.?.?.?.?.?.?\}|\x7e.?.?.?.?.?.?.?.?\x7e|\x7f.?.?.?.?.?.?.?.?\x7f|\x80.?.?.?.?.?.?.?.?\x80|\x81.?.?.?.?.?.?.?.?\x81|\x82.?.?.?.?.?.?.?.?\x82|\x83.?.?.?.?.?.?.?.?\x83|\x84.?.?.?.?.?.?.?.?\x84|\x85.?.?.?.?.?.?.?.?\x85|\x86.?.?.?.?.?.?.?.?\x86|\x87.?.?.?.?.?.?.?.?\x87|\x88.?.?.?.?.?.?.?.?\x88|\x89.?.?.?.?.?.?.?.?\x89|\x8a.?.?.?.?.?.?.?.?\x8a|\x8b.?.?.?.?.?.?.?.?\x8b|\x8c.?.?.?.?.?.?.?.?\x8c|\x8d.?.?.?.?.?.?.?.?\x8d|\x8e.?.?.?.?.?.?.?.?\x8e|\x8f.?.?.?.?.?.?.?.?\x8f|\x90.?.?.?.?.?.?.?.?\x90|\x91.?.?.?.?.?.?.?.?\x91|\x92.?.?.?.?.?.?.?.?\x92|\x93.?.?.?.?.?.?.?.?\x93|\x94.?.?.?.?.?.?.?.?\x94|\x95.?.?.?.?.?.?.?.?\x95|\x96.?.?.?.?.?.?.?.?\x96|\x97.?.?.?.?.?.?.?.?\x97|\x98.?.?.?.?.?.?.?.?\x98|\x99.?.?.?.?.?.?.?.?\x99|\x9a.?.?.?.?.?.?.?.?\x9a|\x9b.?.?.?.?.?.?.?.?\x9b|\x9c.?.?.?.?.?.?.?.?\x9c|\x9d.?.?.?.?.?.?.?.?\x9d|\x9e.?.?.?.?.?.?.?.?\x9e|\x9f.?.?.?.?.?.?.?.?\x9f|\xa0.?.?.?.?.?.?.?.?\xa0|\xa1.?.?.?.?.?.?.?.?\xa1|\xa2.?.?.?.?.?.?.?.?\xa2|\xa3.?.?.?.?.?.?.?.?\xa3|\xa4.?.?.?.?.?.?.?.?\xa4|\xa5.?.?.?.?.?.?.?.?\xa5|\xa6.?.?.?.?.?.?.?.?\xa6|\xa7.?.?.?.?.?.?.?.?\xa7|\xa8.?.?.?.?.?.?.?.?\xa8|\xa9.?.?.?.?.?.?.?.?\xa9|\xaa.?.?.?.?.?.?.?.?\xaa|\xab.?.?.?.?.?.?.?.?\xab|\xac.?.?.?.?.?.?.?.?\xac|\xad.?.?.?.?.?.?.?.?\xad|\xae.?.?.?.?.?.?.?.?\xae|\xaf.?.?.?.?.?.?.?.?\xaf|\xb0.?.?.?.?.?.?.?.?\xb0|\xb1.?.?.?.?.?.?.?.?\xb1|\xb2.?.?.?.?.?.?.?.?\xb2|\xb3.?.?.?.?.?.?.?.?\xb3|\xb4.?.?.?.?.?.?.?.?\xb4|\xb5.?.?.?.?.?.?.?.?\xb5|\xb6.?.?.?.?.?.?.?.?\xb6|\xb7.?.?.?.?.?.?.?.?\xb7|\xb8.?.?.?.?.?.?.?.?\xb8|\xb9.?.?.?.?.?.?.?.?\xb9|\xba.?.?.?.?.?.?.?.?\xba|\xbb.?.?.?.?.?.?.?.?\xbb|\xbc.?.?.?.?.?.?.?.?\xbc|\xbd.?.?.?.?.?.?.?.?\xbd|\xbe.?.?.?.?.?.?.?.?\xbe|\xbf.?.?.?.?.?.?.?.?\xbf|\xc0.?.?.?.?.?.?.?.?\xc0|\xc1.?.?.?.?.?.?.?.?\xc1|\xc2.?.?.?.?.?.?.?.?\xc2|\xc3.?.?.?.?.?.?.?.?\xc3|\xc4.?.?.?.?.?.?.?.?\xc4|\xc5.?.?.?.?.?.?.?.?\xc5|\xc6.?.?.?.?.?.?.?.?\xc6|\xc7.?.?.?.?.?.?.?.?\xc7|\xc8.?.?.?.?.?.?.?.?\xc8|\xc9.?.?.?.?.?.?.?.?\xc9|\xca.?.?.?.?.?.?.?.?\xca|\xcb.?.?.?.?.?.?.?.?\xcb|\xcc.?.?.?.?.?.?.?.?\xcc|\xcd.?.?.?.?.?.?.?.?\xcd|\xce.?.?.?.?.?.?.?.?\xce|\xcf.?.?.?.?.?.?.?.?\xcf|\xd0.?.?.?.?.?.?.?.?\xd0|\xd1.?.?.?.?.?.?.?.?\xd1|\xd2.?.?.?.?.?.?.?.?\xd2|\xd3.?.?.?.?.?.?.?.?\xd3|\xd4.?.?.?.?.?.?.?.?\xd4|\xd5.?.?.?.?.?.?.?.?\xd5|\xd6.?.?.?.?.?.?.?.?\xd6|\xd7.?.?.?.?.?.?.?.?\xd7|\xd8.?.?.?.?.?.?.?.?\xd8|\xd9.?.?.?.?.?.?.?.?\xd9|\xda.?.?.?.?.?.?.?.?\xda|\xdb.?.?.?.?.?.?.?.?\xdb|\xdc.?.?.?.?.?.?.?.?\xdc|\xdd.?.?.?.?.?.?.?.?\xdd|\xde.?.?.?.?.?.?.?.?\xde|\xdf.?.?.?.?.?.?.?.?\xdf|\xe0.?.?.?.?.?.?.?.?\xe0|\xe1.?.?.?.?.?.?.?.?\xe1|\xe2.?.?.?.?.?.?.?.?\xe2|\xe3.?.?.?.?.?.?.?.?\xe3|\xe4.?.?.?.?.?.?.?.?\xe4|\xe5.?.?.?.?.?.?.?.?\xe5|\xe6.?.?.?.?.?.?.?.?\xe6|\xe7.?.?.?.?.?.?.?.?\xe7|\xe8.?.?.?.?.?.?.?.?\xe8|\xe9.?.?.?.?.?.?.?.?\xe9|\xea.?.?.?.?.?.?.?.?\xea|\xeb.?.?.?.?.?.?.?.?\xeb|\xec.?.?.?.?.?.?.?.?\xec|\xed.?.?.?.?.?.?.?.?\xed|\xee.?.?.?.?.?.?.?.?\xee|\xef.?.?.?.?.?.?.?.?\xef|\xf0.?.?.?.?.?.?.?.?\xf0|\xf1.?.?.?.?.?.?.?.?\xf1|\xf2.?.?.?.?.?.?.?.?\xf2|\xf3.?.?.?.?.?.?.?.?\xf3|\xf4.?.?.?.?.?.?.?.?\xf4|\xf5.?.?.?.?.?.?.?.?\xf5|\xf6.?.?.?.?.?.?.?.?\xf6|\xf7.?.?.?.?.?.?.?.?\xf7|\xf8.?.?.?.?.?.?.?.?\xf8|\xf9.?.?.?.?.?.?.?.?\xf9|\xfa.?.?.?.?.?.?.?.?\xfa|\xfb.?.?.?.?.?.?.?.?\xfb|\xfc.?.?.?.?.?.?.?.?\xfc|\xfd.?.?.?.?.?.?.?.?\xfd|\xfe.?.?.?.?.?.?.?.?\xfe|\xff.?.?.?.?.?.?.?.?\xff)
diff --git a/usr/local/share/protocols/skypetoskype.pat b/usr/local/share/protocols/skypetoskype.pat
new file mode 100644
index 0000000..3649492
--- /dev/null
+++ b/usr/local/share/protocols/skypetoskype.pat
@@ -0,0 +1,13 @@
+# Skype to Skype - UDP voice call (program to program) - http://skype.com
+# Pattern attributes: ok veryfast fast overmatch
+# Protocol groups: voip p2p proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Skype
+
+# This matches at least some of the general chatter that occurs when the
+# user isn't doing anything as well as actual calls.
+# Thanks to Myles Uyema, mylesuyema AT gmail.com
+
+skypetoskype
+# require at least 16 bytes (my limited tests always get at least 18)
+^..\x02.............
+
diff --git a/usr/local/share/protocols/smb.pat b/usr/local/share/protocols/smb.pat
new file mode 100644
index 0000000..cdf0fe1
--- /dev/null
+++ b/usr/local/share/protocols/smb.pat
@@ -0,0 +1,18 @@
+# Samba/SMB - Server Message Block - Microsoft Windows filesharing
+# Pattern attributes: good fast notsofast
+# Protocol groups: document_retrieval networking proprietary
+# Wiki: http://www.protocolinfo.org/wiki/SMB
+#
+# "This protocol is sometimes also referred to as the Common Internet File
+# System (CIFS), LanManager or NetBIOS protocol." -- "man samba"
+#
+# Actually, SMB is a higher level protocol than NetBIOS. However, the
+# NetBIOS header is only 4 bytes: not much to match on.
+#
+# http://www.ubiqx.org/cifs/SMB.html
+#
+# This pattern is lightly tested.
+
+smb
+# matches a NEGOTIATE PROTOCOL or TRANSACTION REQUEST command
+\xffsmb[\x72\x25]
diff --git a/usr/local/share/protocols/smtp.pat b/usr/local/share/protocols/smtp.pat
new file mode 100644
index 0000000..eb98ae7
--- /dev/null
+++ b/usr/local/share/protocols/smtp.pat
@@ -0,0 +1,39 @@
+# SMTP - Simple Mail Transfer Protocol - RFC 2821 (See also RFC 1869)
+# Pattern attributes: great notsofast fast
+# Protocol groups: mail ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/SMTP
+#
+# usually runs on port 25
+#
+# This pattern has been tested and is believed to work well.
+
+# As usual, no text is required after "220", but all known servers have some
+# there. It (almost?) always has string "smtp" in it. The RFC examples
+# does not, so we match those too, just in case anyone has copied them
+# literally.
+#
+# Some examples:
+# 220 mail.stalker.com ESMTP CommuniGate Pro 4.1.3
+# 220 mail.vieodata.com ESMTP Merak 6.1.0; Mon, 15 Sep 2003 13:48:11 -0400
+# 220 mail.ut.caldera.com ESMTP
+# 220 persephone.pmail.gen.nz ESMTP server ready.
+# 220 smtp1.superb.net ESMTP
+# 220 mail.kerio.com Kerio MailServer 5.6.7 ESMTP ready
+# 220-mail.deerfield.com ESMTP VisNetic.MailServer.v6.0.9.0; Mon, 15 Sep 2003 13:4
+# 220 altn.com ESMTP MDaemon 6.8.5; Mon, 15 Sep 2003 12:46:42 -0500
+# 220 X1 NT-ESMTP Server ipsmin0165atl2.interland.net (IMail 6.06 73062-3)
+# 220 mail.icewarp.com ESMTP Merak 6.1.1; Mon, 15 Sep 2003 19:43:23 +0200
+# 220-mail.email-scan.com ESMTP
+# 220 smaug.dreamhost.com ESMTP
+# 220 kona.carleton.edu -- Server ESMTP (PMDF V6.2#30648)
+# 220 letra.reed.edu ESMTP Sendmail 8.12.9/8.12.9; Mon, 15 Sep 2003 10:35:57 -0700 (PDT)
+# 220-swan.mail.pas.earthlink.net ESMTP Exim 3.33 #1 Mon, 15 Sep 2003 10:32:15 -0700
+#
+# RFC examples:
+# 220 xyz.com Simple Mail Transfer Service Ready (RFC example)
+# 220 dbc.mtview.ca.us SMTP service ready
+
+smtp
+^220[\x09-\x0d -~]* (e?smtp|simple mail)
+userspace pattern=^220[\x09-\x0d -~]* (E?SMTP|[Ss]imple [Mm]ail)
+userspace flags=REG_NOSUB REG_EXTENDED
diff --git a/usr/local/share/protocols/snmp.pat b/usr/local/share/protocols/snmp.pat
new file mode 100644
index 0000000..5b88f03
--- /dev/null
+++ b/usr/local/share/protocols/snmp.pat
@@ -0,0 +1,18 @@
+# SNMP - Simple Network Management Protocol - RFC 1157
+# Pattern attributes: good veryfast fast superset
+# Protocol groups: networking ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/SNMP
+#
+# Usually runs on UDP ports 161 (monitoring) and 162 (traps).
+#
+# These filters match SNMPv1 packets without fail, and are made as
+# specific as possible not to match any ASN.1 encoded protocols. However
+# these could still be matched by other protocols that use ASN.1 encoding
+
+# Contributed by Goli SriSairam <goli_sai AT yahoo.com>
+
+# This pattern has been tested and is believed to work well.
+
+# All SNMPv1 traffic. See snmp-mon.pat and snmp-trap.pat for details.
+snmp
+^\x02\x01\x04.+([\xa0-\xa3]\x02[\x01-\x04].?.?.?.?\x02\x01.?\x02\x01.?\x30|\xa4\x06.+\x40\x04.?.?.?.?\x02\x01.?\x02\x01.?\x43)
diff --git a/usr/local/share/protocols/socks.pat b/usr/local/share/protocols/socks.pat
new file mode 100644
index 0000000..a7501a8
--- /dev/null
+++ b/usr/local/share/protocols/socks.pat
@@ -0,0 +1,31 @@
+# SOCKS Version 5 - Firewall traversal protocol - RFC 1928
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: networking ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/SOCKS
+#
+# Usually runs on port 1080
+# Also useful: http://www.iana.org/assignments/socks-methods
+#
+# We have had two reports that this pattern works.
+
+# method request, no private methods \x05[\x01-\x08]*
+# method reply, assumes sucess \x05[\x01-\x08]?
+# method dependent sub-negotiation .*
+# request, ipv4 only \x05[\x01-\x03][\x01\x03].*
+# reply \x05[\x01-\x08]?[\x01\x03].*
+
+# username/password method
+# u/p request, assuming reasonable usernames and passwords
+# \x05[\x02-\x10][a-z][a-z0-9\-]*[\x05-\x20][!-~]*
+# server reply
+# \x05
+
+# GSSAPI method
+# client initial token \x01\x01\x02.*
+# server reply \x01\x01\x02.*
+
+# any other method .* (all methods boil down to this until we have information
+# about all the commonly used ones)
+
+socks
+\x05[\x01-\x08]*\x05[\x01-\x08]?.*\x05[\x01-\x03][\x01\x03].*\x05[\x01-\x08]?[\x01\x03]
diff --git a/usr/local/share/protocols/soribada.pat b/usr/local/share/protocols/soribada.pat
new file mode 100644
index 0000000..a5da9fd
--- /dev/null
+++ b/usr/local/share/protocols/soribada.pat
@@ -0,0 +1,50 @@
+# Soribada - A Korean P2P filesharing program/protocol - http://www.soribada.com
+# Pattern attributes: good slow notsofast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Soribada
+
+# I am told that there are three versions of this protocol, the first no
+# longer being used. That would probably explain why incoming searches
+# have two different formats...
+
+# There are three parts to Soribada protocal:
+# 1: Ping/Pong to establish a relationship on the net (UDP with 2 useful bytes)
+# 2: Searching (in two formats) (UDP with two short easy to match starts)
+# 3: Download requests/transfers (TCP with an obvious first packet)
+
+# 1 -- Pings/Pongs:
+# Requester send 2 bytes and a 6 byte response is sent back.
+# \x10 for the first byte and \x14-\x16 for the second.
+# The response is the first byte (\x10) and the second byte incremented
+# by 1 (\x15-\x17).
+# No further communication happens between the hosts except for searches.
+# A regex match: ^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$
+# First Packet ---^^^^^^^^^^^^^^^
+# Second Packet -----------------^^^^^^^^^^^^^^^^^^^^^^^
+
+# 2 -- Search requests:
+# All searches are totally stateless and are only responded to if the user
+# actually has the file.
+# Both format start with a \x01 byte, have 3 "random bytes" and then 3 bytes
+# corasponding to one of two formats.
+# Format 1 is \x51\x3a\+ and format 2 is \x51\x32\x3a
+# A regex match: ^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a)
+
+# 3 -- Download requests:
+# All downloads start with "GETMP3\x0d\x0aFilename"
+# A regex match: ^GETMP3\x0d\x0aFilename
+
+soribada
+
+# This will match the second packet of two.
+# ^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$
+
+# Again, matching this is the end of the comunication.
+# ^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a)
+
+# This is the start of the transfer and an easy match
+#^GETMP3\x0d\x0aFilename
+
+# This will match everything including the udp packet portions
+^GETMP3\x0d\x0aFilename|^\x01.?.?.?(\x51\x3a\+|\x51\x32\x3a)|^\x10[\x14-\x16]\x10[\x15-\x17].?.?.?.?$
+
diff --git a/usr/local/share/protocols/soulseek.pat b/usr/local/share/protocols/soulseek.pat
new file mode 100644
index 0000000..4385141
--- /dev/null
+++ b/usr/local/share/protocols/soulseek.pat
@@ -0,0 +1,16 @@
+# Soulseek - P2P filesharing - http://slsknet.org
+# Pattern attributes: good fast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Soulseek
+#
+# All my tests show that this pattern is fast, but one user has reported that
+# it is slow. Your milage may vary.
+
+# This has been tested and works for "pierce firewall" commands and file
+# transfers. It does *not* match all the various sorts of chatter that go on,
+# such as searches, pings and whatnot.
+
+soulseek
+# (Pierce firewall: in theory the token could be 4 bytes, but the last two
+# seem to always be zero.|download: Peer Init)
+^(\x05..?|.\x01.[ -~]+\x01F..?.?.?.?.?.?.?)$
diff --git a/usr/local/share/protocols/ssdp.pat b/usr/local/share/protocols/ssdp.pat
new file mode 100644
index 0000000..db50362
--- /dev/null
+++ b/usr/local/share/protocols/ssdp.pat
@@ -0,0 +1,20 @@
+# SSDP - Simple Service Discovery Protocol - easy discovery of network devices
+# Pattern attributes: good slow notsofast
+# Protocol groups: networking ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/SSDP
+
+# This pattern was tested only by listening to a Linksys WRT54G. However,
+# I expect it works in general given the simplicity of the protocol.
+
+# SSDP packets should _always_ be sent to the multicast address
+# 239.255.255.250, making this pattern irrelevant. (Moreover, SSDP
+# packets should be resitricted to local networks that have plenty of
+# bandwidth.) However, Microsoft, as usual, has other ideas, so maybe
+# it could be useful. Can't hurt, anyway. :-)
+#
+# http://www.upnp.org/download/draft_cai_ssdp_v1_03.txt
+# http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/ssdp.asp
+
+ssdp
+^notify[\x09-\x0d ]\*[\x09-\x0d ]http/1\.1[\x09-\x0d -~]*ssdp:(alive|byebye)|^m-search[\x09-\x0d ]\*[\x09-\x0d ]http/1\.1[\x09-\x0d -~]*ssdp:discover
+
diff --git a/usr/local/share/protocols/ssh.pat b/usr/local/share/protocols/ssh.pat
new file mode 100644
index 0000000..adffe9e
--- /dev/null
+++ b/usr/local/share/protocols/ssh.pat
@@ -0,0 +1,16 @@
+# SSH - Secure SHell
+# Pattern attributes: great veryfast fast
+# Protocol groups: remote_access secure ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/SSH
+#
+# usually runs on port 22
+#
+# http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-22.txt
+#
+# This pattern has been tested and is believed to work well.
+
+ssh
+^ssh-[12]\.[0-9]
+
+# old pattern:
+# (diffie-hellman-group-exchange-sha1|diffie-hellman-group1-sha1.ssh-rsa|ssh-dssfaes128-cbc|3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes192-cbc|aes256-cbc|rijndael-cbc@lysator.liu.sefaes128-cbc|3des-cbc|blowfish-cbc|cast128-cbc|arcfour|aes192-cbc|aes256-cbc|rijndael-cbc@lysator.liu.seuhmac-md5|hmac-sha1|hmac-ripemd160)+
diff --git a/usr/local/share/protocols/ssl.pat b/usr/local/share/protocols/ssl.pat
new file mode 100644
index 0000000..a10589a1
--- /dev/null
+++ b/usr/local/share/protocols/ssl.pat
@@ -0,0 +1,15 @@
+# SSL and TLS - Secure Socket Layer / Transport Layer Security - RFC 2246
+# Pattern attributes: good notsofast fast superset
+# Protocol groups: secure ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/SSL
+#
+# Usually runs on port 443
+#
+# This is a superset of validcertssl. For it to match, it must be first.
+#
+# This pattern has been tested and is believed to work well.
+
+ssl
+# Server Hello with certificate | Client Hello
+# This allows SSL 3.X, which includes TLS 1.0, known internally as SSL 3.1
+^(.?.?\x16\x03.*\x16\x03|.?.?\x01\x03\x01?.*\x0b)
diff --git a/usr/local/share/protocols/stun.pat b/usr/local/share/protocols/stun.pat
new file mode 100644
index 0000000..5f0f58a
--- /dev/null
+++ b/usr/local/share/protocols/stun.pat
@@ -0,0 +1,45 @@
+# STUN - Simple Traversal of UDP Through NAT - RFC 3489
+# Pattern attributes: ok veryfast fast
+# Protocol groups: networking ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/STUN
+#
+# This pattern is untested as far as I know.
+
+# Wikipedia says: "The STUN server is contacted on UDP port 3478,
+# however the server will hint clients to perform tests on alternate IP
+# and port number too (STUN servers have two IP addresses). The RFC
+# states that this port and IP are arbitrary."
+
+stun
+# \x01 is a Binding Request. \x02 is a Shared Secret Request. Binding
+# Requests are, experimentally, exactly 20 Bytes with three NULL Bytes.
+# The first NULL is part of the two byte message type field. The other
+# two give the message length, zero. I'm guessing that Shared Secret
+# Requests are similar, but I have not checked. Please read the RFC and
+# do experiments to find out. All other message types are responses,
+# and so don't matter.
+#
+# The .? allows one of the Message Transaction ID Bytes to be \x00. If
+# two are \x00, it will fail. This will happen 0.37% of the time, since
+# the Message Transaction ID is supposed to be random. If this is
+# unacceptable to you, add another ? to reduce this to 0.020%, but be
+# aware of the increased possibility of false positives.
+^[\x01\x02]................?$
+
+# From my post to the mailing list:
+# http://sourceforge.net/mailarchive/message.php?msg_id=36787107
+#
+# This is a rather permissive pattern, but you can make it a little better
+# by combining it with another iptables rule that checks that the packet
+# data is exactly 20 Bytes. Of course, the second packet is longer, so
+# maybe that introduces more complications than benefits.
+#
+# If you're willing to wait until the second packet to make the
+# identification, you could use this:
+#
+# ^\x01................?\x01\x01
+#
+# or if the Message Length is always \x24 (I'm not sure it is from your
+# single example):
+#
+# ^\x01................?\x01\x01\x24
diff --git a/usr/local/share/protocols/subspace.pat b/usr/local/share/protocols/subspace.pat
new file mode 100644
index 0000000..57dabf1
--- /dev/null
+++ b/usr/local/share/protocols/subspace.pat
@@ -0,0 +1,20 @@
+# Subspace - 2D asteroids-style space game - http://sscentral.com
+# Pattern attributes: marginal veryfast fast
+# Protocol groups: game
+# Wiki: http://www.protocolinfo.org/wiki/Subspace
+#
+# By Myles Uyema <mylesuyema AT gmail.com>
+#
+# This pattern matches the initial 2 packets of the client-server
+# 'handshake' when joining a Zone.
+#
+# The first packet is an 8 byte UDP payload sent from client
+# 0x00 0x01 0x?? 0x?? 0x?? 0x?? 0x11
+# The next packet is a 12 byte UDP response from server
+# 0x00 0x10 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x?? 0x01 0x00
+#
+# l7-filter strips out the null bytes, leaving me with this pattern
+
+subspace
+^\x01....\x11\x10........\x01$
+
diff --git a/usr/local/share/protocols/subversion.pat b/usr/local/share/protocols/subversion.pat
new file mode 100644
index 0000000..cc5ec3b
--- /dev/null
+++ b/usr/local/share/protocols/subversion.pat
@@ -0,0 +1,12 @@
+# Subversion - a version control system
+# Pattern attributes: ok veryfast fast
+# Protocol groups: version_control open_source
+# Wiki: http://www.protocolinfo.org/wiki/Subversion
+#
+# This pattern is UNTESTED. (But it seems straightforward enough...)
+#
+# Subversion uses TCP port 3690 by default.
+
+subversion
+# This is not a valid basic GNU regular expression.
+^\( success \( 1 2 \(
diff --git a/usr/local/share/protocols/teamfortress2.pat b/usr/local/share/protocols/teamfortress2.pat
new file mode 100644
index 0000000..83fb960
--- /dev/null
+++ b/usr/local/share/protocols/teamfortress2.pat
@@ -0,0 +1,10 @@
+# Team Fortress 2 - network game - http://www.valvesoftware.com
+# Pattern attributes: good veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Team_Fortress
+#
+# Credits: Clayton Macleod <cherry twist at gmail dot com>
+# Jan Engelhardt <jengelh at computergmbh dot de>
+
+teamfortress2
+^\xff\xff\xff\xff.....*tfTeam Fortress
diff --git a/usr/local/share/protocols/teamspeak.pat b/usr/local/share/protocols/teamspeak.pat
new file mode 100644
index 0000000..e83569f
--- /dev/null
+++ b/usr/local/share/protocols/teamspeak.pat
@@ -0,0 +1,14 @@
+# TeamSpeak - VoIP application - http://goteamspeak.com
+# Pattern attributes: good veryfast fast
+# Protocol groups: voip proprietary
+# Wiki: http://www.protocolinfo.org/wiki/TeamSpeak
+#
+# This pattern has been tested by Matthew Strait and verified by packet
+# traces by at least two other people. The meaning of f4b303 is not
+# known, but it seems to appear in all first packets. This pattern only
+# matches the actual UDP voice traffic, not the TeamSpeak web interface
+# or "TCP query".
+
+teamspeak
+^\xf4\xbe\x03.*teamspeak
+
diff --git a/usr/local/share/protocols/telnet.pat b/usr/local/share/protocols/telnet.pat
new file mode 100644
index 0000000..a93d17d
--- /dev/null
+++ b/usr/local/share/protocols/telnet.pat
@@ -0,0 +1,15 @@
+# Telnet - Insecure remote login - RFC 854
+# Pattern attributes: good veryfast fast
+# Protocol groups: remote_access obsolete ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/Telnet
+#
+# Usually runs on port 23
+#
+# This pattern is lightly tested.
+
+telnet
+# Matches at least three IAC (Do|Will|Don't|Won't) commands in a row.
+# My telnet client sends 9 when I connect, so this should be fine.
+# This pattern could fail on a unchatty connection or it could be
+# matched by something non-telnet spewing a lot of stuff in the fb-ff range.
+^\xff[\xfb-\xfe].\xff[\xfb-\xfe].\xff[\xfb-\xfe]
diff --git a/usr/local/share/protocols/tesla.pat b/usr/local/share/protocols/tesla.pat
new file mode 100644
index 0000000..f9fdece
--- /dev/null
+++ b/usr/local/share/protocols/tesla.pat
@@ -0,0 +1,14 @@
+# Tesla Advanced Communication - P2P filesharing (?)
+# Pattern attributes: marginal slow notsofast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Tesla
+#
+# This pattern is untested!
+
+# This is lifted from http://oofle.com/filesharing.php?app=tesla
+# There is no explaination of what these numbers mean.
+# The above page says that the first string is found only in TCP packets
+# and the second only in UDP.
+
+tesla
+\x03\x9a\x89\x22\x31\x31\x31\.\x30\x30\x20\x42\x65\x74\x61\x20|\xe2\x3c\x69\x1e\x1c\xe9
diff --git a/usr/local/share/protocols/tftp.pat b/usr/local/share/protocols/tftp.pat
new file mode 100644
index 0000000..e9f16f7
--- /dev/null
+++ b/usr/local/share/protocols/tftp.pat
@@ -0,0 +1,20 @@
+# TFTP - Trivial File Transfer Protocol - used for bootstrapping - RFC 1350
+# Pattern attributes: marginal veryfast fast
+# Protocol groups: document_retrieval ietf_internet_standard
+# Wiki: http://www.protocolinfo.org/wiki/TFTP
+#
+# usually runs on port 69
+#
+# This pattern is unconfirmed.
+
+tftp
+# The first packet from the initiating host should either be a Read Request
+# or a Write Request. In the other direction, it should be data packet with
+# block number one or an ACK with block number zero. We only attempt to match
+# the initiating host's packets, because the only identifying features of
+# the responses to them are two byte sequences (which isn't specific enough).
+# (\x01|\x02) = Read Request or Write Request
+# [ -~]* = the file name
+# the rest = netascii|octet|mail (case insensitivity done by the kernel)
+
+^(\x01|\x02)[ -~]*(netascii|octet|mail)
diff --git a/usr/local/share/protocols/thecircle.pat b/usr/local/share/protocols/thecircle.pat
new file mode 100644
index 0000000..a161531
--- /dev/null
+++ b/usr/local/share/protocols/thecircle.pat
@@ -0,0 +1,11 @@
+# The Circle - P2P application - http://thecircle.org.au
+# Pattern attributes: ok veryfast fast
+# Protocol groups: p2p open_source
+# Wiki: http://www.protocolinfo.org/wiki/The_Circle
+
+# This is tested with The Circle 0.41c on Linux.
+# It likely misses some stuff. Notably, I wasn't able to test it on any
+# large downloads, because no one is sharing anything!
+
+thecircle
+^t\x03ni.?[\x01-\x06]?t[\x01-\x05]s[\x0a\x0b](glob|who are you$|query data)
diff --git a/usr/local/share/protocols/tor.pat b/usr/local/share/protocols/tor.pat
new file mode 100644
index 0000000..16f8884
--- /dev/null
+++ b/usr/local/share/protocols/tor.pat
@@ -0,0 +1,16 @@
+# Tor - The Onion Router - used for anonymization - http://tor.eff.org
+# Pattern attributes: good notsofast notsofast
+# Protocol groups: networking
+# Wiki: http://protocolinfo.org/wiki/Tor
+#
+# This pattern has been tested and is believed to work well.
+#
+# It matches on the second packet. I have no idea how the protocol
+# works, but this matches every stream I have made using Tor 0.1.0.16 as
+# a client on Linux.
+#
+# It does NOT attempt to match the HTTP request that fetches the list of
+# Tor servers.
+
+tor
+TOR1.*<identity>
diff --git a/usr/local/share/protocols/tsp.pat b/usr/local/share/protocols/tsp.pat
new file mode 100644
index 0000000..e704ce0
--- /dev/null
+++ b/usr/local/share/protocols/tsp.pat
@@ -0,0 +1,13 @@
+# TSP - Berkely UNIX Time Synchronization Protocol
+# Pattern attributes: good veryfast fast overmatch
+# Protocol groups: time_synchronization open_source
+# Wiki: http://www.protocolinfo.org/wiki/TSP
+#
+# http://ftp.svbug.com/ftp/pub/manuals/pdf/smm.22.timed.pdf
+# http://docs.freebsd.org/44doc/smm/12.timed/paper.pdf
+#
+# This pattern is barely tested.
+
+tsp
+# type, version (1), sequence number, 8 type specific bytes, machine name
+^[\x01-\x13\x16-$]\x01.?.?.?.?.?.?.?.?.?.?[ -~]+
diff --git a/usr/local/share/protocols/unknown.pat b/usr/local/share/protocols/unknown.pat
new file mode 100644
index 0000000..1c1c166
--- /dev/null
+++ b/usr/local/share/protocols/unknown.pat
@@ -0,0 +1,7 @@
+# Unknown - Dummy pattern for old unmatched connections.
+
+unknown
+# This pattern is ignored by the kernel. It sees that the "protocol" is
+# "unknown" and always returns unmatched for connections that are still
+# being tested.
+.
diff --git a/usr/local/share/protocols/unset.pat b/usr/local/share/protocols/unset.pat
new file mode 100644
index 0000000..80950c9
--- /dev/null
+++ b/usr/local/share/protocols/unset.pat
@@ -0,0 +1,8 @@
+# Unset - Dummy pattern for unmatched connections that are still being tested
+
+unset
+# This pattern is ignored by the kernel. It sees that the "protocol" is
+# "testing" and always returns matched for connections that are still
+# being tested.
+# NOT YET IMPLEMENTED.
+.
diff --git a/usr/local/share/protocols/uucp.pat b/usr/local/share/protocols/uucp.pat
new file mode 100644
index 0000000..c7685cd
--- /dev/null
+++ b/usr/local/share/protocols/uucp.pat
@@ -0,0 +1,11 @@
+# UUCP - Unix to Unix Copy
+# Pattern attributes: ok veryfast fast
+# Protocol groups: document_retrieval obsolete
+# Wiki: http://www.protocolinfo.org/wiki/UUCP
+
+# This is completely untested! (I don't know how to use UUCP...)
+
+# See http://docs.freebsd.org/info/uucp/uucp.info.The_Initial_Handshake.html
+
+uucp
+^\x10here=
diff --git a/usr/local/share/protocols/validcertssl.pat b/usr/local/share/protocols/validcertssl.pat
new file mode 100644
index 0000000..c004517
--- /dev/null
+++ b/usr/local/share/protocols/validcertssl.pat
@@ -0,0 +1,24 @@
+# Valid certificate SSL
+# Pattern attributes: good notsofast notsofast subset
+# Protocol groups: secure ietf_proposed_standard
+# Wiki: http://www.protocolinfo.org/wiki/SSL
+
+# This matches anything claiming to use a valid certificate from a well
+# known certificate authority.
+#
+# This is a subset of ssl, so it needs to come first to match.
+#
+# Note that opening a website that has a valid certificate will
+# open one connection that matches this and many ssl connections that
+# only match the ssl pattern. Thus, this pattern may not be very useful.
+#
+# This pattern is believed match only the above, but may not match all
+# of it.
+#
+# the certificate authority info is sent in quasi plain text, if it matches
+# a well known certificate authority then we will assume it is a
+# web/imaps/etc server. Other ssl may be good too, but it should fall under
+# a different rule
+
+validcertssl
+^(.?.?\x16\x03.*\x16\x03|.?.?\x01\x03\x01?.*\x0b).*(thawte|equifax secure|rsa data security, inc|verisign, inc|gte cybertrust root|entrust\.net limited)
diff --git a/usr/local/share/protocols/ventrilo.pat b/usr/local/share/protocols/ventrilo.pat
new file mode 100644
index 0000000..7ee9c13
--- /dev/null
+++ b/usr/local/share/protocols/ventrilo.pat
@@ -0,0 +1,17 @@
+# Ventrilo - VoIP - http://ventrilo.com
+# Pattern attributes: good fast fast
+# Protocol groups: voip proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Ventrilo
+#
+# I have tested this with Ventrilo client 2.3.0 on Windows talking to
+# Ventrilo server 2.3.1 (the public version) on Linux. I've done this
+# both within a LAN and over the Internet. In one test, I tried
+# monkeying around with the server settings to see if I could break the
+# pattern, and I couldn't. However, you can't change the port number in
+# the public server.
+#
+# It has also been tested by one other person in an unknown configuration.
+
+ventrilo
+^..?v\$\xcf
+
diff --git a/usr/local/share/protocols/vnc.pat b/usr/local/share/protocols/vnc.pat
new file mode 100644
index 0000000..9f77fdf
--- /dev/null
+++ b/usr/local/share/protocols/vnc.pat
@@ -0,0 +1,22 @@
+# VNC - Virtual Network Computing. Also known as RFB - Remote Frame Buffer
+# Pattern attributes: great veryfast fast
+# Protocol groups: remote_access
+# Wiki: http://www.protocolinfo.org/wiki/VNC
+#
+# http://www.realvnc.com/documentation.html
+#
+# This pattern has been verified with vnc v3.3.7 on WinXP and Linux
+#
+# Thanks to Trevor Paskett <tpaskett AT cymphonix.com> for this pattern.
+
+vnc
+# Assumes single digit major and minor version numbers
+# This message should be all alone in the first packet, so ^$ is appropriate
+^rfb 00[1-9]\.00[0-9]\x0a$
+
+# This is a more restrictive version which assumes the version numbers
+# are ones actually in existance at the time of this writing, i.e. 3.3,
+# 3.7 and 3.8 (with some clients wrongly reporting 3.5). It should be
+# slightly faster, but probably not worth the extra maintenance.
+# ^rfb 003\.00[3578]\x0a$
+
diff --git a/usr/local/share/protocols/whois.pat b/usr/local/share/protocols/whois.pat
new file mode 100644
index 0000000..0c8d0d0
--- /dev/null
+++ b/usr/local/share/protocols/whois.pat
@@ -0,0 +1,13 @@
+# Whois - query/response system, usually used for domain name info - RFC 3912
+# Pattern attributes: good notsofast notsofast overmatch
+# Protocol groups: networking ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/Whois
+#
+# Usually runs on TCP port 43
+#
+# This pattern has been tested and is believed to work well.
+
+whois
+# Matches the query. Assumes only that it is printable ASCII without wierd
+# whitespace.
+^[ !-~]+\x0d\x0a$
diff --git a/usr/local/share/protocols/worldofwarcraft.pat b/usr/local/share/protocols/worldofwarcraft.pat
new file mode 100644
index 0000000..dae2643
--- /dev/null
+++ b/usr/local/share/protocols/worldofwarcraft.pat
@@ -0,0 +1,65 @@
+# World of Warcraft - popular network game - http://blizzard.com/
+# Pattern attributes: ok veryfast fast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/World_of_Warcraft
+
+worldofwarcraft
+^\x06\xec\x01
+
+# Quoth the author of this pattern, Weisskopf Beat <weisb AT bfh.ch>:
+
+# I have written a pattern for wow (tested with versions 1.8.3 and
+# 1.8.4, german edition). It does not match the login as i think this is
+# uncritical, but i have added the necessary info later on. So only the
+# actual in-game traffic is matched.
+#
+# I hope the pattern is specific enough, otherwise one may add some
+# bytes from the response.
+#
+# some captured info:
+#
+# login:
+#
+# 0000: 00 02 28 00 57 6F 57 00 01 08 03 C7 12 36 38 78 ..(.WoW......68x
+# 0010: 00 6E 69 57 00 45 44 65 64 3C 00 00 00 C0 A8 01 .niW.EDed<......
+# 0020: 22 0A 42 57 45 49 53 53 4B 4F 50 46 ".BWEISSKOPF
+#
+# 0000: 00 02 28 00 57 6F 57 00 01 08 03 C7 12 36 38 78 ..(.WoW......68x
+# 0010: 00 6E 69 57 00 45 44 65 64 3C 00 00 00 C0 A8 01 .niW.EDed<......
+# 0020: 22 0A 42 57 45 49 53 53 4B 4F 50 46 ".BWEISSKOPF
+#
+# server asking:
+#
+# #1
+# 0000: 00 06 EC 01 04 49 C5 33 .....I.3
+#
+# #2
+# 0000: 00 06 EC 01 C3 A8 6E 63 ......nc
+#
+# client response
+# #1
+# 0000: 00 A4 ED 01 00 00 C7 12 00 00 00 00 00 00 42 57 ..............BW
+# 0010: 45 49 53 53 4B 4F 50 46 00 EB 35 DC 89 5A CA 6D EISSKOPF..5..Z.m
+# 0020: 17 95 DE 5B 74 6E 1E 5D 23 73 C6 8F 27 9F 11 12 ...[tn.]#s..'...
+# 0030: BB 21 01 00 00 78 9C 75 CC 41 0A 83 50 0C 84 E1 .!...x.u.A..P...
+# 0040: E7 3D 7A 19 75 25 D4 4D AB EB 12 5E A2 0C 8D 51 .=z.u%.M...^...Q
+# 0050: D2 57 04 4F DF 2E 2D A4 B3 FD 86 3F A5 EF 1A C5 .W.O..-....?....
+# 0060: 71 90 F3 A3 7E E7 82 D5 C6 2E 55 CB 7E B9 FE 58 q...~.....U.~..X
+# 0070: 43 A5 A8 4C 10 E5 1E 86 85 B6 E8 04 63 D8 1C 06 C..L........c...
+# 0080: 5A A7 A9 84 D2 D9 6B 93 1C 5B 4F D9 D7 50 6E 04 Z.....k..[O..Pn.
+# 0090: 0E 61 20 15 8B 6B 83 13 CB FD 09 D5 7F 0C 13 3F .a ..k.........?
+# 00A0: DB 07 B4 EA 54 F8 ....T.
+#
+# #2
+# 0000: 00 A4 ED 01 00 00 C7 12 00 00 00 00 00 00 42 57 ..............BW
+# 0010: 45 49 53 53 4B 4F 50 46 00 38 4C B5 95 C3 AD 25 EISSKOPF.8L....%
+# 0020: CB 73 48 BD 82 FC 99 63 59 AC BF F3 D0 C6 8D AB .sH....cY.......
+# 0030: 3D 21 01 00 00 78 9C 75 CC 41 0A 83 50 0C 84 E1 =!...x.u.A..P...
+# 0040: E7 3D 7A 19 75 25 D4 4D AB EB 12 5E A2 0C 8D 51 .=z.u%.M...^...Q
+# 0050: D2 57 04 4F DF 2E 2D A4 B3 FD 86 3F A5 EF 1A C5 .W.O..-....?....
+# 0060: 71 90 F3 A3 7E E7 82 D5 C6 2E 55 CB 7E B9 FE 58 q...~.....U.~..X
+# 0070: 43 A5 A8 4C 10 E5 1E 86 85 B6 E8 04 63 D8 1C 06 C..L........c...
+# 0080: 5A A7 A9 84 D2 D9 6B 93 1C 5B 4F D9 D7 50 6E 04 Z.....k..[O..Pn.
+# 0090: 0E 61 20 15 8B 6B 83 13 CB FD 09 D5 7F 0C 13 3F .a ..k.........?
+# 00A0: DB 07 B4 EA 54 F8 ....T.
+
diff --git a/usr/local/share/protocols/x11.pat b/usr/local/share/protocols/x11.pat
new file mode 100644
index 0000000..f42b98f
--- /dev/null
+++ b/usr/local/share/protocols/x11.pat
@@ -0,0 +1,22 @@
+# X Windows Version 11 - Networked GUI system used in most Unices
+# Pattern attributes: good notsofast fast
+# Protocol groups: remote_access x_consortium_standard
+# Wiki: http://www.protocolinfo.org/wiki/X11
+#
+# It is common for X to be tunneled through SSH. Then obviously this pattern
+# will not catch it.
+#
+# Specification: http://www.msu.edu/~huntharo/xwin/docs/xwindows/PROTO.pdf
+# Usually runs on port 6000 (6001 for the second server on a host, etc)
+#
+# This pattern has been tested.
+
+x11
+# 'l' = little-endian. 'B' = big endian
+# ".?" is for the unused byte that comes next. If it's a null, it won't appear.
+# \x0b = protocol-major-version 11.
+# For some reason, protocol-minor-version is 0, not 6, so can't match it.
+# This pattern is too general.
+^[lb].?\x0b
+userspace pattern=^[lB].?\x0b
+userspace flags=REG_NOSUB
diff --git a/usr/local/share/protocols/xboxlive.pat b/usr/local/share/protocols/xboxlive.pat
new file mode 100644
index 0000000..8d402cf
--- /dev/null
+++ b/usr/local/share/protocols/xboxlive.pat
@@ -0,0 +1,40 @@
+# XBox Live - Console gaming
+# pattern attributes: marginal slow notsofast
+# Protocol groups: game proprietary
+# Wiki: http://www.protocolinfo.org/wiki/XBox_Live
+#
+# This may match all XBox traffic, or may only match Halo 2 traffic.
+# We don't know yet.
+#
+# Thanks to Myles Uyema <mylesuyema AT gmail DOT com>, who says:
+#
+# Analyzing packet traces using Ethereal, the Xbox typically connects
+# to remote users using UDP port 3074. The first frame is typically
+# a 156 byte UDP payload. I've only scrutinized the first 20 or so bytes.
+#
+# Each line below represents the first frame between my Xbox and a remote
+# player's IP address playing Halo2 on Xbox Live.
+#
+# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 05 0f c5 62 00 f3 96 08
+# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 0f 0f c5 62 00 f3 97 09
+# 00 00 00 00 00 58 80 00 00 00 00 00 82 31 9e a8 05 0f c5 62 00 f3 95 07
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bc 07
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 be 09
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bf 0a
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bd 08
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 ba 05
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 87 ea 59 aa 11 ff 89 00 f3 bb 06
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 ca 06
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 cc 08
+# 00 00 00 00 00 58 80 00 00 00 00 00 81 7f dd 14 f2 8e a3 a1 00 f3 c9 05
+# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 d4 0a
+# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f3 c3 00 f3 d1 07
+# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 d2 08
+# 00 00 00 00 00 58 80 00 00 00 00 00 8b ca 5b c0 d8 9c f8 c3 00 f3 cf 05
+# 00 00 00 00 06 58 4e 00 00 00 e6 d9 6e ab 65 0d 63 9f 02 00 00 02 80 dd
+# 00 00 00 00 06 58 4e 00 00 00 46 e2 95 74 cd f9 bc 3d 00 00 00 00 8b ca
+# 00 00 00 00 06 58 4e 00 00 00 cf ce 3b 5c f5 f2 49 9a 00 00 00 00 8b ca
+# 00 00 00 00 06 58 4e 00 00 00 a9 c0 ac c5 16 e5 c9 92 00 00 00 00 8b ca
+
+xboxlive
+^\x58\x80........\xf3|^\x06\x58\x4e
diff --git a/usr/local/share/protocols/xunlei.pat b/usr/local/share/protocols/xunlei.pat
new file mode 100644
index 0000000..c362e37
--- /dev/null
+++ b/usr/local/share/protocols/xunlei.pat
@@ -0,0 +1,14 @@
+# Xunlei - Chinese P2P filesharing - http://xunlei.com
+# Pattern attributes: good veryfast fast
+# Protocol groups: p2p
+# Wiki: http://www.protocolinfo.org/wiki/Xunlei
+#
+# This has been tested by three people. It definitely catches some
+# streams.
+#
+# Written by wsgtrsys of www.routerclub.com. Improved by VeNoMouS.
+# Improved more by wsgtrsys and platinum of bbs.chinaunix.net.
+
+xunlei
+^[()]...?.?.?(reg|get|query)
+
diff --git a/usr/local/share/protocols/yahoo.pat b/usr/local/share/protocols/yahoo.pat
new file mode 100644
index 0000000..537349a
--- /dev/null
+++ b/usr/local/share/protocols/yahoo.pat
@@ -0,0 +1,26 @@
+# Yahoo messenger - an instant messenger protocol - http://yahoo.com
+# Pattern attributes: good fast fast
+# Protocol groups: chat proprietary
+# Wiki: http://www.protocolinfo.org/wiki/Yahoo_Messenger
+#
+# Usually runs on port 5050
+#
+# This pattern has been tested and is believed to work well.
+
+yahoo
+# http://www.venkydude.com/articles/yahoo.htm says:
+# All Yahoo commands start with YMSG.
+# (Well... http://ethereal.com/faq.html#q5.32 suggests that YPNS and YHOO
+# are also possible, so let's allow those)
+# The next 7 bytes contain command (packet?) length and version information
+# which we won't currently try to match.
+# L means "YAHOO_SERVICE_VERIFY" according to Ethereal
+# W means "encryption challenge command" (YAHOO_SERVICE_AUTH)
+# T means "login command" (YAHOO_SERVICE_AUTHRESP)
+# (there are others, i.e. 0x01 "coming online", 0x02 "going offline",
+# 0x04 "changing status to available", 0x06 "user message", but W and T
+# should appear in the first few packets.)
+# 0xC080 is the standard argument separator, it should appear not long
+# after the "type of command" byte.
+
+^(ymsg|ypns|yhoo).?.?.?.?.?.?.?[lwt].*\xc0\x80
diff --git a/usr/local/share/protocols/zmaap.pat b/usr/local/share/protocols/zmaap.pat
new file mode 100644
index 0000000..d21ad80
--- /dev/null
+++ b/usr/local/share/protocols/zmaap.pat
@@ -0,0 +1,17 @@
+# ZMAAP - Zeroconf Multicast Address Allocation Protocol
+# Pattern attributes: ok veryfast fast
+# Protocol groups: networking ietf_draft_standard
+# Wiki: http://www.protocolinfo.org/wiki/ZMAAP
+#
+# http://files.zeroconf.org/draft-ietf-zeroconf-zmaap-02.txt
+# (Note that this reference is an Internet-Draft, and therefore must
+# be considered a work in progress.)
+#
+# This pattern is untested!
+
+zmaap
+# - 4 byte magic number.
+# - 1 byte version. Allow 1 & 2, even though only version 1 currently exists.
+# - 1 byte message type,which is either 0 or 1
+# - 1 byte address family. L7-filter only works in IPv4, so this is 1.
+^\x1b\xd7\x3b\x48[\x01\x02]\x01?\x01
OpenPOWER on IntegriCloud