[Bro] Activating a scanner within a scanner?

Richard Hartmann richih at net.in.tum.de
Fri May 11 07:10:01 PDT 2007


> How closely are the two coupled? Is there information which needs to
> be passed between the two? 
> Not sure I understand that. Does this mean SDP can be encapulated
> inside SIP but does not have to?

SIP may contain SDP, whereas SDP is mainly used in SIP. SDP could be
used for the description of other sessions, but from what I could find,
its main use is definately for SIP.

The only information about SDP in SIP is the Content-Length field, so I
know that when I see a Content-Length != 0, there will be SDP
encapsulated into my SIP packet.


> If the coupling is not too tight, I'd say separating the two looks
> nicer, as it shows that semantically they are seperat.  The outer
> analyzer can instantiate an instance of the inner if necessary
> (i.e., if there's a body) and then call it's DeliverStream() method
> for the data. 

SIP is UDP-based. Would this work for DeliverPacket, as well?


A related problem I have is that SIP uses a blank line to show where the
SIP part ends and where the SDP part (if any) starts. What would be a
clean way to handle this situation?

Ideally, I would want to try two regular expressions. If the first one
matches, I know I am still in the SIP part. As soon as that regular
expression does not match any more, I could look for a blank line and
either set a status flag or invoke the secondary analyzer.

The problem is that from what I understand about BinPAC, it is impossible
to look at a line and just try to match. Either your whole type/record
matches or the whole rest of the packet is discarded.

Unfortunately, I can not simply look for a magic last item in the SIP
part as the order of the keywords may be completely random.

I tried looking at the HTTP analyzer, because this protocol uses a
newline to show when the header is finished, but to no avail.

Any help on this question would be greatly appreciated, as I am simply
unable to solve this problem.


For future versions on BinPAC, expanding the case statement so that one
could match the contents of a field against a regular expression and/or
text would probably help in a lot of situations.

What I have in mind is along the lines of

fork : case foo of {
	REGEXP_1 -> bar:  REGEXP_1;
	REGEXP_2 -> baz:  REGEXP_23;
	"string" -> qux:  bytestring &restofdata;
	default  -> quux: "hello";
};


Any help appreciated :)
Richard



More information about the Bro mailing list