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

Anyway, even properly working Paranoid HIPS will cause many problems with software or system updates.
If one reads the Comodo forum, the moderators are not fans of HIPS.
The users have already passed a judgment. Most of them happily skipped HIPS.
Because most people cannot handle the complexity of HIPS.

The moderators on the Comodo forum don't promote HIPS because they are aware of the HIPS bug and HIPS overall setting complexity and don't like to be bother with all the fuss around it. Also @cruelsister repeats it every time, don't use HIPS keep it simple. Yes keep it simple, don't use HIPS and CIS' own resources will no longer be protected by HIPS anymore, introducing a security flaw, so great!

One doesn't have to use HIPS Paranoid mode at all. HIPS Safe mode is excellent and very user friendly without all the prompts / alerts.
 
That's an interesting question, and one that's becoming more relevant as AI tools evolve. Personally, I see it as a positive thing overall—especially in a community like this where clear, factual communication can make discussions more productive and less prone to misunderstandings. If a user is inputting their own ideas and phrasing, then using AI to polish it into something concise and emotion-free, it's essentially like having a really good editor. It helps keep the focus on the info being shared, which is great for learning and collaboration.
Bro, you seem pretty lonely! How about a romantic getaway with the smokin' hot babe, Ms. Gemini? She's sure to keep you Googly-eyed for a week!
 
  • HaHa
Reactions: Trident
There are loads of applications reading and writing in registry.

This is different because it is linked directly to suspending and allowing in-memory actions in real-time. Furthermore, alerts must also be visible. All of this can be impossible to properly handle during the system shutdown or system crash.

Also why would it read from many places?

HIPS can be called by many different CIS modules depending on the current HIPS settings. It all depends on how it was coded.

If there is registry reading happening, one function can return all the reading needed?

It could, but it is probably not the case in Comodo. The application in the beginning is usually very different than after 15 years. It is hard to plan optimal functions.

In addition, it can be reworked from scratch to use xml, json, database or even something totally new/unseen before. It can immediately save in temporary files and on next boot, it can merge the temporary files with the persistent one.

If it could, the developer would probably have done it.

Even a csv file can be parsed and can contain the rules for that matter.
The old functions can still remain, just the calls in the HIPS module will be updated.

The code may be different from your assumptions. As I said, it probably reads the HIPS settings from many locations via many different functions.
The code was probably not optimized for many years.

Rewriting elam should not be necessary, a comodo signed process should be allowed after authorisation to merge the databases

The system can crash before the databases are merged. That is why the merging has to be done by the ELAM driver before the CIS services and drivers start. It does not matter if those databases are stored in the registry or in the files on the disk.
 
If it could, the developer would probably have done it.
I think your trust in Comodo is way higher than what it should be.
It could, but it is probably not the case in Comodo. The application in the beginning is usually very different than after 15 years. It is hard to plan optimal functions.
That doesn’t really matter, I’ve studied way after 2010 (15 years ago as you’re saying) but the OOP paradigms date way back, before this stage.
I don’t see any reason why it would need to read the rules from many locations.

One single module can act as a rules manager/processor (in fact I would name it ruleProc.dll) and it needs just one class (registryHandler). Inside, you can define whatever functions you need (which will include reading, writing, editing, deleting), although realistically it could also be one function with parameters. It can also communicate with kernel drivers and can store in memory.

I am not sure why this developer will come, write a function, read the registry, that developer will come, write a function, read the registry…
If you implement everything 15-20 times, you will end up with code that can compete with the Windows Vista installed size. Without the databases…
 
  • Like
Reactions: simmerskool
If I recall correctly earlier versions of CIS protection did operate partly in User Mode and partly in Kernel Mode. Later versions (and up to the latest) CIS protection operates mainly in Kernel Mode. However both old and new versions suffer from the same bug so chances are real that the issue happens in Kernel Mode code.
 
  • Like
