
KLEE LLVM Execution Engine - polskibus
https://klee.github.io
======
hdespiritu
One of the contributors wrote a memoir of his time spent working on this
project as a PhD student and gives an interesting perspective on the
challenges encountered:

[http://pgbovine.net/PhD-memoir.htm](http://pgbovine.net/PhD-memoir.htm)

------
k4st
You can also run KLEE on x86(-64) or AArch64 binaries using McSema to lift the
binary to LLVM bitcode. An example is here:
[https://github.com/trailofbits/mcsema/tree/master/examples/M...](https://github.com/trailofbits/mcsema/tree/master/examples/Maze)

------
mslate
Anyone using this in practice?

~~~
TheNewAndy
I use it - I am writing a subset-of-yaml parser, and I've littered the code
with a bunch of abort()/assert() statements for things I don't think should be
possible. Running klee over my code spits out ~100K test cases (I let it use
any 10 byte YAML input), and so while I don't inspect the output of any of the
cases - I do make sure that none of them crash.

Similarly, if I make a change which I don't expect to change the output of the
parser, then I can use this test suite to be quite sure that my change hasn't
changed behaviour.

One thing I am unclear about is what it means for klee to be "done" on my
binary. When it has generated all the test cases, if none of them crash my
binary, then does that mean it is impossible to crash my binary in 10 bytes of
input?

~~~
withzombies
Have you checked out DeepState
([https://github.com/trailofbits/deepstate](https://github.com/trailofbits/deepstate)),
it's a symbolic unit testing framework that has an interface similar to google
test.

~~~
TheNewAndy
I haven't - thanks.

Writing test harnesses specific to the different tools (so far, just AFL and
KLEE) has not been particularly difficult - all of them fit easily on one
screen. So I'm not sure that deepstate really brings much to the table for
what I'm doing.

------
xvilka
Problem of KLEE is lagging behind the latest LLVM version , which changed and
improved a lot meanwhile.

~~~
kren1
There is support up to atleast llvm 3.8 now. See:
[http://klee.github.io/build-llvm38/](http://klee.github.io/build-llvm38/)

~~~
xvilka
3.8 is super old already.

------
cztomsik
I wonder if we could somehow use the work done in prepack to generate similar
tests for javascript.

BTW: I don't want to oversimplify it, but it basically just looks at each
branch and generates data which would pass the branch, right?

------
senatorobama
What is CS 101 explanation for this project?

~~~
modeless
I found a blog post with a succinct explanation.

> KLEE [runs] a program considering its input(or some other variables) to be
> symbols instead of concrete values like 100 or “cacho”. In very few words, a
> symbolic execution runs through the code propagating symbols and conditions;
> forking execution at symbol dependant branches and asking the companion SMT
> solver for path feasibility or counter-examples.

[https://feliam.wordpress.com/2010/10/07/the-symbolic-
maze/](https://feliam.wordpress.com/2010/10/07/the-symbolic-maze/)

~~~
cryptonector
Finally, a succint, pithy explanation.

This is great. Makes me want to use it.

