Bugchecker.net – finds bugs in your binaries (symbolic execution)
bugchecker.netAs 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!
Thanks! If you have any advice, we are all ears.
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
The About page talks about Klee, the program that Philip Guo talked about in his story about the trials of PhD life:
Just read about: http://bugchecker.net/about - apparently only x86-64 Linux executives. Which is still pretty awesome.
Thanks for reporting this, looking into it. The Windows support is fairly unstable right now. About page updated.
I would change on the website:
1) Upload binary 2) Receive Bugs
to:
1) Upload binary 2) Discover Bugs
Looking at the picture, I'm pretty sure it's intentionally worded that way. A spin on "Push Button, Receive Bacon".
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.
Done.
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.
Very appreciated, fixing...
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?
* 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.
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