Reactions: Trident
If I recall correctly earlier versions of CIS protection did operate partly in User Mode and partly in Kernel Mode. Later versions (and up to the latest) CIS protection operates mainly in Kernel Mode. However both old and new versions suffer from the same bug so chances are real that the issue happens in Kernel Mode code.
I remember there were some HIPS drivers. Though the main protection algorithms (which include hardware manipulations as well) must be in kernel mode (in user mode they won’t help you too much) the rules processing has absolutely zero reason to stay in the kernel. All that has to be done, upon new rule, all rules must be put together in a buffer (so kernel can access) and at the same time (or with some delay) you gotta propagate to the persistent storage (be it in registry, in file, sent to an api or printed and stored underneath the bed).

In kernel mode, you should have nothing more than one policy enforcer, just like the ELAM should be a small driver merely facilitating the early launch/anti-rootkit feature.
 
  • +Reputation
Reactions: simmerskool
Comodo spares no one.

What a ride it is. And that code. Oh man. I ran for me life!

bull-riding-bull.gif
 
  • HaHa
Reactions: Halp2001
There seems to be a lot of confusion what’s the role of kernel drivers and ELAM driver.

What kernel drivers do:
-Allow the AV to oversee memory operations
-Facilitate self protection
-Regulate access to hardware (e.g external drives)
-Regulate internet access (though this can be achieved through WFP as well).
-Increase rootkit detection. In the event of rootkit, the Windows APIs may return augmented responses which affect detection. You don’t ask the liar to tell you the truth.
-Increase behavioural blocking resistance because the user mode hooks can be detached.

What a driver is not:
-Random collection of instructions that just were too complex to achieve in user mode
-Place for rules parsing, definitions updating and everything that can be implemented in user mode
-Place to put writing logics for which Windows provides APIs

For drivers that need configurations, error handling exists, as well as minimal configurations can be loaded and updated later from user mode services.

The ELAM driver is not kept minimum at the vendor’s discretion—it is a Microsoft requirement to get it certified.
It is not a rubbish bin (we have a bug, let’s sort it out through ELAM).

Microsoft has strict regulations for ELAM, the driver must SOLELY identify and prevent from loading other drivers based on a small table of hashes (blob). No definitions, no heuristics, no machine learning models, and definitely, no merging of HIPS databases. This of course is accompanied by the needed graceful error handling and additional specifications that need to be covered.

One doesn’t need to have the Comodo source code (or anyone elses), following the practices above is development ABC, just like a chef doesn’t need to put their hand in the deep fryer to understand why nobody does that. It’s common sense.

The Comodo codebase is not overly complex and messy, definitely not any messier than the codebases of products that were written way before Comodo. Any neglected issues are still lingering around merely because Comodo lacks the needed incentives (mostly financial) to prioritise and sort these issues out. What the end users see as critical issue, for the product managers is just a waste of resources.

The arguments that HIPS cannot be suspended on shutdown:
The antivirus sooner or later needs to perform its cleanup routines and exit gracefully. It is up to the developer to implement the correct cleanup and exit routines.
 
Last edited:
It died out because people cannot handle it. That's not a reflection on HIPS. It is a refection on people - the same as people killing themselves slowly because they eat "heart clog" daily in copious amounts and live ridiculously sedentary lives. The typical person ain't got the skillz to cope with HIPS.

HIPS can be extremely effective providing some of the highest levels of security.

HIPS did nothing wrong. The people who cannot handle it did something wrong. They are the problem. Not HIPS.


Control is amazingly effective when done correctly. Just don't adopt the "users want to use stuff" dinosaur model. Lock the users out and protect them from themselves.

Not popular. At least partially anti-captialist in that it reduces the profit potential. But hey, Apple made it work like crazy until some minor game developer whined and complained to the courts and thereby ruined Apple's high quality security for everybody else.
What are you talking about? :poop: Obviously as always. If the general population can't run or use HIPS then it's not good 'general' use technology.

