v4.0 Information 


What Is New In madCodeHook 4.0

•  new "permanent" dll injection option survives reboots
You can now "install" your injection driver and then issue "permanent" dll injection requests. The driver will store such permanent requests and re-apply them automatically, every time the OS reboots. As a result you no longer need a service or application to restart the whole dll injection, when the user rebooted the OS.
•  verification of hook dll's code signing signatures
When using madCodeHook 3.x, you had to make all hook dlls known to the injection driver, or else the driver would refuse to inject the hook dlls. Furthermore, every time you touched the hook dlls, the injection driver needed to be updated, too. This whole solution was very safe, but also quite uncomfortable. Which is now all the more true, when trying to achieve SecureBoot compatability in Windows 10, where your drivers need to be sent in to Microsoft to get co-signed. madCodeHook 4.0 now checks the hook dll's code siging signature. If it's valid, and if it was signed with the same certificate as the driver file, then the hook dll is automatically considered "trusted". This should still be a very secure solution, but it's now also completely comfortable. As long as you sign your hook dlls with the same certificate you sign your drivers with, you only need to configure and sign the driver once now.
•  API hooks can now optionally record the caller's "thread state"
When trying to detect malware attacks, it's very useful for security applications to know the exact contents of the registers and the exact parameters on the stack of the caller of the hooked API. When using madCodeHook 3.x, it was only possible to get that kind of information by using hand written assembler callback routines. With madCodeHook 4.0 you can now activate this functionality with a simple flag and then in your hook callback function simply access all the information through a comfortable structure.
•  stable cleanup of your hook dll resources
Usually a hook DLL frees its resources in DllMain(DLL_PROCESS_DETACH). However, this can be dangerous because of the loader lock. For example, you can't wait for secondary threads to finish because they're usually blocked from running while you're in DllMain. madCodeHook itself unhooks all of your API hooks automatically, in the moment when you uninject your hook DLL - and it's doing that outside of DllMain. In order to allow you to also cleanup your stuff outside of DllMain, you can call "RegisterUninjectCallback()". Your callback function will then be called after madCodeHook has uninstalled your API hooks, and right before FreeLibrary is called on your hook DLL.
•  new optional dll injection technique (for newly created processes)
Although the madCodeHook 3.x injection technique (for newly created processes) has proven to be very stable and reliable, a new technique was added, which you can use as an option. The new technique has the advantage that your hook DLL will be loaded and initialized very early, when a new process starts up, before all other DLLs that are statically linked to by the EXE. It also has a disadvantage, though: Since your hook DLL will be considered as statically linked to by the EXE, the OS will refuse to unload your hook DLL from newly created process, which makes uninjection impossible.
•  improved compatability with other hooking libraries
madCodeHook 3.x used a 6-byte absolute JMP instruction to hook APIs, while most other hooking libraries are using a 5-byte relative JMP. Although both approaches are perfectly legit, and madCodeHook's solution was very stable on its own, sometimes there were compatability problems. That's especially true if "the other" hooking library was of inferior quality and didn't know how to properly handle madCodeHook's 6-byte JMP. In order to improve compatability, I've now also switched to using a 5-byte JMP in madCodeHook 4.0.