> Can anyone from McSema comment on why it's moved from paid solutions for CFG recovery?
Plainly, because radare's CFG recovery is not reliable enough for us to use. It's not a production quality tool when compared to IDA or Binary Ninja. CFG recovery is an extraordinarily complex problem and doing it right requires a team with commercial support behind them. Altruism simply does not get you far enough for the grind of developing effective CFG recovery.
Similarly, McSema itself is not free either. We're being paid by the US Government. It requires a team of people with decades of experience in programming languages and compilers working together for years. We're lucky to be in this position, but it could have easily gone the other way. Not every project out there has a sponsor willing to make it free.
The teams behind IDA and Binary Ninja don't have some other, enormous business producing profits to support them (say, advertising). In order to spend the person-decades of time required to build these tools that our entire community relies on for our jobs, they need an income stream to work on them.
> The support for radare is ... not even merged.
I'm not aware of any pull requests for radare support. You're welcome to submit one and we'll consider it. However, we'll expect the author to continue supporting it as McSema grows since we can't use it for our projects (it's not reliable enough).
IDA has a ton of hacks in it that arent exactly common or public knowledge. There are hundreds of anti-debugger/dissasembler instruction sequences that will crash or stall or corrupt analysis tools. To even identify all the instructions which can be used for control flow, which alter which flags and how, for multiple architectures, is a royal man hour grunt work marathon. And as we see with the latest round of speculative load exploits, a lot of branches cannot even be predicted appropriately because they could be using exploits relying on undefined behavior..side channels. So the whole issue of perfect control flow analysis is a more mechanical one than a pure abstraction based one. When OllyDbg was first built it was the same way. Oleg put thousands od hours into whack a moling every issue. Most people like elegant endeavors based on some core principles. In static analysis of complex ISAs, the core principle is documenting 10000 species of moths, not finding that they all have wings..
Plainly, because radare's CFG recovery is not reliable enough for us to use. It's not a production quality tool when compared to IDA or Binary Ninja. CFG recovery is an extraordinarily complex problem and doing it right requires a team with commercial support behind them. Altruism simply does not get you far enough for the grind of developing effective CFG recovery.
Similarly, McSema itself is not free either. We're being paid by the US Government. It requires a team of people with decades of experience in programming languages and compilers working together for years. We're lucky to be in this position, but it could have easily gone the other way. Not every project out there has a sponsor willing to make it free.
The teams behind IDA and Binary Ninja don't have some other, enormous business producing profits to support them (say, advertising). In order to spend the person-decades of time required to build these tools that our entire community relies on for our jobs, they need an income stream to work on them.
> The support for radare is ... not even merged.
I'm not aware of any pull requests for radare support. You're welcome to submit one and we'll consider it. However, we'll expect the author to continue supporting it as McSema grows since we can't use it for our projects (it's not reliable enough).
I will note that we have an open PR for DynInst-based CFG recovery but we're still working with the author to review and approve it. https://github.com/trailofbits/mcsema/pull/386