byte_test and relative

[Brandon Castel <bcastel () wurldtech com>]

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!