Decompiling

decompilers (fail to) work as such: find which architecture -> disassemble -> pattern finder/search for common code segments/idioms, language dependent -> turn into higher level code. it would seem to me what is needed is a good database of the high-level -> assembly idioms, that the decompiler accesses at run time and is always updated as new links are found (thinking that the decompiler would be part of a suite with other tools to help find these links). how many different ways do different compilers really have available to make "if(a==b)"? and more complex code is just combination of these smaller parts. assuming they optimize when compiling, that's what's really needed, a way to keeping track of these different ways of doing the same thing, slight variations, etc., and of course a way to find them in the first place (the suite i mentioned, which i also have ideas for; properly formatted assembly for starters). i don't get why decompilers don't work.

>>16
I'm a bit curious how better would an automatic decompiler work if it were being fed all the needed structures from header files and prototypes from PDBs.
Doing so is trivial, but has anyone actually written a decompiler that does that yet? Or even simpler, a decompiler that can pass the decompile -> compile equivalency test e.g. 90% of the time? Also, consider that one of the best disassemblers out there (IDA) is fucking expensive and its distribution is highly controlled, and the same goes for Hex Rays. They obviously do not want this sort of technology to become widely available. Even Hex Rays doesn't quite pass the equivalency test, nor would I guess that they want it to. Free generally-available decompilers are out there, but are rare, and the ones I've tried range from useless to worse than reading the Asm.

Think about it. How else can we explain this discrepancy of the only close-to-working decompilers being closely-guarded assets?