dotnet: consider emitting references to types

methods interact with various types, including both primitive objects (u8) and classes. sometimes we see method/property access to the classes, which can be represented by things like API (and maybe offset???). we might also see direct references to class objects, such as casting instances from one class to another.

do we want to introduce a new feature to represent types/classes referenced within some scope?

e.g.

type: System.Net.FtpWebResponse

[mike-hunhoff]

Chatted with @adamstorek offline about the ability to distinguish object instantiation in capa rules. This is especially important when analyzing scripting languages e.g.

... new System.Threading.Mutex();

which we see as the following in .NET CIL:

... newobj System.Threading.Mutex::.ctor

We discussed the potential of emitting an object instantiation as an api feature using the keyword ctor:

- api: System.Threading.Mutex::ctor

This would allow us to capture the intended behavior without needing to add new features.

[williballenthin]

As a programmer, I get the difference between instance and class. But from a perspective of matching malware behavior, does it make enough difference to warrant a new feature?

Note also that the rule author must be competent at programming to differentiate the cases to construct accurate rules. Not sure if this is a strong or weak argument, though.

On Jul 28, 2022, at 1:43 PM, Mike Hunhoff @.***> wrote:

another use case for an instance feature:

… newobj instance void [mscorlib]System.Reflection.Emit.DynamicMethod::.ctor(string, class [mscorlib]System.Type, class [mscorlib]System.Type[], class [mscorlib]System.Type, bool)

• namespace: System.Reflection.Emit
• class: System.Reflection.Emit.DynamicMethod
• instance: System.Reflection.Emit.DynamicMethod — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.