missing number features due to compiler using LEA to load constants

Summary

Compilers may setup API call constants via offsets instead of numbers (see examples below). I’ve seen this especially in 64-bit code using the LEA instruction.

It’s not ideal to manually account for things like this in rules as seen in https://github.com/fireeye/capa-rules/pull/122.

With some more research we can also come up with better ways to recognize such cases and only report number features accordingly.

Motivation

Per https://github.com/fireeye/capa-rules/pull/122#discussion_r489615545:

xor     edx, edx        ; pszRootPath
xor     ecx, ecx        ; hwnd
lea     r8d, [rdx+7]    ; dwFlags <-------
call    cs:SHEmptyRecycleBinW

Another example:

.text:000000018000F0D1 lea     r9d, [rsi+40h]  ; flProtect <-------
.text:000000018000F0D5 xor     ecx, ecx        ; lpAddress
.text:000000018000F0D7 mov     [rsp+0A8h+arg_0], rbp
.text:000000018000F0DF mov     r8d, 3000h      ; flAllocationType
.text:000000018000F0E5 mov     edx, [rbp+50h]  ; dwSize
.text:000000018000F0E8 call    cs:VirtualAlloc

Describe alternatives you’ve considered

• Ignore edge cases like these

[re-fox]

I encountered this when I was working on Luhn variations. https://github.com/fireeye/capa-rules/pull/52/files

We ended up merging the rule with 2 conditions, 1 account for the LEA and the other accounting for the regular numeric operation.

      - basic block:
        - or:
          - and:
            - number: 0x30
            - mnemonic: sub
            description: Conversion of chr to int (SUB 0x30) 
          - and:
            - mnemonic: lea
            - offset: -0x30
            description: Conversion of chr to int (LEA REG,[REG+ -0x30])

I think you have an interesting question, but I’m not sure what the best answer is.

This is just to contribute more data to the issue so it can help steer a decision.

[williballenthin]

this proposal was agreed to verbally by @mr-tz @mike-hunhoff during our weekly call