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.
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.
It's just an expensive product and IDA/Hexray's owner/designer is very paranoid about piracy(up to the point that even if most of the user base that uses IDA has a pirated copy, he refuses to accept legitimate bug reports if they don't come from real people who payed for it), so he tries to only sell to real companies which work in this field. It still doesn't stop people from leaking or stealing it in different ways, so it's always pirated about every half a year, so you can see why he keeps attempting to stop his product from leaking. There were claims that the sales tend to drop considerably after each leak.
IDA+plugins is actually cheaper than a lot of other professional software where the marker is so small.
Implementing what IDA can do isn't really that hard to do, and there's nothing stopping other people from doing it, except that it's just a lot of work to code processor modules(disassemblers) for all those CPUs, executable module loaders, signatures, types and so on. There are similar projects, but they don't come with a nice fancy easy-to-use GUI like IDA. Actually, reversing without IDA is perfectly doable, it's just that it's nice being able to save your disassembly data in a accessible and queryable database.
How else can we explain this discrepancy of the only close-to-working decompilers being closely-guarded assets?
Other decompilers out there aren't that bad, but they don't always come with an easy to use interface where the user can guide the decompiler, so it's a pain to work with them, even if some may be based even on better ideas than Hex Rays, secondly, Hex Rays borrows IDA's disassembly engine and can query the user created database, this makes it much easier for it to tell between data and code, as well as locate pointers, thirdly, it's still easier for a skilled reverse engineer to decompile a function by himself ( or simply read the asm directly ) than to use Hex Rays when a function is fairly complex.
Even Hex Rays doesn't quite pass the equivalency test, nor would I guess that they want it to.
It's mostly for reverse engineering work, this means its goal is to help the reverser understand the function by presenting it in an easier to understand form than asm. If your goal is to just rip someone else's code, then you don't need a decompiler at all, a disassembler is enough, and in some cases even a disassembler isn't needed(if relocations are present).