>>24
"See if"? As if you don't think we've considered that? I wish I could disclose the details, but I'll just say it's more amusing to see the exploits that have been
added by these "security patches"...
>>33
Maybe the average neet exploit finder living in a basement doesn't have a tool like this, but you can bet your ass that the professionals do.
It's not a "tool", it's a whole bloody
system. Said exploit finder would likely not have the compute resources either, so we're just giving the professionals even more firepower if we released it; we realise not releasing it won't prevent hacking, but at least it won't make exploit rates rise dramatically.
>>34
We're basically trying to solve the Halting Problem here, and how far you can go depends on how much storage and processing power you have. There's nothing we can do about that; state/path analysis is naturally resource-intensive.
>>38
This is not a debugger (unless you mean that it can find the bugs for you...), nor a simple-minded single-use-case thing like IDA. The use cases are also completely different; it's not a realtime "load this program in a debugger and step through it to see what's happening", it's more like "analyse this program and see
all the possible things it could do." I wouldn't call this a decompiler either, since being able to generate the semantically equivalent HLL code is just a side-effect of this process.