[Snort-devel] byte_test and relative
bcastel at ...3121...
Fri Oct 12 15:10:52 EDT 2012
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)
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_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?
Wurldtech Security Technologies
Suite 1000 - 1090 West Georgia Street
Vancouver, BC V6E 3V7
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-devel