capa-scripts: import, api, and function-name features

[mr-tz]

Currently, capa-scripts uses function call specific features different to capa. Intuitively, I'd expect that capa.NET rules "just work" on C# source and vice versa.

A) capa's current understanding:

• api: standard APIs, e.g. System.Convert.ToBase64String
  • scope: instruction, basic block, function, file
• function-name: user-defined functions, e.g. my_awesome_callout_function; identified using technologies like FLIRT, or .NET metadata, or source code...
  • scope: file
    • sidebar: should these also be defined at the function scope?
• import: an imported function
  • scope: file

B) Per discussion with Adam, the current capa-script implementation is:

• api: not defined
• function-name: a function from some imported namespace, can be static
• import: a newly instantiated object from some imported namespace

C) How I would see these in capa-script:

• api: like above
  • scope: function, file
• function-name: like above, differ to api in that they are defined in the current file
  • scope: function(?), file
• import: like above (equals all apis in the file?!)
  • scope: file

Do you agree with C) and if so, how can we get there?

[adamstorek]

I agree with the change and believe it's relatively easy to change, however, I am a bit confused about the difference between an api and an import.

[mr-tz]

For scripts I thought of import features as anything that's imported (used or not in the script). Is this useful in practice? Probably not. Should we not use import for scripts or treat them synonymously to api?

[adamstorek]

You are right. The more I think of it the more I am inclined to drop import and lump everything under api. It makes little difference for a rule whether the api is a class or a static method or a regular method. However, should we have something special for script alternative of offset aka class attribute assignment such as:

my_foo = new Foo();
my_foo.bar = "bar";

I believe @mike-hunhoff suggested property.

[mr-tz]

Great, then let's remove import for scripts.

Do we have multiple use-cases for such an property now? If not I'm fine if we worry about it later.

[mike-hunhoff]

You are right. The more I think of it the more I am inclined to drop import and lump everything under api. It makes little difference for a rule whether the api is a class or a static method or a regular method. However, should we have something special for script alternative of offset aka class attribute assignment such as:

my_foo = new Foo();
my_foo.bar = "bar";

I believe @mike-hunhoff suggested property.

@adamstorek regarding attribute assignments we want to extract these as property features. @anushkavirgaonkar is working on #939 that extends the .NET feature extractor to emit property features.