Serious Discussion Why does the Comodo "Disappearing HIPS rules" bug require a complete source code rewrite?

Is an ELAM driver not tailored to do only the things @GenV indicated in his post?
Basically, ELAM is used to allow/block other boot drivers by checking with malicious digital signatures db in registry, then it unloads and "passes the torch" to regular protection driver (its MS recommendation for the ELAM/AM drivers). I think it couldn't be used for anything else.
MS has pretty strict requirements for ELAM driver performance:
View attachment 291940
Also, it stores certificates required for AM service to start as PPL-AM process.
 
The original bug is undeniably still present. It's almost impressive that the 2025 version manages to maintain the same random device-crashing feature. Naturally, I'll be sure to hurry up and install this for everyone I know.



 
  • Like
Reactions: Pico
The original bug is undeniably still present. It's almost impressive that the 2025 version manages to maintain the same random device-crashing feature. Naturally, I'll be sure to hurry up and install this for everyone I know.



Remember, remember the Comodo forum, and the reported bugs and problems that were said to be not. I know of no reason why Comodo should not forever be forgot.

1760614698960.png


1760614826450.png


1760614906997.png
 
Last edited:
Is an ELAM driver not tailored to do only the things @GenV indicated in his post?

"The ELAM feature provides a Microsoft-supported mechanism for antimalware (AM) software to start before other third-party components. AM drivers are initialized first and allowed to control the initialization of subsequent boot drivers, potentially not initializing unknown boot drivers. Once the boot process has initialized boot drivers and access to persistent storage is available in an efficient way, existing AM software may continue to block malware from executing."


By modifying the ELAM driver, you can initialize the "HIPS recovery" driver before some other drivers.
 
  • +Reputation
Reactions: simmerskool
Remember, remember the Comodo forum, and the reported bugs and problems that were said to be not. I know of no reason why Comodo should not forever be forgot.
Seems like from the start it was designed in a way that is less than sensible. If one module requires you to rewrite the whole product.

By modifying the ELAM driver, you can initialize the "HIPS recovery" driver before some other drivers.
Highly unlikely. Microsoft uses very complex management logics on how drivers will load based on startup type, group, dependancies and so on. It is unlikely that Microsoft will allow Comodo to tamper with the established boot sequence. The system boots the way Microsoft had decided it should be booting, and not the way Comodo needs to arrange it in real time, to save money on R&D.

The most sensible way remains minimal HIPS config till the userland service parses a config and buffers it. Furthermore, checking signatures reputation, checking for revocation, checking for updated reputation and all these operations which HIPS probably needs will require active internet connection. Though I wouldn’t be surprised if HIPS from Comodo does none of that.

Anyway, if what Melih is saying on the forum is true and not just an attempt to brush users off (which is also possible and much more believable), any workaround would require loads of work.

As @bazang noted, these works require users to enter their CC details and subscribe.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Highly unlikely. Microsoft uses very complex management logics on how drivers will load based on startup type, group, dependancies and so on. It is unlikely that Microsoft will allow Comodo to tamper with the established boot sequence. The system boots the way Microsoft had decided it should be booting, and not the way Comodo needs to arrange it in real time, to save money on R&D.
That's how I understood @GenV post.
 
Anyway, if what Melih is saying on the forum is true and not just an attempt to brush users off (which is also possible and much more believable), any workaround would require loads of work.
Not surprisingly that XCS has new codebase to fix this (and other) issues but not sure if it's a completely rewritten CIS codebase.
 
  • Like
Reactions: Trident
Not surprisingly that XCS has new codebase to fix this (and other) issues but not sure if it's a completely rewritten CIS codebase.
Certainly a lot of portions of the software have been rewritten. Rewriting is not something scary. Norton for their 2009 edition had over 500 engineers looking at the code, implementing thousands of optimisations.
After that, the rewrote the entire scan engine, previously very much kernel-based, the SDS is entirely in userland.

