Suricata

Why do use pcre instead of content here ? (it looks fixed)
And if you can use content, why do not you start with the content appearing first ?

Philippe Antoine wrote in #note-1:

Why do use pcre instead of content here ? (it looks fixed)
And if you can use content, why do not you start with the content appearing first ?

The PCRE were kept simple for the sake of an example, but in some cases I genuinely needed PCRE to match non-static content while jumping back some distance after some fixed content is matched.

teajj Is it your expectation that a negative @post_offset will never move the pointer prior to the buffer?

Using your example, a value of -10 would be before the buffer whereas a value of -8 is at the buffer start. So, treat -10 as though it were -8?

Jeff Lucovsky wrote in #note-6:

teajj Is it your expectation that a negative @post_offset will never move the pointer prior to the buffer?

Using your example, a value of -10 would be before the buffer whereas a value of -8 is at the buffer start. So, treat -10 as though it were -8?

That's correct, I feel it should either be at the buffer start or at least it shouldn't fail the rest of the signature. It's been a while since I tested this, but referring to example 3)

3. (failure) Actually, even the inclusion of this larger negative post_offset itself is enough to fail the signature without any proceeding patterns.
drop tcp any any -> any any ( msg:"Test.3"; rev:1; content:"|0A 95 00 20|"; byte_jump:0,0,relative,post_offset -10; sid:1000003; )

The signature doesn't trigger at all after making the jump without even trying to match anything after it, which is a weird behaviour.
It could be treated as a -10 still (so a distance/within in a following pattern has to take into account the extra -2 bytes anyway), or it could be treated as a -8 and always be at the buffer start.

If, say, we jump -10 and try to match PCRE with an anchor like ^ eg. byte_jump:0,0,relative,post_offset -10; pcre:"/^\x4e\x53\x4c\x4f/R";, and it's before the buffer, it may not be expected to work and that's fine. If treated as a -8 and at buffer start then it would work. Not sure which makes more sense but either seem like valid behaviour to me.

The only expectation is that we jumped -10 and we should still be able to search any patterns from that point regardless if we're in pre-start-of-buffer limbo, as long as we're not checking exactly there. So my original example of byte_jump:0,0,relative,post_offset -10; pcre:"/\x4e\x53\x4c\x4f/R"; should be able to trigger.