.NET sample analysis

[mr-tz]

In mandiant/flare-floss#1087 a .NET sample causes vivisect issues:

INFO: vivisect: Beginning analysis...
INFO: vivisect: Extended Analysis: vivisect.analysis.generic.linker
INFO: vivisect.analysis.generic.linker: linking Imports with Exports
INFO: vivisect: Extended Analysis: vivisect.analysis.generic.entrypoints
DEBUG: vivisect: processEntryPoint: 0x47b39e
DEBUG: vivisect: makeFunction(0x47b39e, None, 0x0)
DEBUG: envi.codeflow: addCodeFlow(0x47b39e, 0x0)

I haven't looked too closely yet, but the issue seems to arise from addCodeFlow via addEntryPoint.

[rakuy0]

Probably the bigger issue is that .NET binaries are kind their own thing sorta separate from i386/arm/ppc/etc. The CLR section gets populated with a big database of type info and the actual instructions are their own virtual machine bytecode instructions.

I've been poking at .NET support in #673, but it's all in my free time, so it might still be a while till that's fully fleshed out.

[mr-tz]

Yes, absolutely. What do you think of an approach to initially detect .NET early on and not go down the standard path of code flow analysis that results in errors like this one?

[rakuy0]

I'm not against bailing early if it's an architecture we know we don't properly support. @atlas0fd00m you have any thoughts?