McAfee rewrote every portion of their software too.

If you wanna make money then you gotta invest.
 
Anyway, if what Melih is saying on the forum is true and not just an attempt to brush users off.
In the old forum Melih would post retorts to complaints such as "Software has bugs." However, I think in the case of the post in question about the disappearing HIPS rule bug, he meant it.

He often would say on the various software sub-forums "due to the resources needed we will not...".

Those words meant to me back then that the future of any of his software would be "problematic."

One thing is for sure. Comodo has a 99% abandonment rate for all of its software.
 
Highly unlikely. Microsoft uses very complex management logics on how drivers will load based on startup type, group, dependancies and so on.

This seems to contradict the information from Microsoft documentation:

"The ELAM feature provides a Microsoft-supported mechanism for antimalware (AM) software to start before other third-party components. AM drivers are initialized first and allowed to control the initialization of subsequent boot drivers, potentially not initializing unknown boot drivers."

So, let's agree to disagree.
 
Where
This seems to contradict the information from Microsoft documentation:

"The ELAM feature provides a Microsoft-supported mechanism for antimalware (AM) software to start before other third-party components. AM drivers are initialized first and allowed to control the initialization of subsequent boot drivers, potentially not initializing unknown boot drivers."

So, let's agree to disagree.
The answer is in the copied text. So yes, we’ll have to disagree.
 
  • Like
Reactions: simmerskool
Agree. If CIS was well maintained with good support then much more users would be prepared to pay for it.
The software owner, Melih, is ideologically against paid security software - or at least that was his stated position back then for CIS/CFW. There is no evidence that he has changed that position. He said it many times - "I think it is good enough" or something that essentially meant the very same thing.

He instructed his few developers at the time to study the various internet security suites available on the market at the time, and to copy the features - much of which was based upon Kaspersky's feature set.

The objective of the entire project - of any of his software projects - was create a software and then release it at zero cost. However, that means he is paying for the expenses out of his own pocket. Even before he starts a project, he has a "resource" limit already set in his mind for the project beyond which he will not go. And hence, you get software such as CIS/CFW and all the software that was abandoned.

CIS/CFW is only on spaceship minimum power life support at this point, and the CO2 scrubbers and heat are non-functional.
 
Last edited:
Here is an example from Sophos:

1760641122709.png


Although this does not indicate that the ELAM driver can affect the loading order, it shows that it is possible to force some drivers to be loaded earlier than many others. In the case of Comodo, the "HIPS restore" driver should be similar to that from Sophos.
 
Last edited:
Here is an example from Sophos:

View attachment 292031

Although this does not indicate that the ELAM driver can affect the loading order, it shows that it is possible to force some drivers to be loaded earlier than many others. In the case of Comodo, the "HIPS restore" driver should be similar to that from Sophos.
The Elam architecture was explained by Microsoft in various webinars many years ago and even at one point a sample code for ELAM was published.

What Microsoft wants in this driver is:
The driver starts at third or 4th position. Before this driver is the kernel and a very primitive cryptographic driver which assists ELAM in verifying signatures.

The ELAM configuration and communication logically is in the registry.

The registry contains information to identify malicious drivers and drivels.

Elam driver registers kernel callback, the kernel feeds information ELAM which drivers it plans on loading, pausing before it does so, waiting for the ELAM return.

The ELAM driver on a loop checks every driver loading via the information provided in registry and returns the result.
The Kernel decides whether it will load or it won’t load the driver.

No deletion or driver calls happens, the ELAM is merely a kernel extension.

The entire process as well as the requirements for years have been well documented and very well known.

They don’t require the standard whql certification for elam I believe, it just has to belong to a registered AV vendor and should be as simple as possible.

I am not excluding the possibility that with hefty payments and qa processes, MS may have allowed Sophos to do more.
 
Last edited:
  • +Reputation
Reactions: simmerskool