This Week in Falcon - 29 Jul 2017

2017/07/29

Roadmap to 0.1.0.

I’ve created a 0.1.0 milestone. This will track all of the less-exciting things that I believe should happen before 0.1.0 as they come up. The big things are:

We can symbolically execute over the simple-0 example.

We have some concept of, “Platform,” of which, “Linux,” “CGC,” and perhaps, “Windows,” may be supported.

Once these things work, I will have confidence enough in the IL and x86 translator to move to 0.1.0. The data-flow analysis/fixed-point engine will most likely change drastically between 0.1.0 and 0.2.0, but the IL and translator should be stable enough for me to support it.

List of new additions/changes/fixes.

Bug fix in je.

Basic relocation types for x86 ELFs.

Falcon can link libc.so.6 and ld-linux.so.2 against the simple-0 example binary, taken from a stock Ubuntu 16.04 32-bit x86 machine.

Cleaning up and paying attention to expensive clone() calls. Things are moving much faster.

The translator lifts from a TranslationMemory trait, so we can memory for lifting from other things (like memory models during Symbolic Execution).

Non-Falcon things learned/found

Manticore allows for symbolic addresses on memory stores

As shown here. It looks like manticore will solve for up to 0x1000 possible addresses, check if any of them are Out-Of-Bounds (crashing), and if not, add the possible value being stored to each memory location to the set of possible values in that memory location?

This is interesting as Klee concretizes addresses for reads and stores, MAYHEM concretizes addresses for stores (but allows symbolic addresses on reads), and Angr follow’s MAYHEM’s model. While there most likely is a binary symbolic execution engine that allows for symbolic addresses on stores, I don’t know of it.