consider deprecation of SMDA backend

[williballenthin]

we have some new major features coming that will be implemented for the viv (and probably IDA) backends; however, we don't have the bandwidth to implement the analysis for SMDA. we are considering removing the SMDA backend rather than let it bitrot.

questions:

• does anyone use the SMDA backend?
• would anyone like to contribute continued maintenance of the SMDA backend?

an example of a "major feature" we're considering is "function call argument scope". that is, for recognized API calls, extract the arguments (when feasible). we expect to be able to implement this for:

• viv, probably via emulation
• ida, via idapython API for fetching arguments for a given call insn

but for SMDA we don't have any obvious strategy, without re-implementing e.g. emulation. we could just not support this scope for SMDA, but if call scope works well for viv, we'll migrate many rules to use this syntax (instead of basic block: api, number, string). then, SMDA wouldn't work for many rules.

[williballenthin]

@danielplohmann

[williballenthin]

shall we introduce a deprecation warning in v4.0 when users select the SMDA backend and remove it in v5.0? between now and 5.0, no further guaranteed development?

[danielplohmann]

Hey!

Given that SMDA was originally added to provide Python3 support to capa and given the fact that this is now also covered by vivisect, phasing it out again because of redundancy sounds like the most reasonable architecture decision at this point.

For SMDA, we already do some very basic dataflow analysis / backtracking to resolve targets of call <reg> instructions.
I guess this approach could be adapted for resolving (WinAPI) call arguments but it would be nowhere as sound and complete as a properly designed DFA or potentially emulation would be.

For potential future extensions in SMDA, I'm also leaning more towards adding ICFG extraction for other architectures than focusing on more intricate static analysis.

[williballenthin]

removed in #1213