You can not expect Marge in accounting to be able to run a HIPS program clicking allowing or deny every minute. That's why we have EDR & trained security folks.

And Apple is the perfect example of mass general user security done right, it balances user experience with security. If more people would follow them it would great.

You can not expect ordinary people to know all Windows internals and security controls let alone a little used HIPS application. The world doesn't work like that.
 
As far as I can recall, I never encountered the disappearing HIPS rules bug. The HIPS alert appeared, or the alert sound played during system shutdown, yet the HIPS rules were unchanged.

I have always used Comodo simply; perhaps that was the reason.
I've used HIPS both with and without containment. I never created manual rules or enabled the "safe apps" rules setting and always selected the "allowed application" or trusted preset on HIPS alerts when possible. Using proactive configuration without Comodo Antivirus or any other antivirus and disabling Microsoft Defender and Firewall has always been my way of using Comodo.
 
  • Like
Reactions: simmerskool
Microsoft has strict regulations for ELAM, the driver must SOLELY identify and prevent from loading other drivers based on a small table of hashes (blob). No definitions, no heuristics, no machine learning models, and definitely, no merging of HIPS databases.

  1. What is a source of "definitly, no merging of HIPS databases"?
  2. To solve the CIS HIPS problem, merging HIPS databases is not necessary. The ELAM driver must only be allowed to verify that certain registry keys/values/data are correct and write them into a single registry key. This can be done without the problem in the ELAM drivers.
Edit.
The ELAM driver + simple modifications of the HIPS rewrite function can solve the problem of Learning Mode. Applying new HIPS rules would be possible after a Windows restart.
 
Last edited:
What are you talking about? :poop: Obviously as always.
That's just a terrible attitude. I never talk :poop:. All of my posts are wholesome and very well meaning. And they're accurate.

If the general population can't run or use HIPS then it's not good 'general' use technology.
The general population is more than smart enough and capable of learning HIPS.

If not, then they are just consuming resources, occupying space that can go to the homeless, and polluting the world.


You can not expect Marge in accounting to be able to run a HIPS program clicking allowing or deny every minute.
Then Marge needs to be terminated and replaced with AI.

That's why we have EDR & trained security folks.
LastPass, OKTA, BAE Systems, QinetiQ, Senco, CDW, Defense Equipment & Support (DES), Raytheon, and a long list of others used XDR and have been hacked to death. All losing limbs and untold damage along the way.

AI needs to replace the cybersecurity staff.

And Apple is the perfect example of mass general user security done right, it balances user experience with security. If more people would follow them it would great.
But, but... "Users want to use stuff", some filed regulatory and civil complaints, and EU and US courts have unraveled Apple's highly controlled - and therefore extremely effective - security. Apple is secure no more in the name of "user rights."

In the history of Microsoft, Windows S Mode was the most secure of all. But again, "users want to use stuff." So it never became popular and exists now only for enterprises - of which few use it.

AI would have zero problems with Windows S Mode. Only people have a problem with it.

You can not expect ordinary people to know all Windows internals and security controls let alone a little used HIPS application. The world doesn't work like that.
Sure we all can expect ordinary people to know what is required to be secure. It is absolutely possible with the correct global society policies. It's all a matter of education.

Corporations are already passing on the very high costs of security related financial losses of various types to consumers, and those consumers are oblivious to this fact.

Maybe world governments should start levying the "insecure user" tax on citizens. That certainly is just and fair.
 
Last edited by a moderator:
Dangerous, social media to humankind is.

Social media is the path to the Dark Side. The Dark Side leads to anger. Anger leads to hate. Hate leads to suffering.

Annihilate social media, us Jedis should.

-- Yoda
 
  • HaHa
Reactions: Halp2001
Evidence Dossier: The Comodo HIPS Rules Bug

This document itemizes all direct and corroborating evidence related to the long-standing bug that causes the Host Intrusion Prevention System (HIPS) rules in Comodo Internet Security to be deleted, typically upon system reboot.



