On Driver install - Say driver install, not registry modification!

As shown in this thread:
It’s not at all obvious that a protected registry entry
is the same as a Driver install to even power users or some IT people. I hope that in the future D+ can specifically warn on a Kernel or other Driver install as a driver install so it’s clearer what exactly a program is trying to do.

I think that in any case where it’s possible, Comodo should try and use less technical terms with full details availble if requested by the user in a tab of the pop up or some such.

I’m a professional IT Sysadmin, I’ve read the Windows Internals 4th ed etc, and I just learned from that thread that a Registry entry like above denotes a driver install.

i couldn’t agree more wholeheartedly with this request. i currently use process hacker, but what’s more, i personally experienced a situation in which distinguishing between registry protection and driver installation would be very helpful! see this thread here:


i also think relying on registry protection, protection of certain file/folder directories, and other filters to prevent driver installation may also result in more popups and potentially less protection overall than a single, solid driver protection filter:


i think in general, relying on registry protection to protect against drivers and rootkits is more difficult. let’s take a look at specific examples:


defense+ protects against only part of the second line; it doesn’t even look at the first line. when i say “part” of the second line, i mean it only detects a few sub entries, but not the entire group. sure, you can manually enter both of those lines in the registry protection filter, but then you would be faced with a LOT of pop ups, since those lines contain many sub entries themselves. those 2 lines aren’t even everything, as demonstrated by the second link above. these are gaping holes in defense+.

what this indicates is that the filter to protect against device driver installation should be improved. this will eliminate the need to manually add in a new line to the registry filter or add a new folder directory to protect against a new exploit. regardless, such hard coding wouldn’t work against unknown exploits as well as blocking the driver directly would.

i believe CIS is a great product, but it can be made even better. :slight_smile:

I totally agree with you. Ver very important point indeed.

Thanks for the tests, Aigle. There was extensive discussion in this thread about the implications of allowing some driver alerts to be mixed in with registry alerts:


While in theory, Defense+ has not been bypassed because one of the hundreds of registry alerts allowed the user to block the driver installs, I must make two points:

  1. A casual user risks not understanding the exact registry entries that correspond to driver installation. Hence, this casual user, thinking the driver installation alert to be no different from the registry alert, risks allowing the activity without understanding the full consequences of such an action.

  2. A more experienced or expert user would recognize the specific keys that correspond to driver installation alerts. However, in order to pick this alert out amongst the hundreds of other trivial ones, they would have to either carefully scrutinize every alert, thus wasting precious time, or simply click past many at once, thus allowing the driver install. Neither of these options are acceptable.

In essence, Defense+ is fine on a theoretical level, but in practice, it can be easily bypassed. Driver installation is not the same as registry modfiication. The difference is critical in both its theoretical and practical aspects, for all classes of users, new or experienced, and the implications are grave. Being able to correctly alert users to driver installations is one area in which Defense+ could and should vastly improve in the next version. An important function of a HIPS is to act as an anti rootkit. What good is it if it allows driver installs by poorly alerting the user?

Now, let’s put this problem in perspective. There are two other ways in which Defense+ can be improved in the area of preventing driver installs:

  1. Protected files/folders. Take a look at reply #17 (egeman’s post) in the following thread:


The topic is locked because the last post before mine was August 2008, but it is as relevant as ever. Confusing protected files/folderrs with driver installations is dangerous for the following two reasons:

a. There are many protected folder directories. Only a small handful of them pertain at all to driver installations. Therefore, relying on protecting file/folder directories to prevent the installation of drivers risks mixing in the driver installatoin alerts with the protected file/folder alerts in the same way driver installation alerts can be mixed in with registry alerts.

b. Only some methods of driver installation require the file to be in Windows\system32\drivers. Thus, methods that do not have such a requirement will not be caught by the protected file/folder method.

  1. Here is the final way in which Defense+ can be improved: Detect driver installation attempts even by system applications when they are invoked by COM access. This can best be seen by Egeman’s reply #17 in this post:


services.exe or svchost.exe is trying to install a driver. So what? This happens a lot, right? It is precisely because such events are so common that users need to be alerted as to WHICH file is invoking services.exe or svchost.exe. They don’t invoke themselves. The COM access is nice to have, but it does NOT eliminate the need to also alert users that services.exe or another system application is trying to install a driver.



I have said a lot in these posts. Let me sum up this entire Wishlist suggestion in a few lines:

I. On driver installations, do NOT mix in the alert with registry modifications. Separate the two so that users do not confuse trivial registry alerts with driver installs.

II. On driver installations, do NOT mix in the alert with protected files/folders alerts. There are many protected folders that do not involve driver installations, and there are many drivers that do not need a file in a specific folder to be installed. Separate driver installation alerts with protected files/folder alerts so that users do not confuse trivial protected files/folders with driver installs.

III. When an unknown application attempts to invoke a system application to load drivers, whether through COM access or by any other means, combine the invocation alert (COM access being one example) with the driver installation alert. A good example alert would be as follows:

Program xyz.exe, through protected COM Interface ABC, is attempting to use services.exe to load driver xyz.sys.

[ ] Allow this request [ ] Block this request

Implementing I, II, and III in the next version of Defense+ would give Defense+ far greater protection against driver installations, and thus the threats that are associated with rootkits. Thank you for your concern.

+10000000000000000000000000000000! ;D

forcespawn , your reply #3 is the most thorough research of this case i saw so far. well done!

you also could (can :slight_smile: ) include documental proof :). IMO in this case you research is forced and easier to follow and understand.

for example, for:

I. On driver installations, do NOT mix in the alert with registry modifications. Separate the two so that users do not confuse trivial registry alerts with driver installs.
current unsatisfactory Defense+ behaviour can be proven by note to run Proof of Concept attached to [url=https://forums.comodo.com/feedbackcommentsannouncementsnews_cis/cfp_poor_pop_up_alerts_by_compared_with_other_hips-t44186.0.html;msg319780#msg319780]this post[/url] and/or by note to see [url=http://www.wilderssecurity.com/showpost.php?p=1526873&postcount=2]this post[/url].