PLUGX: make more restrictive to fix FP

[williballenthin]

closes #842

[williballenthin]

@Still34 FYI

[williballenthin]

looks like i need to review the linter failure before this is merged. please review the intent of the logic change in the meantime.

[Still34]

Shoot, I'll take a look in a bit

[mr-tz]

logic LGTM

[Still34]

Looks perfectly fine to me as well

[williballenthin]

when I proposed the changes here I imagined (without looking, sorry) that there'd be a large command ID dispatcher that had a bunch of the command IDs referenced in the same function, using a case/switch statement. turns out this is not the case for plugx. instead, we have individual functions that handle each command, parsing or creating the protocol, like:

note that we see:

mov [base+0], TIMESTAMP
mov [base+4], COMMAND

also: along the way i did find a FP in the same sample: see how 0x4000 is used as a bitmask in a related function, not as the command ID:

so, i'll propose updating the rule to:

- and:
  - instruction:
    - mnemonic: mov
    - operand[0].offset: 0
    - or:
      - operand[1].number: TIMESTAMP1
      - operand[1].number: TIMESTAMP2
  - instruction:
    - mnemonic: mov
    - operand[0].offset: 4
    - or:
      - operand[1].number: COMMAND1
      - operand[1].number: COMMAND2

i think its appropriate to set the scope to basic block, too.

[williballenthin]

[williballenthin]

@Still34 @mr-tz would you take another peek, please?

[Still34]

Throw this timestamp in there as well 0x20140613, also I could not get the match to pass with sample edfff708808ef3a5453dc7713d306b20 @ 0x1000A258 (and yes the timestamp is added to the local rule).

[mr-tz]

with the added value it matches for me:

[williballenthin]

@Still34

also I could not get the match to pass

would you double check using -vv?

it looks like today we're filtering out malware family rules from the default display. im not quite sure why we're doing that. do you remember @mr-tz?

[mr-tz]

I'm not sure why. Maybe we wanted to render it separately...