Snort mailing list archives
byte_test and relative
From: Brandon Castel <bcastel () wurldtech com>
Date: Fri, 12 Oct 2012 12:10:52 -0700
Hi all, We've noticed that using byte_test doesn't seem to advance the relative pointer in the way we'd expect and were wondering if this was by design behavior or a bug (the docs don't discuss the relative concept in any depth as far as I can tell) Here's a contrived example of what we're noticing Against this (hex) data - 05 64 16 21 AB CD 11 22 CC CC AA A1 0D We write a rule with the following body (ignore for conversation's sake that we can write the 2nd and 3rd as contents and avoid this whole mess) Content:"|05 64|"; byte_test:1,>,7,0, relative; byte_test:2,=,0xABCD,2,relative; byte_test:1,=,0x0D,10, relative; This rule will fire, but notice that the offsets of the three byte_tests are are relative to 0x0564 and not each other. In the simple example that's not a big deal, its all fixed offsets so we can just adjust our numbers a bit and it all works out. The problem is when we'd like to do more complicated things, for example we have a signature we want to write which reads two variables from a packet at fixed offsets from the header, does a simple calculation on them (2a + b + 6) to find the offset of some bytes further down the packet. We had *hoped* to solve this by combining byte_extract and byte_test kind of like this: byte_extract:1,0,variableA,multiplier 2; byte_extract:1,4,variableB; byte_test:1, ^, 0xff, 6; byte_test:1, ^, 0xff, variableA; byte_test:4, >, 0xAABBCCDD, variableB; #our actual test goes here at relative offset variableB The idea being we're taking advantage of the fact that doing a logical OR with 0xff is always true so we force the relative pointer to where we want it in stages. We want 2A + B + 6, so we move it 6, then 2A then B Any thoughts (or alternative solutions) guys? -- Brandon Castel Vulnerability Researcher Wurldtech Security Technologies Suite 1000 - 1090 West Georgia Street Vancouver, BC V6E 3V7 Canada Phone: (604) 669 6674 ext 709 Fax: (604) 669 2902 "ARE YOU ACHILLES CERTIFIED?" This message is intended only for the named recipients. This message may contain information that is privileged, confidential or exempt from disclosure under applicable law. Any dissemination or copying of this message by anyone other than a named recipient is strictly prohibited. If you are not a named recipient or an employee or agent responsible for delivering this message to a named recipient, please notify us immediately by telephone at 604-669-6674, and permanently destroy this message and any copies you may have. Email may not be secure unless properly encrypted.
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ Snort-devel mailing list Snort-devel () lists sourceforge net https://lists.sourceforge.net/lists/listinfo/snort-devel Please visit http://blog.snort.org for the latest news about Snort!
Current thread:
- byte_test and relative Brandon Castel (Oct 12)
- Re: byte_test and relative Todd Wease (Nov 02)
- Re: byte_test and relative Todd Wease (Nov 02)
- Re: byte_test and relative Brandon Castel (Nov 02)
- Re: byte_test and relative Todd Wease (Nov 02)
- Re: byte_test and relative Todd Wease (Nov 02)
- Re: byte_test and relative Todd Wease (Nov 02)