fOn Thu, May 02, 2013 at 04:03:05PM +0200, Franco Fichtner wrote: > On May 2, 2013, at 3:20 PM, Damien Miller <d...@mindrot.org> wrote: > > > On Thu, 2 May 2013, Franco Fichtner wrote: > > > >> OK, the implementation only pulls a couple of bytes from the packet's > >> payload. It will never pull bytes that are not verified. It will never > >> allocate anything. It will never test against something that's neither > >> hard-coded nor available in the range of the approved payload. It will > >> never return more than "unsigned int" with a number describing the > >> actual application. It will never manipulate any input value, lest of > >> all the packet itself. It will never run into endless loops. And I'll > >> gladly zap everything that could still considered be a potential risk. > > > > You've just described bpf, right down to "no endless loops" and the amount > > of data it returns. > > > > For a little more code that it takes to write one packet parser > > (basically: loading bpf rules from pf and making the bpf_filter()'s > > return value available to it) you get everything you described above and > > more. > > I yield. I'm working on making DPI more human-readable and maintainable, > and struct bpf_insn is not an option for me, personally.
libpcap has a fairly simple parser to turn expressions into bpf instructions. It is used by tcpdump. > > Worse still, searching for bpf+dpi in google already brings up this mail > thread as a top ten hit, which may be a good indicator of how successful > this approach has been the last couple of years. ;) > > > Franco
