|
|
System wide DLL injection in madCodeHook is split into two separate parts:
(1) Injection into already running processes.
(2) Automatic injection into newly created processes.
Part (1) is done with user land code, while (2) is done by a little kernel mode driver, which is shipping with madCodeHook. Or actually it's 2 drivers, a 32bit and a 64bit one. These drivers are shipping in fully compiled form (*.sys), but they will not work, until they are properly configured and afterwards signed with a code signing certificate (e.g. GlobalSign or Verisign).
By configuring the driver file, it gets a unique name. Furthermore you can make a selection of dlls known to the driver, to make sure that the driver will trust these dlls and will inject them without hesitation. The signing process is necessary to make the driver load in newer OSs (especially in x64 OSs). The signing also makes sure that the configuration can not be modified, anymore, because doing so would invalidate the signature. A configured & signed driver is only willing to inject those hook dlls which are known to it, or which were signed with the same code signing certificate as the driver itself. Injection of untrusted hook dlls is always refused.
The injection driver must be manually loaded or installed by using the driver control API.
First of all your custom driver needs to be loaded/installed. There are two different options:
(1) The normal way is to install the driver permanently, just like a service. If you do that, the driver will be visible to the end user (it's listed in the device manager, if you activate certain options). Furthermore the driver survives reboots. The advantage of this solution is that the driver doesn't play "hide and seek", so it should look less dangerous to security applications. The disadvantage is that your software needs both an installation and deinstallation logic.
(2) Instead of permanently installing the driver, you can also simply load it dynamically. If you do that, the driver will stay loaded until you either stop it, or until the end user reboots the OS. The advantage of this solution is that you don't need to provide an installation/deinstallation logic. The disadvantage is that dynamically loading a driver might look slightly more suspicious to security applications, because a dynamically loaded driver is mostly invisible to the end user.
madCodeHook contains APIs for both approaches described above. There are also APIs available for stopping and restarting the driver. See here for a detailed description of all available injection APIs.
In order to stop malware programmers from misusing madCodeHook, there are several layers of protection:
(1) You need to sign the kernel mode drivers yourself. Most malware programmers will probably lack a valid code signing certificate. And even if they have such a certificate, it can be revoked if it's used to create malware. And it can also be easily used as a search criterion for security applications.
(2) The driver strictly refuses to inject any dlls which were not made known to the driver at build/configuration time (unless the dlls are signed with the same certificate as the driver). This makes sure that a malware programmer can not misuse your driver to inject his own dlls.
(3) When your application tells the driver to inject a specific dll, the driver calculates a hash of your exe file and stores that together with the injection request information. The driver later only accepts a "stop injection" request from a process if the exe file has the same hash as the one which started the injection (or if the exe was signed with the same certificate as the driver). This makes sure that a malware process can not simply hack into the application/driver communication to stop your dll from being injected.
(4) Even if you configure your driver to support being stopped (safely), a stopping request is only accepted by the driver if it was issued by the driver injection API. Stopping the driver through the normal service/driver OS APIs is blocked. Furthermore the driver accepts a stop request only if no dll injection requests are active. This should make sure that a malware process can not simply stop your driver behind your back.
|