Today madCodeHook 4.1.0 introducess an optional new DLL injection technique:
The new technique has a couple of advantages and disadvantages compared to the "old" one.
Because of that the old technique stays the default. The new DLL injection technique works
by modifying the EXE's import table in such
a way that the OS loader believes that your hook DLL would be statically linked to
by the EXE. This brings us the following advantages:

The OS loader actually now loads your hook DLL for us, when initializing the
new process. Which means we don't have to inject any code patches into newly
created processes, anymore, or hook any APIs. So this solution should be cleaner
and simpler.

Your hook DLL will be listed as the first DLL the EXE statically links to. As
a result, the OS loader will load your hook DLL first, before any other statically
linked DLLs. Which is a big advantage because it means your API hooks will be
installed before any statically linked DLLs have a chance to do anything.

There's no free lunch, unfortunately, so the new DLL injection method also comes
with a couple of disadvantages:

Since the OS considers your hook DLL as being statically linked to by all
newly created processes, the OS will refuse to unload your hook DLL from any of
these. This practically makes uninjection impossible.

The EXE import table uses ANSI chars. So your hook DLL file name/path must
consist of ANSI chars, only. No Unicode supported. Maybe you can workaround this
issue by using GetShortPathNameW(), though.

If for any reason a newly created process is not able to load your hook DLL,
the OS loader will show an error message and refuse to let the process run.
In a worst case scenario it's possible that no process can be created at all,
anymore. So you need to make sure your hook DLL can always be successfully loaded.
Avoid statically linking to any weird DLLs, avoid weird manifests and make sure
the NTFS rights allow read & execute for all users.

Another bigger change is that the DLL injection driver now supports storing the
public key of your signing certificate. Let me explain why this is useful:
Recently, Microsoft changed their EV signing procedure. They used to just add
their own certificate to your's. But now they completely remove your certificates
in some situations, which makes madCodeHook's driver unable to successfully match
the driver's signature with the hook DLL's signature. I've made 2 changes now to
work around this problem:

The driver will now compare the hook DLL's first signature with *all* of the
driver's signatures (not just the first one). So you can make the signature matching
work by re-adding your own signature to Microsoft's EV signature.

Some (security) users mentioned that such a more flexible signature match might
not always be 100% secure, because the matching might actually find matching Microsoft
signatures instead of your private signatures. As a result, I've added an option
to the "madConfigDrv" tool which allows you to bind the driver to your specific
certificate. This way the driver will only accept hook DLLs as trustworthy which
are really signed with your specific certificate.

Please note that some of these changes are going rather deep, so although in my tests
everything worked nicely, please consider the new features somewhat "experimental".
Which means I'd recommend that you test them throuroughly yourself before using them
in production software. I'm optimistic about that they work well, though.

2018-05-31

Today madCodeHook v4 introducess a relatively "big" new feature:
You can now register a user mode callback, which the driver will call for all
newly created processes which match your injection
criteria. Your user mode callback then has the option to approve or reject DLL
injection for each newly created process.
Please note that this kind of callback from a driver to user land, which delays
the start of new processes, is not recommended by Microsoft. So use this new feature
at your own risk! It seems to work pretty well, though.
If you do use this feature, please make sure your callback executes as quickly
as possible, to avoid any unnecessary delays for newly started processes.

Furthermore, both the new madCodeHook v3 and v4 build now disable the "parallel
DLL loading" feature of the Windows 10 OS loader, for any processes we inject
our hook DLL into. "Parallel loading" basically tries to initialize newly created
processes in a multi-threaded way. This OS loader feature can make problems if
DLL injection and API hooking is used. Consequently the OS already disables it
itself in certain situations. Now madCodeHook does that automatically, which should
help Windows 10 stability.

Please note that madCodeHook 3.0.18 is probably going to be the last v3 build! I will
concentrate on madCodeHook v4 development and support now. Which means if you
haven't upgraded to v4 yet, now might be a good time. To make your decision
a bit easier, I'm reducing upgrade pricing from 60% (of the price of a new license)
down to 50% for the next 2 weeks. This price includes one
full year of subscription. After that year has passed, you can optionally renew
the subscription for a yearly payment of 30% of the price of a new license. If you'd
like to upgrade from v3 to v4, please contact me via email, thank you!

A more detailed description about the various improvements is available here.

I've decided to move to a subscription based licensing model. Please don't worry about it, I think the terms and conditions
are more than fair. My pricing math works out like this: If I release a major new upgrade (madCodeHook 4.0, 5.0, 6.0 etc) every 2
years, and ask for a 60% upgrade price every time, this sums up to the same 30% yearly subscription rate I'm asking for now.
And you can just let the subscription run out at any time and you're still allowed to keep using the version you're on forever.

There are a couple different reasons why I'm switching to a subscription model: For one, it gives me a more predictable
income. Furthermore, I don't have to save major functionality improvements for the next major upgrade, anymore. Instead
I can now constantly and regularly work on improving madCodeHook, which should be a benefit for everyone. Finally, I hope
that including a reasonable yearly payment into your budget might be easier than fitting in a much larger upgrade price every other
year.

The exact terms of the subscription model, with full upgrade pricing etc is explained on the shop
page. If you have a need to discuss this payment model change, or the upgrade pricing, please feel free to contact me
email. I'm open for discussion and reasonable arguments.

· added support for XE5· added madTraceProcess64· added "largest free block" header info· fixed a couple of weird bugs· madExceptWizard: patching is now always moved to madExceptPatch tool· madExceptViewer: newest bug report is now listed on top

· added support for XE4· fixed: IPC in Metro apps only worked without replies· fixed: win9x hooking eventually crashed· fixed: FOLLOW_JMP eventually modified export tables· fixed: UNICODE_STRING in internal structure was not aligned properly· "driver only" injection now works without admin rights (if driver is already installed and running)