Re: [help,urgent] Using PCRE to match packets in hex

[rmkml <rmkml () yahoo fr>]

oops I'm curious when your linux sample:
 0e 13 12 34 56 78 ab cd ef 00 6c 69 6e 75 78

Are you sure it's \x0e ? because "linux" length is \x0f...

@Rmkml


On Sun, 27 Oct 2013, rmkml wrote:

> new version:
>
> alert tcp any any -> any any (msg:"Some message"; flow:to_server,established; 
> content:"|13|"; offset:1; pcre:"/^[\x0F\x11]\x13.{8}(?:windows|linux)/s"; 
> sid:1234567; rev:3;)
>
> @Rmkml
>
>
> On Sun, 27 Oct 2013, Yoyo Lam wrote:
>
> > Just to clarify so that no one thinks I am stuck with pcre regex:
> >
> > My problem is not with regex expression. Unless I am wrong (In this case 
> > please kindly point it out), there is no problem with it.
> > It is about the representation of bytecode in Snort. I guess it's the 
> > second one, but I'm not sure.
> >
> > And thank you very much for all your help. I feel honoured.
> >
> >
> > 2013/10/27 Yoyo Lam <mtcyoyo () gmail com>
> >       Thanks for all your help,
> >
> > Sorry for misleading you with the packets. I only got the packets on the 
> > windows version, I don't have the linux ones.
> > My issue is that I cannot use the regex with Snort.
> > And the format of this particular request is like this (in hex form):
> >
> > [1 byte of message length in hex]13[8 bytes of random hex][windows/linux in 
> > hex]
> >
> > The only thing which would be consistent throughout packets will be 13.
> > Therefore @rmkml, to make the first byte with 11 will not work.
> >
> > @Cummings, I know that content should be added, but I can't figure how it 
> > works from the docs. For example, about how I can confirm that a particular 
> > byte is something, and how to use multiple
> > contents with offset and depth. BTW I don't care about performance, since 
> > this is not for production. But thanks for the advice.
> >
> > @Waldo Kitty The data I want to match is bytecode (binary data in hex form, 
> > please refer to docs*), therefore I tried the B after the delimiter to see 
> > if it works. I don't think it would be possible
> > to wrap | around the regex to make it match bytecode.
> >
> > *"Bytecode represents binary data as hexadecimal numbers and is a good 
> > shorthand method for describing complex binary data."
> >
> > This is my modified version with reference to yours:
> >
> > alert tcp any any -> any any (msg:"Some message"; content:|13|; offset:1;
> > pcre:"/([0-9a-fA-F]{2}\s)13\s([0-9a-fA-F]{2}\s){8}(77\s69\s6e\s64\s6f\s77\s73|6c\s69\s6e\s75\s78)/B"; 
> > sid:1234567;
> > rev:1;)
> >
> > Regex explained:
> > ([0-9a-fA-F]{2}\s)13\s([0-9a-fA-F]{2}\s){8}(77\s69\s6e\s64\s6f\s77\s73|6c\s69\s6e\s75\s78)
> > ([0-9a-fA-F]{2}\s)         Matches 1 byte with 1 whitespace
> > 13\s                                   Matches 13 with 1 whitespace
> > ([0-9a-fA-F]{2}\s){8}    Matches 8 bytes seperated with 1 whitespace
> > (77\s69\s6e\s64\s6f\s77\s73|6c\s69\s6e\s75\s78)     Matches the bytecode of 
> > either *windows* or *linux* (You can take away the \s and put it into a hex 
> > to ascii converter)
> >
> > Therefore this regex pattern will match something like this: (a linux 
> > sample)
> > 0e 13 12 34 56 78 ab cd ef 00 6c 69 6e 75 78
> >
> > My problem is how do Snort represents bytecode. I can think of 3 methods:
> > 0e1312345678abcdef006c696e7578
> > 0e 13 12 34 56 78 ab cd ef 00 6c 69 6e 75 78
> > 0e:13:12:34:56:78:ab:cd:ef:00:6c:69:6e:75:78
> >
> > I want to know which is the one.
> > Since it is late here, I will do the testing tomorrow and give you the 
> > results.
> > btw thanks for the formatting tips :)
> >
> > Regards,
> > Yoyo
> >
> >
> >
> > 2013/10/27 waldo kitty <wkitty42 () windstream net>
> >       On 10/27/2013 3:33 PM, Yoyo Lam wrote:
> >       > I didn't use content since I don't really get how to use it 
> > properly, and with
> >       > my programming experience, I am more familiar with regex. And it 
> > seems that
> >       > using pcre alone is ok. (not thoroughly tested)
> >
> > yes you really do need content to match on and then regex performs more 
> > checking
> > either on the same content or other data in the same buffer...
> >
> > in your pcre you have "13", "77696e646f7773" and "6c696e7578" that you 
> > could use
> > content on...
> >
> > theory eg: content: 13; content: 77696e646f7773; distance: 46; 
> > your_pcre_here
> >
> > if i'm reading your regex properly, you are looking for
> >
> >    2 characters 0-9 or a-f or A-F
> >    13
> >    2 characters 0-9 or a-f or A-F
> >    the above three parts repeated 8 times
> >    77696e646f7773 or 6c696e7578
> >
> > is this correct? if so, the content looking for 13 followed 46 bytes later 
> > with
> > another content looking for 77696e646f7773 should match on those packets 
> > and
> > then the pcre would refine the match and fire...
> >
> > i think you will need two rules the same but with the second content match 
> > being
> > 6c696e7578 to catch those because i'm not aware of a way of specifying OR 
> > with
> > content... this would also allow you to alter the last part of your pcre to
> > contain only one or the other match depending on which rule it is...
> >
> > eg:
> >
> > alert tcp any any -> any any (msg:"Some message"; content: 13; content:
> > 77696e646f7773; distance: 46;
> > pcre:"/([0-9a-fA-F]{2})13([0-9a-fA-F]{2}){8}(77696e646f7773)/B"; 
> > sid:1234567;
> > rev:1;)
> >
> > alert tcp any any -> any any (msg:"Some message"; content: 13; content:
> > 77696e646f7773; distance: 46;
> > pcre:"/([0-9a-fA-F]{2})13([0-9a-fA-F]{2}){8}(6c696e7578)/B"; sid:1234567; 
> > rev:1;)
> >
> >
> > i've written the above off the top of my head with no testing at all (and 
> > no
> > data to test against)... i think it will give you what you need to 
> > understand
> > about content matches... the only other thing is if those parts are 
> > character
> > strings or if they are byte sequences... if they are by sequences, then the
> > content format would change slightly...
> >
> > another small formatting hint is that you should start the parameters of 
> > your
> > rules with the MSG section and then follow with your content, pcre, and 
> > other
> > parameters as needed (references, sid, rev)...
> >
> > --
> > NOTE: No off-list assistance is given without prior approval.
> >        Please keep mailing list traffic on the list unless
> >        private contact is specifically requested and granted.
> >
> >
> > ------------------------------------------------------------------------------
> > October Webinars: Code for Performance
> > Free Intel webinars can help you accelerate application performance.
> > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most 
> > from
> > the latest Intel processors and coprocessors. See abstracts and register >
> > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users
> >
> > Please visit http://blog.snort.org to stay current on all the latest Snort 
> > news!
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk

_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-users

Please visit http://blog.snort.org to stay current on all the latest Snort news!