[RFC] Symbion state of the art and future ideas

I'm opening this issue to report on the current state of Symbion.

I've been recently contacted regarding bugs/ideas, so I thought was probably time to write a list of things that need to be done to improve the system and support new features. I'm writing this in the hope of pushing the contribution from the community as I'm having very little time to keep maintaining the project.

ConcreteTargets Support

• Currently, the only maintained ConcreteTarget is the AvatarGDBConcreteTarget. I can confirm the system works for the analysis of ELF/ELF64 binaries on a Ubuntu 18.04 system with gdb and gdbserver at versions 8.1.1 (it should also work until 9.2).
• I’ve recently discovered that the support for the analysis of Windows binary is not compatible anymore with the AvatarGDBConcreteTarget. To solve this issue, we can try to fix Avatar2, or, better, we can either drop that dependency and write our own GDBConcreteTarget purely based on pygdbmi, or, write a WinDBGTarget. Personally, I would really like to move to our own target that doesn't depend on Avatar2.
• I'm aware someone wrote a PandaConcreteTarget, and a ZelosConcreteTarget, it would be awsome if these projects can be pushed on our angr-targets repo! :)

Architectures Support

• Currently, Symbion can import the concrete state of programs compiled for x86/AMD64 and ARM32 architectures. As different architecture have different peculiarities, importing the state of a program written for an unsupported architecture requires extending the concrete state plugin.

Program Behaviors

• Symbion conceptually synchronizes only the state of the registers and memory. Any other data outside of that (i.e., socket, opened files, etc…) are not taken into account.
• I’ve never experimented with programs using threads, even if, that would be extremely interesting to try out. I'm aware someone did.
• Controlling how SimProcedures are re-hooked after a synchronization from concrete to symbolic is done through the option use_sim_proc (passed to the Project) and the SimStateOption SYMBION_KEEP_STUBS_ON_SYNC. More details on this can be found here.

Implementation Contributions

• Fuse Symbion into archr.
• Write a GDBConcreteTarget based on pygdbmi.
• Write a WinDBGTarget to support analysis on Windows environments without relying on CYGWIN.
• Re-vamp the IDAConcreteTarget.
• Improve support for PIC binaries analyses.

Research Ideas

• Use Symbion to automatically skip unsupported instructions, grab the results from the concrete execution, and resume the symbolic execution.
• Context-Aware Rop-Chain generation. All the current rop-chain generator tools are working without the context of the program in the "exploited state" (i.e., values in memory and in registers when starting to ROP). Can we improve the quality of the generated ROP-chains by adding this information? I can see this being integrated in our angrop.
• How much Symbion benefits the analysis of VERY complex binaries? Can we show that we can apply symbolic execution to, let's say, Google Chrome, and symbolically explore code that couldn't really be analyzed in a scalable way by the current SoA tools?
• ?

Extra Resources

More information regarding our motivation and Symbion's internal details can be found in the paper, the blogpost, and the slides I've put together for the presentation at CNS2020. Moreover, you can find more examples in this repo.

I've recently also opened a dedicated channel (#symbion) on our angr Slack. Feel free to PM me or yell in the channel for any other ideas or to discuss the one presented here!