[Snort-devel] [snort-devel] (no subject)

Peter Schmitz mosquitooth at ...224...
Thu Dec 28 03:23:50 EST 2006


Thanks again for replying - this helped a lot!

I had a look at snort's source code, but I cannot figure out one thing: 

in sp_pcre.c for example, the doe_ptr should be set to end of the last matching pattern, but instead it seems to me that it's set to the beginning of the last matching pattern:

* set the doe_ptr if we have a valid offset */
if(found_offset > 0)
{
   doe_ptr = (u_int8_t *) base_ptr + found_offset;
}

where found_Offset is returnded by the pcre functions. Where is doe_ptr additionally incremented by pattern length?

Just the same at byte_test: Of course doe_ptr is incremented by the byte_test offset, but doesn't it need to be incremented by the bytes_toextract value as well?

Thanks a lot for any answers,

Peter Schmitz


-------- Original-Nachricht --------
Datum: Wed, 27 Dec 2006 09:08:31 -0500
Von: Steven Sturges <steve.sturges at ...402...>
An: Peter Schmitz <mosquitooth at ...224...>
Betreff: Re: [Snort-devel] (no subject)

> 
> Peter Schmitz wrote:
> > Hi,
> > 
> > again, thanks for replying.
> > So, what it comes to would be this:
> > 
> > To do all the necessary payload checks, snort first initializes some
> > pointers (base_ptr at the beginning of the payload, start_ptr at the
> > beginning of the payload to search, end_ptr at the end of the
> > payload/searchspace and doe_ptr). base_ptr and end_ptr shouldn't
> > change when going through all the rules, but the other ones are
> > resetted on every new rule that snort checks upon.
> 
> The base, start, end ptrs are set when each rule option is checked,
> as they are local to the individual rule options.  Base and end
> shouldn't change, though...
> 
> > Now the search starts. If there is a byte_jump keyword, the doe_ptr is
> > moved for some bytes (depending on payload) so that the next relative
> > keyword would start the search at doe_ptr (in this case a byte_jump
> > keyword that is NOT followed by any relative keyword - distance, R on
> > pcre  etc. - would make no sense, is that correct?).
> 
> Not necessarily... The doe_ptr is moved forward some bytes.  There
> shouldn't be a non-relative option following a byte_jump -- kinda makes
> the byte_jump useless, but there is nothing to prevent it.
> 
> > So basically, every time a content pattern (or any other payload option
> > as there are pcre, isdataat, content, byte_test, byte_jump) matches on
> > the payload, doe_ptr is moved to that location (+ the pattern length),
> > just in case the next keyword would be relative and needed this as a
> > starting place.
> 
> Correct.  The doe_ptr is set to the end of the pattern in the case of
> PCRE, content, or byte_test and moved forward in the case of byte_jump.
> 
> > One last thing: What's the exact difference between doe_ptr and
> > start_ptr?  Is start_ptr just a 'wrapper' for either the value of
> > base_ptr (non- relative) or doe_ptr (relative)?
> 
> Yes, exactly... the doe_ptr is the global variable that is used
> across all rule options.  start_ptr is set to base_ptr or doe_ptr (if
> relative).
> 
> > thanks - again - for any help,
> > 
> > Peter
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > -------- Original-Nachricht --------
> > Datum: Tue, 26 Dec 2006 20:39:04 -0500
> > Von: Steven Sturges <steve.sturges at ...402...>
> > An: Peter Schmitz <mosquitooth at ...224...>
> > Betreff: Re: [Snort-devel] (no subject)
> > 
> >> Hi Peter--
> >>
> >> No, multiple contents are not relative to each other unless
> >> you specify a 'distance' (start x bytes from current
> >> position), 'within' (search no more than y bytes).  'offset' and
> >> 'depth' have similar meanings.
> >>
> >> byte_test, byte_jump have a 'relative' option keyword, and PCRE
> >> has a 'R' modifier.
> >>
> >> Order of rule options is only important for those that are relative
> >> to each other.
> >>
> >> In your example, there is no difference... 1st line searches for
> >> "a", then, if found, start at the beginning and search for "b",
> >> and if found, start at the beginning and search for "c".  2nd one
> >> does the same for "b", then "a", then "c".
> >>
> >> However, if you add 'distance:10' to the content:"c", the 1st
> >> would start looking for "c" 10 bytes after the first occurance
> >> of "b", while the 2nd would start looking for "c" 10 bytes after
> >> the first occurance of "a".
> >>
> >> Cheers.
> >> -steve
> >>
> >> Peter Schmitz wrote:
> >>> Thanks a lot for replying! This helped a lot!
> >>>
> >>> One additional question: If there is a pointer like doe_ptr,
> >>> does that mean that e.g. several content keywords in a rule
> >>> are all 'relative' to each other? Does snort only look for
> >>> an additional content after the last matching pattern?
> >>> If so, is the order of all the keywords in one rule important? 
> >>> E.g. is content:"a";content:"b"; content:"c" different from
> >>>         content:"b";content:"a"; content:"c"?
> >>> To which keywords does this apply (pcre, byte_test, etc.)?
> >>>
> >>> thanks a lot,
> >>>
> >>> Peter 
> >>> -------- Original-Nachricht --------
> >>> Datum: Tue, 26 Dec 2006 13:43:35 -0500
> >>> Von: Steven Sturges <steve.sturges at ...402...>
> >>> An: Peter Schmitz <mosquitooth at ...224...>
> >>> Betreff: Re: [Snort-devel] (no subject)
> >>>
> >>>> Hi Peter--
> >>>>
> >>>> Answers below... Hope this helps.
> >>>>
> >>>> Cheers.
> >>>> -steve
> >>>>
> >>>> Peter Schmitz wrote:
> >>>>> HI, 
> >>>>>
> >>>>> I'm currently struggeling through snort code and rules to fully
> >>>>> understand the system. When I came across the keyword byte_jump,
> >>>>> I - unfortunately - didn't understand something:
> >>>>>
> >>>>> In the latest snort documentation it says, that byte_jump would
> >>>>> set a doe_ptr to another destination (depending on the rule).
> >>>>> Now, what does this pointer really point to? Is this a position
> >>>>> in the payload? Does that mean, that if I jump some bytes all
> >>>>> later checking for content keywords will take place after the
> >>>>> destination doe_ptr now (after executing byte_jump) points to?
> >>>>>
> >>>>> If I - for example - would begin a rule like this: 
> >>>>>
> >>>>> byte_jump:4,36,align; 
> >>>>> content:"|00 00 00 01|"; offset:16; depth:4; 
> >>>>>
> >>>>> First, I'd jump some bytes (depending on the packet real payload)
> >>>>> - then I'd search for some specific content. If this content could
> >>>>> be found in the bytes I just skipped by byte_jump - will this
> >>>>> content be found?
> >>>> The interpretation of this is jump some bytes (depending on payload),
> >>>> then look for '00 00 00 01' 16  bytes from the result of the jump and
> >>>> only search the next 4 bytes.  So, this will only trigger if the
> >>>> content is found starting 16 bytes from where the byte jump 'landed'
> >>>> (the resulting doe_ptr).
> >>>>
> >>>> Think of the doe_ptr as a pointer to a place in the payload at the
> >>>> conclusion of each operation (be it byte jump, byte test, pcre,
> >> content,
> >>>> etc).
> >>>>
> >>>>> Another thing are the several pointers:
> >>>>>
> >>>>> What do base_ptr, doe_ptr, start_ptr, end_ptr really point to?
> >>>> Not looking at the code at the moment, but base_ptr is the start of
> >>>> the payload (usually).  start_ptr is a pointer to the beginning of
> >>>> the search space (after 'relative', 'offset', are taken into account.
> >>>> end_ptr is the end of the payload -- to prevent reading beyond the
> >>>> payload.
> >>>>
> >>>>> By the way, there are several keywords for the byte_jump keyword
> >>>>> itself, esp. from_beginning and relative...isn't this superficial?
> >>>>> Isn't relative == !from_beginning ?
> >>>> Good question... 'relative' means read the bytes to jump relative to
> >> the
> >>>> end of the last operation -- ie, use the doe_ptr to find how much to
> >>>> jump.  Then, jump from the end of those bytes.  DNS record parsing is
> a
> >>>> good example, where you'd want to skip the length of a given record.
> >>>>
> >>>> 'from_beginning' means jump from the start of payload.  The bytes
> that
> >>>> are read can still be relative to a earlier operation, but they are
> >>>> really an offset from the beginning of the payload, not from the
> >>>> current location -- this happens with DCE/RPC quite a bit.
> >>>>
> >>>> So, you could have both 'relative' and 'from_beginning' as options to
> >>>> the same byte_jump.
> >>>>
> >>>>> I know that some of my questions seem (and probably are) trivial, 
> >>>>> but I really want to understand and if someone could help me out
> >>>>> I'd be really grateful :)
> >>>>>
> >>>>> Thanks for any help on this matter, 
> >>>>>
> >>>>> Peter 
> >>>>>
> >>>>
> >>
> -------------------------------------------------------------------------
> >>>> Take Surveys. Earn Cash. Influence the Future of IT
> >>>> Join SourceForge.net's Techsay panel and you'll get the chance to
> share
> >>>> your
> >>>> opinions on IT & business topics through brief surveys - and earn
> cash
> >>>>
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>>> _______________________________________________
> >>>> Snort-devel mailing list
> >>>> Snort-devel at lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/snort-devel
> > 

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer




More information about the Snort-devel mailing list