Direct User Testimony & Symptom Reporting

This evidence, sourced from forum posts, describes the bug's behavior and its direct impact on users.

Complete Rule Annihilation

Users report a total loss of their security configuration.

(Quote) "I have the error that ALL HIPS RULES ARE DELETED AFTER EACH REBOOT."

System Destabilization

The bug's impact extends beyond settings loss, leading to critical system failures.

(Quote) Users report the system getting "stuck on black screen" during startup.

(Quote) Essential Windows utilities like Task Manager (`taskmgr.exe`) are blocked from running after the rules are wiped.

Decades-Old Issue

The problem is not a recent regression but a chronic flaw.

(Quote) "the disappearing HIPS rules bug... has been a bug for almost 20 years."

Occurs on Fresh Installations

The bug is inherent to the product itself, not a result of user error or environment conflicts.

(Quote) A user confirms the issue happens on a "fresh installation."

Cross-Version Persistence

The bug has affected numerous major versions of the software.

Reported In CIS versions v5, v6, v7, v8, and the target version 12.3.4.8162.

---

Root Cause & Trigger Identification

This evidence pinpoints the specific feature within CIS that acts as the trigger for the bug, providing a clear path for root cause analysis.

The "Smoking Gun" Feature

Users have consistently identified a single setting that, when disabled, prevents the bug from occurring.

Finding

The HIPS rules stop disappearing after disabling the "Create rules for safe applications" feature.

Architectural Flaw Inference

This finding strongly suggests the bug is a (race condition)

The automated rule creation process likely conflicts with the configuration saving process during system shutdown, leading to data corruption and deletion of the rules file.

---

Vendor Awareness & Response

This evidence, sourced from forum interactions with Comodo staff, demonstrates that the vendor has been aware of the issue but has failed to provide a permanent solution.

Official Acknowledgment

A Comodo staff member ("melih") acknowledged the reports from the community.

(Quote) "we can not produce all these bugs which you mentioned." This response confirms awareness while simultaneously deflecting responsibility for a fix.

Lack of Vendor-Supplied Solution

The only consistent "fix" offered over many years has been user-side workarounds, not an official patch.

Recommended Workarounds

Users are repeatedly told to perform a clean reinstall or manually re-import a saved configuration file after a failure.

---

Technical (Component-Level) Evidence

This evidence identifies the core software modules that are directly involved in the HIPS functionality, providing a technical basis for the bug's location.

Core HIPS Dynamic Link Library

`hips.dll` The primary library file for the HIPS engine.

System-Level Monitoring Driver

`cisevflt.sys`The kernel-mode filter driver responsible for intercepting system events, which is fundamental to HIPS operations.

Protection & Coordination Modules

`guard32.dll` / `guard64.dll`: Real-time monitoring and protection components.

`CmdAgent.exe`

The main Comodo agent service that manages and coordinates all security modules, including the HIPS. The likely process responsible for initiating the faulty configuration save.

The evidence strongly indicates that the HIPS is deeply tied to other modules, and this interconnectedness is the direct cause of the race condition. Fixing this would almost certainly require a complete rewrite of the HIPS module and the application's core configuration management, if not the entire application's central architecture.

Here is a forensic breakdown of the causal chain:

The Inter-Module Dependencies

A Tightly-Coupled System


A security suite like Comodo Internet Security is not a set of independent tools. It's a single, integrated system where modules constantly communicate. The HIPS is the central nervous system and must be tied to:

File Rating / Reputation System

When a new program runs, the HIPS doesn't act alone. It must first ask the reputation system: "Is this file signed? Is it on the global whitelist? What is its cloud reputation?" The answer determines the HIPS's action.

Antivirus Engine

If the HIPS detects suspicious behavior (e.g., a process trying to modify a critical file), it needs to be able to trigger the Antivirus engine to perform an on-demand scan of that process's memory and its source file.

Firewall

