# Activating a scanner within a scanner? **URL:** \ **Category:** Zeek\ **Created:** [May 10, 2007, 9:35am UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175 "2007-05-10T09:35:44Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Richard\_Hartmann](https://avatars.discourse-cdn.com/v4/letter/r/6f9a4e/32.png) [@Richard\_Hartmann](https://community.zeek.org/u/Richard_Hartmann)\ **Post date:** [May 10, 2007, 9:35am UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/1 "2007-05-10T09:35:44Z")
Hi all, as some of you will know, I am writing a SIP and (soonish) a RTCP analyzer in BinPAC. I have a question regarding the analyzation of protocols which are inlined into other protocols. The relation of SIP to SDP could losely be described as that of a HTML header and body. When the Content-Length field in the SIP packet is non-zero, there is a SDP payload that also needs to be parsed. I am not sure if it would make more sense to hook another analyzer into the SIP analyzer or to just parse the SDP payload within my SIP analyzer. Another consideration would be how to write the SDP analyzer in a way that accounts for both for standalone detection and as a plugin for my SIP analyzer (working on packets vs working on data i feed it directly). Any feedback is appreciated, Richard ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [May 10, 2007, 10:23pm UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/2 "2007-05-10T22:23:10Z")
(Disclaimer: I've no idea about SIP/SDP). > I am not sure if it would make more sense to hook another analyzer into > the SIP analyzer or to just parse the SDP payload within my SIP > analyzer. How closely are the two coupled? Is there information which needs to be passed between the two? 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. > Another consideration would be how to write the SDP analyzer in a way > that accounts for both for standalone detection and as a plugin for my > SIP analyzer (working on packets vs working on data i feed it directly). Not sure I understand that. Does this mean SDP can be encapulated inside SIP but does not have to? Robin ---
**Author:** ![Richard\_Hartmann](https://avatars.discourse-cdn.com/v4/letter/r/6f9a4e/32.png) [@Richard\_Hartmann](https://community.zeek.org/u/Richard_Hartmann)\ **Post date:** [May 11, 2007, 2:10pm UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/3 "2007-05-11T14:10:01Z")
> 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 ---
**Author:** ![Richard\_Hartmann](https://avatars.discourse-cdn.com/v4/letter/r/6f9a4e/32.png) [@Richard\_Hartmann](https://community.zeek.org/u/Richard_Hartmann)\ **Post date:** [May 11, 2007, 5:38pm UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/4 "2007-05-11T17:38:22Z")
To elaborate on options to parse newlines which I can think of in the order I would prefer to be able to do this: 1) Define a type like type SIP\_Headers = SIP\_Header[] &until(foo); where foo would be some way to tell the parser 'until you hit a blank line' 2) Use a case statement to decide how to continue parsing of the data 3) Try to parse parts of the remaining buffer and continue with another branch in the parsing tree if that first attempt fails 4) If all else fails, I will probably try to just grab the first letter of the current line and decide based on what is in that field. This would be an extremely kludgy (think several strings starting with the same letter, resulting in even more branching) and hacky (just ugly, hard to read and generally bad style) Best regards, Richard ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [May 16, 2007, 1:37am UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/5 "2007-05-16T01:37:27Z")
> SIP may contain SDP, whereas SDP is mainly used in SIP. SDP could be > used for the description of other sessions, [...] > The only information about SDP in SIP is the Content-Length field, Ok, so then I would go for a seperate analyzer. > SIP is UDP-based. Would this work for DeliverPacket, as well? Yes. The "packet" is actually just a chunk of data, with the actual interpretation being left to the analyzer. > I tried looking at the HTTP analyzer, because this protocol uses a > newline to show when the header is finished, but to no avail. If I understand you correctly, you should be able to do this in the same way as the HTTP analyer does it. I thinkt this is the relevant type from http-protocol.pac:      type HTTP\_Headers = HTTP\_Header &until($input.length() == 0); Does something similar work for you?       Robin ---
**Author:** ![Ruoming\_Pang](https://avatars.discourse-cdn.com/v4/letter/r/df788c/32.png) [@Ruoming\_Pang](https://community.zeek.org/u/Ruoming_Pang)\ **Post date:** [May 17, 2007, 5:40pm UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/6 "2007-05-17T17:40:33Z")
> \> I tried looking at the HTTP analyzer, because this protocol uses a > \> newline to show when the header is finished, but to no avail. > > If I understand you correctly, you should be able to do this in the > same way as the HTTP analyer does it. I thinkt this is the relevant > type from http-protocol.pac: > >      type HTTP\_Headers = HTTP\_Header &until($input.length() == 0); > > Does something similar work for you? Richard, > From what you described, it should work for you. Please keep us updated if it doesn't. To provide a bit of background, $input in the "until" clause corresponds to a line without the trailing CRLF, because HTTP\_Header is defined with a &oneline attribute. By the way, this means $input can also be used in more fancy conditions, such as ($input == "foo"). Ruoming ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/activating-a-scanner-within-a-scanner/1175/7 "2022-05-06T15:38:15Z")
Closed on May 6, 2022, 3:38pm UTC