>>22
Of course I don't mean that I would try to gain understand of every little detail. Such things, while possible would be a huge waste of time for most applications, but you also overestimate how hard it is to gain understanding about the functionality of binaries. I sometimes find it easier to just do a binary patch than recompile an application when source is available:
A few years ago, I encountered a PRNG bug in a certain GPLed multimedia container tool suite. The bug managed to cause the GUI and applications to hang as it was generating the same id for objects which were required to have different ids. (I don't recall all the details about it right now, it's been a long time, but in short, an infinite loop was entered because some object identifiers which were meant to be unique were not. ). I whipped out my disassembler and debugger and located the bug. The conclusion was that that specific routine would need to be rewritten. It took me about 20 minutes to write a replacement function in x86 asm and patch it in in one of the libraries used by the application. Mind you, source was available to this, but it was just easier to locate the bug with a debugger and patch the binary. I already had my fix, but of course it's a crappy, hacky fix, as the fix was limited to my platform(which was enough for now), and I would have to redo this for future versions unless I got the fix in the official trunk. I then proceeded to obtain the source, spent some 10 minutes guessing the location of the bug in the source code, and eventually located it. Building the application and its dependencies with MINGW took over an hour, damn SEPPLES, and getting the fix incorporated in the main code base took a couple of days submitting tickets and talking to people on IRC. Which was easier? a 20 minute quick binary fix to a GPLed binary, or a few days of bureaucracy to actually get it fixed properly and incorporated in an official build?
You also seem to claim that it's impossible to make meaningful major changes to binaries. I think that depends on how much knowledge someone has about them and how much time the person is willing to spend on the process. I've seen quite a few such projects which involved replacing 10-20% of a binary application with code loaded from an external module. Sometimes there were ways to make this easier(debug symbols), other people actually had to do quite a bit of reverse engineering work to comprehend the internals. In some cases such things may be worth it, but in others, it's better to just understand the concepts and reimplement everything yourself - it can be faster.
It's hard enough to comprehend someone else's shitty source code, and now you expect programmers to do the same for compiler generated machine code to a non-trivial system? No, it's just not practically possible.
It took me less time to locate that bug and understand the cause of it by looking at the disassembly, than it took me to understand the underlying SEPPLES code.