madshi wrote:There are various ways to inject DLLs. Some of them are offered by the OS itself, e.g. see AppInit_Dlls. madCodeHook's DLL injection driver is just one more method to inject DLLs. Why would they not approve?
Which injection technique does madCodeHook injection driver use to inject a DLL into the user-land process, is it the APC?
madshi wrote:Anyway, I don't think they actually perform any tests on the drivers.
So, you're saying that they don't actually perform any thorough tests on the driver. Since you have to send a compiled driver to the dashboard, they would have to reverse engineer the driver in order to determine what exactly it does. But since there are probably multiple drivers send to the dashboard daily, they don't have the time to do it manually, while the automatic detection isn't good enough to detect a lot of things.
However, if they upgrade the detection techniques in order to detect that madCodeHook is injecting a DLL into the user-mode processes, can they nevertheless mark the certificate as malicious? For example, if we sign the madCodeHook with our own certificate and ship the driver to customers, then some kernel endpoint protection detects it's being used to inject a DLL and marks the driver as malicious, which eventually gets sent to cloud for analysis and after some time gets into the Microsoft's hands. After their team analyzes it manually, they will confirm it's injecting the DLLs into the user-mode processes and blacklist our own certificate (since this is the certificate with which the driver was signed). The end result would be that none of the other things signed by the same certificate will be valid anymore and all of a sudden every product across the world will not be able to work, since the certificate validation/signing will not be valid.
I hope I'm not overly concerned about all this, I would just like to understand things in details.