[Shub-Nigurrath]

Hi
two hints: the __security_check_cookie is just another thing, tied to stack canaries (http://www.codeproject.com/Articles/1854/Compiler-Security-Checks-In-Depth) and second, for sure one of the above hash functions is involved in the strange behaviour.

What I would suggest to do (simpler solution, at least from my point of view) is to do an interactive loader that does these steps:

1. load the exe in debug mode
2. put an HW breakpoint in the right place (not a real BP, just to not raise mismatches in the hash checking functions). Place it in a stable place to avoid ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization) if you run on Win7 onward, or calculate using stable anchors (for example a BP in an API).
3. start the victim and wait for the HWBP to hit
4. find from there the right place to patch and place another HWBP just after the execution point
5. restore the original code

Quite complex indeed, but not once you know how to do it, and most of all you could find all the required theory in my tutorials on writing loaders available at the ARTeam site.

The alternatives are
1. do the loader direcly in ASM and embed it into a stub of the exe, as an in process injected code
2. defeat all the hash placed in the code.
3. see if you can patch outside the exe itself (for example whe you deal with nags sometimes you can patch the loaded user32:MessageBoxA/W to immediately return)

BR,
Shub