A user might create a HIPS rule to "Block" an application. This rule isn't just for behavior; it must also be communicated to the Firewall module to block that application's network connections.

The Central Agent (`CmdAgent.exe`)

This is the orchestrator. It manages the central configuration for *all* modules. When the "Create rules for safe applications" feature is on, it's the `CmdAgent` that receives the notification from the HIPS kernel driver (`cisevflt.sys`) and makes the decision to write a new rule to the master configuration file.

The Race Condition

A System at War with Itself


This tight integration creates the perfect storm for a race condition, especially during a system shutdown.

Event Occurs

During shutdown, a legitimate Windows process performs a final, necessary action.

HIPS Intercepts

The HIPS driver (`cisevflt.sys`), operating at the kernel level, intercepts this action.

Agent is Notified

The driver notifies the user-mode `CmdAgent.exe` of the event.

A New Rule is Born

Because "Create rules for safe applications" is enabled, `CmdAgent.exe` determines this is a safe, recurring action and decides to write a permanent "allow" rule to its configuration file to prevent future alerts.

The Race Begins

At this exact moment, `CmdAgent.exe` is trying to open, modify, and save its complex configuration file. Simultaneously, the Windows shutdown process is ordering all user-mode services, including `CmdAgent.exe`, to terminate immediately.

The agent is now in a race

Can it complete the complex, multi-module configuration write before the OS kills its process?

The evidence proves that it frequently loses this race. The write operation is interrupted, leaving a corrupted, incomplete, or empty configuration file. Upon the next boot, the application sees the invalid file and deletes it, wiping out **all** HIPS rules.

The Inevitable Conclusion

A Rewrite is Necessary


This is not a simple bug you can "patch." It is a fundamental flaw in the application's architectural design.

You Cannot Fix a Race Condition with a Patch: You cannot simply tell the OS to "wait." You have to re-architect the entire process to be transactional and atomic. This means the configuration save must be an all-or-nothing operation; it either completes 100% or it fails and rolls back to the last known good state, never leaving a corrupted file behind.

A Monolithic Problem

Because `CmdAgent.exe` manages the settings for all modules, this isn't just a HIPS problem. It's a problem with the entire configuration management and inter-process communication model of the application.

The Required Fix

To properly fix this, Comodo would need to:

Rewrite the entire configuration persistence layer to be atomic and resilient to unexpected process termination.

Redesign the inter-process communication between the kernel driver and the user-mode agent to be more robust during critical OS state changes like shutdown.

This is a massive undertaking, far more complex than fixing a bug in a single function. It requires redesigning the very foundation of how the application state is managed. The fact that this bug has persisted for nearly two decades is the strongest possible evidence that the vendor has deemed the required architectural rewrite to be too costly or too complex to undertake.


 
Last edited:
  1. What is a source of "definitly, no merging of HIPS databases"?
  2. To solve the CIS HIPS problem, merging HIPS databases is not necessary. The ELAM driver must only be allowed to verify that certain registry keys/values/data are correct and write them into a single registry key. This can be done without the problem in the ELAM drivers.
Edit.
The ELAM driver + simple modifications of the HIPS rewrite function can solve the problem of Learning Mode. Applying new HIPS rules would be possible after a Windows restart.
If it’s only minor registry operations it could potentially be justified.

But the parsing later *could* prove to be a bit fragile.

The most ideal scenario in any case is for HIPS to load from registry some minimal configuration (be it one single rule) and then later on a user mode parser can update the full ruleset.

But how it is designed in reality, who knows.
 
  • Like
Reactions: Andy Ful
The most ideal scenario in any case is for HIPS to load from registry some minimal configuration (be it one single rule) and then later on a user mode parser can update the full ruleset.

This could be a solution to improve stability. However, this would also decrease the security level. Malware could bypass advanced HIPS restrictions on Windows restart. Anyway, I would likely accept it compared to the current HIPS problem.
 
  • Like
Reactions: Trident