-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test/Thread trapping #63
Conversation
Just wanted to let you know that I've started using this PR in my releases, so far so good. Hope it gets merged soon. Perhaps there's no reason to remove execute_while_frozen, and it should be left as an extra? |
Happy to hear that. I don't necessarily want to maintain There are a few things holding up landing this PR that I still need to address.
Feedback that this system is working reliably is really great though and I'll try prioritize landing it (or at least bringing it up-to-date with |
aba9ff4
to
dd08b6b
Compare
I would highly recommend using the latest commit that @cursey just pushed. I was having some major issues with it in a multi-threaded context where trying to execute code in the protected trampoline page would not be caught and handled correctly by safetyhook's exception handler. I was hooking a really busy function, and while the initial hook worked, randomly during the hooking phase of another hook, the trampoline page would be protected, and the exception would not be handled correctly if the original busy function jmped to the trampoline which was now not execute permissible. |
Co-authored-by: cursey <cursey@live.com>
This is a POC/WIP PR that replaces thread freezing with a technique I'm calling thread trapping. The idea is to remove execute access from the pages of memory we're modifying and trap the threads that throw access violations on them until we're done writing our changes to them. We then fix up the IP from within the exception handler itself.
This is intended to be a safer/more reliable/more performant alternative to freezing threads.