Bugchecker.net – finds bugs in your binaries (symbolic execution)

Bugchecker.net – finds bugs in your binaries (symbolic execution)(bugchecker.net)

33 points by wololo 12 years ago | 15 comments

k4st 12 years ago |

As someone that does dynamic binary translation for kernel modules (to find bugs) and eventually wants to get into symbolic/concolic execution (to find bugs), this is cool. I would be really pleased if they're able to make a successful business out of this!

wololo 12 years ago | |

Thanks! If you have any advice, we are all ears.

k4st 12 years ago | | |

I'll try to come up with more ideas as they pop into my head, but given that you consume a binary, I'd like to see a service that consumes core dumps and does what " Automated Debugging for Arbitrarily Long Executions" (HotOS'13) does (a sort of reverse symbolic execution for find the root cause(s) of a the failure). An extension of this idea would be to operate on arbitrary program images, perhaps multiple images, as a mechanism of doing concolic execution.

Are you using concolic execution, or thinking of going in that direction as a way of generating more runtime-specific info, e.g. execution interleavings, data sharing, common values for memory locations, hot paths, etc.

I suppose a bunch of this is probably outlined in your API or integration with one's build system, but it would be great if a lot more about the process and capabilities of this system were detailed up front. For example, I think it would be useful to make some case studies of some programs, in a similar way that the Viva64 guy does for PVS-Studio, as a way of showing people how to use your system effectively.

Otherwise, I find the traces hard to digest. Unless there is some better interface for reading things, I think it would help convince people that your product is useful if, for example, your system reported the bugs it found in a very clear way. If debug info is in the binary then that should also be referenced, etc.

Finally, a passing note: I think your biggest "competitor" is going to be a tool like AddressSanitizer and other compiler extensions. I mean, I know solving more bugs is good for everyone and whatever gets the job done means better code out there, but I assume eventually you need to make money and convince people that you're going to solve a problem that a compiler extension can't. This is kind of the situation for DBT systems now :-P

shard 12 years ago |

The About page talks about Klee, the program that Philip Guo talked about in his story about the trials of PhD life:

http://pgbovine.net/PhD-memoir-prologue.htm

TrainedMonkey 12 years ago |

Just read about: http://bugchecker.net/about - apparently only x86-64 Linux executives. Which is still pretty awesome.

wololo 12 years ago | |

Thanks for reporting this, looking into it. The Windows support is fairly unstable right now. About page updated.

dmix 12 years ago |

I would change on the website:

1) Upload binary 2) Receive Bugs

to:

1) Upload binary 2) Discover Bugs

smtddr 12 years ago | |

Looking at the picture, I'm pretty sure it's intentionally worded that way. A spin on "Push Button, Receive Bacon".

http://knowyourmeme.com/memes/push-button-receive-bacon

dmix 12 years ago | | |

Ah, wasn't aware of that meme. I'd still go "Strunk & White" and keep it concrete rather than clever when writing for a business.

letney 12 years ago |

The console app / bugchecker python script on this page: http://bugchecker.net/console

needs the BUGCHECKER_API_URL = 'http://localhost/api.php' changed to 'http://bugchecker.net/api.php' to work.

wololo 12 years ago | |

Very appreciated, fixing...

nwmcsween 12 years ago |

Have you thought of using something besides uclibc? uclibc has all kinds of corner cases of non-conformity, musl would be a somewhat better alternative. Can this work on shared libraries as well if given a header?

wololo 12 years ago | |

* It doesn't use uclibc. The way it works is the guest program is a snapshot of the target program process after it has been linked with its shared libraries. Usually this means it's linked with glibc (but not necessarily -- cyanogenmod programs are linked with bionic).

* Shared libraries: yes, and it doesn't need a header. Not supported yet in the interface. It does need access to the function symbols though.

nwmcsween 12 years ago | | |

Hmm are you thinking of open sourcing this at all? It seems much different than klee. Personally I would do a two tier model open source getting trickle down and the closed having extensions and target software companies that use things like coverity