ChopShop is too slow to handle detection of c2 traffic in real-time on a large pipe. Frankly, it was never meant for it, even though a lot of folks would like to run it like that. For detection of c2 in real-time on a large pipe you need some capability that has the ability to scale (and just be faster overall). If the performance hit added by the translation of bro script is too huge, then it would be slow, but given Bro Cluster's ability to scale I would hope that it could be somehow managed.

The alternative would be to add another bro framework (or augment the signature framework) to allow for C or C++ like code to be directly executed on packets akin to Shared Object Rules or to add some abstracted math language to it that gets parsed and directly executed. The other alternative, of course, is to just use another detection system.



P.S -- full disclosure -- I'm the primary author of ChopShop.



On Sat, May 24, 2014 at 2:56 AM, anthony kasza <anthony.kasza@gmail.com> wrote:

I'd love to see these operations built into Bro. However, considering Bro's focus on scale, individual c2 operations analysis (especially when applied to specific connections within a large pipe) may be better suited for something like chopshop or another framework focussed on individual connections. Any other opinions?

-AK

On May 23, 2014 10:52 PM, "M K" <mkhan04@gmail.com> wrote:
My method was to take a string of bytes and convert them to integral types I wanted.

So if I received a 'string' type in a function I could do:

local foo1 = bytestring_to_count(sub_bytes(string, 0, 4));
local foo2 = bytestring_to_count(sub_bytes(string, 4, 2));
local foo3 = bytestring_to_count(sub_bytes(string, 6, 2));

bar = foo1 ^ 0x12345678;
bah = (foo2 + foo3) & 0xFFFF;

if  ( bar == 0xDEADBEEF && bah > 0x1234 ) {
#do a barrel roll
}



On Sat, May 24, 2014 at 1:42 AM, Vern Paxson <vern@icir.org> wrote:
> Bitwise operations on user defined stream fields for custom protocol

Okay, these examples make sense to me.  Let me ask then about what such
operators should look like.  M K originally sketched them as operating on
integral types.  However, I'd think that if it's for manipulating blobs
of C&C, then instead working on strings would be the right target ... ?

                Vern