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

At the shutdown, the disk can be busy depending on running applications. Furthermore, many people still do not use SSD.
There are many unknown factors.
So from milliseconds it could stretch to a second. This is still tolerable and within the limit.

This is not any different than any other AV that constantly saves work (scanned files in caches, firewall rules, file reputation cache, url reputation cache, behavioural cache and others).
None of them experience data loss and reset at shutdown.
 
  • +Reputation
Reactions: simmerskool
Knowing you i feel if you ever took a job at comodo you would scream at melih and walk out your first day. :ROFLMAO::ROFLMAO:
well if he paid you a lot and also did not care what you produced, ie, whether 'the bug' was fix'ed -- I've had worse jobs and put up with them longer than 1 day, not he would pay me :ROFLMAO:
 
Last edited:
It does matter though. If the user disabled "Create rules for safe applications" this is how it effects each Mode.

Paranoid mode (The bug is fixed, and the mode operates exactly as designed (manual control).

Safe Mode (The bug is fixed, but the mode's primary purpose (auto-allowing "safe" apps) is disabled, making it behave like Paranoid Mode.)

Training Mode (The bug is fixed, and the mode should still auto-allow all user activity as intended)
Go read Comodo CIS User Guide to learn how the different modes work then come back.
 
  • Like
Reactions: Trident
Go read Comodo CIS User Guide to learn how the different modes work then come back.
Paranoid mode

The documentation confirms this mode is fully manual and does not use the automatic rule creation, which is why the workaround has no negative effect on it.

"Comodo Internet Security does not attempt to learn the behavior of any applications - even those applications on the Comodo safe list... Similarly, the Comodo Internet Security does not automatically create 'Allow' rules for any executables...

Safe Mode

The User Guide explicitly states that Safe Mode's auto-allow functionality is contingent on the checkbox being enabled.

Defense+ automatically learns the activity of executables and applications certified as 'Safe' by Comodo. It also automatically creates 'Allow' rules for these activities, if the checkbox 'Create rules for safe applications' is selected.

This directly confirms that If a user disables that option (as the workaround for the bug), Safe Mode loses its primary function (auto-allowing "safe" apps) and will default to alerting for unknown applications, thereby behaving just like Paranoid Mode.

Training Mode

The documentation confirms this mode's goal is to allow everything, not just safe applications, so its logic is separate from the problematic option.

HIPS learns the behaviour of every application and automatically creates 'Allow' rules for them. This includes any files with 'unknown' trust rating.

This confirms Training Mode auto-allows all applications, so disabling the option to only create rules for safe applications would not interfere with its core function.

The User Guide itself validates the exact analysis you are trying to debunk.
 
None of them experience data loss and reset at shutdown.

Maybe none ot them uses a faulty method. :)

I have some doubts about registry time writes. The Pico's test is consistent with the Registry stored on the SSD (40s/140000 ~0.3 ms).
Here is an example of a similar test ( ~0.2 ms):

However, the Windows Registry keeps changes in a memory cache for performance. The system flushes this cache to disk periodically.
Writing into the memory cache is much faster than writing to the SSD, and may be comparable or faster than writing to the file.
 
It's been awhile for me, but with CWF i use to tweak File Rating one by one to my desired user personal configuration in addition to the other settings which for the most part was always with @cruelsister's Config which always worked out well. To my knowledge nothing (testing malwares) ever was able to bust out or otherwise distort this particular arrangement and the Modules appeared to perform as well as expected or i would have straightway dumped it a long time ago. I haven't had time to test CFW lately but i do certainly hope all the attention this free product is garnered lately encourages them to at least patch up any bugs recently brought up in these sometimes intense discussions,
 
Maybe none ot them uses a faulty method. :)

I have some doubts about registry time writes. The Pico's test is consistent with the Registry stored on the SSD (40s/140000 ~0.3 ms).
Here is an example of a similar test ( ~0.2 ms):

However, the Windows Registry keeps changes in a memory cache for performance. The system flushes this cache to disk periodically.
Writing into the memory cache is much faster than writing to the SSD, and may be comparable or faster than writing to the file.
I would love to rip the exact rules (which can be done with one loop) and see how fast they will write to registry via the “comodo chosen apis” which we know, registry transaction, through powershell cmdlets and finally as json. I can replicate the data Comodo collects before that (like process path, signers information, hashes and other properties that may be relevant to HIPS)…

Only this way we’ll find out what’s most efficient.

May put Comodo back.

I also wanna see how long it can take me to write one single rule.

We can also see 10 rules with random delays between them. From discovering the file to writing the rule.
 
Last edited:
The trace was set on Windows Registry APIs such as RegEnumKey RegOpenKey RegSetValue and so on, not on disk I/O.

I think that this test does not reflect the Comodo way of applying HIPS settings.
Anyway, if you are right, then the way of applying the HIPS setting (40s) by Comodo would be unacceptable.
Comodo should show an alert if adding a new rule would last more than a few seconds.
Let's wait for other tests.
 
  • +Reputation
Reactions: simmerskool
I think that this test does not reflect the Comodo way of applying HIPS settings.
Anyway, if you are right, then the way of applying the HIPS setting (40s) by Comodo would be unacceptable.
Comodo should show an alert if adding a new rule would last more than a few seconds.
Let's wait for other tests.
If you open the HIPS rules window to create a new rule to the rules list the first thing CIS does is populating the rules list by reading all the rules from memory which is pretty quick. Next, if you create a new rule to that rules list then the new rule is written to memory and listed in the rules list however the HIPS rules window is still open and you have to confirm your changes by pressing the "OK" button on that same window to close it. Once you press the "OK" button the HIPS rules window stays for approx. 40s on the screen before it is closed and it is during this time that the massive registry events happen.
 
If you open the HIPS rules window to create a new rule to the rules list the first thing CIS does is populating the rules list by reading all the rules from memory which is pretty quick. Next, if you create a new rule to that rules list then the new rule is written to memory and listed in the rules list however the HIPS rules window is still open and you have to confirm your changes by pressing the "OK" button on that same window to close it. Once you press the "OK" button the HIPS rules window stays for approx. 40s on the screen before it is closed and it is during this time that the massive registry events happen.
So the ok button calls an orchestrator and the orchestrator calls the writer. In the UI then can find the orchestrator (they use Sciter) and from there they can find the writer.

It’s literally a minute of work, deep code knowledge is not required.
 
  • +Reputation
Reactions: simmerskool
Only this way we’ll find out what’s most efficient.

The best way would be to use a memory cache (not registry cache) for HIPS rules and write the changes periodically to a file on disk.
The cache is required to speed up reading the HIPS settings.
The cache for the Registry (1) is probably much bigger than the cache needed only for HIPS settings (2), so the writes to (2) can be significantly faster.
 
The best way would be to use a memory cache (not registry cache) for HIPS rules and write the changes periodically to a file on disk.
The cache is required to speed up reading the HIPS settings.
The cache for the Registry (1) is probably much bigger than the cache needed only for HIPS settings (2), so the writes to (2) can be significantly faster.
I thought about this too. But not sure how reliable it is on shutdown. I only have experience with files on shutdown tbh. In any case most performant method is to modify in memory and periodically dump.
 
It does matter though. If the user disabled "Create rules for safe applications" this is how it effects each Mode.

Paranoid mode (The bug is fixed, and the mode operates exactly as designed (manual control).

Safe Mode (The bug is fixed, but the mode's primary purpose (auto-allowing "safe" apps) is disabled, making it behave like Paranoid Mode.)

Training Mode (The bug is fixed, and the mode should still auto-allow all user activity as intended)
When using Safe Mode, the option to create rules for security applications is disabled by default. This option does not affect the functionality of Safe Mode.
 
When using Safe Mode, the option to create rules for security applications is disabled by default. This option does not affect the functionality of Safe Mode.
The option is "disabled by default" (you are correct).

Because it is disabled by default, Safe Mode, in its default state, does not automatically create rules. It only learns the behavior of safe apps and will still prompt the user for unknown applications.

The option absolutely affects the functionality. When a user enables it (changing it from the default), it "turns on" the very feature (auto-creating "Allow" rules) that is reported to trigger the bug.

Therefore, your conclusion is false. The option is the master switch for the "auto-allow" behavior, and that is precisely why disabling it (as in the workaround) reverts Safe Mode to a manual, "Paranoid-like" state.
 
The option is "disabled by default" (you are correct).

Because it is disabled by default, Safe Mode, in its default state, does not automatically create rules. It only learns the behavior of safe apps and will still prompt the user for unknown applications.

The option absolutely affects the functionality. When a user enables it (changing it from the default), it "turns on" the very feature (auto-creating "Allow" rules) that is reported to trigger the bug.

Therefore, your conclusion is false. The option is the master switch for the "auto-allow" behavior, and that is precisely why disabling it (as in the workaround) reverts Safe Mode to a manual, "Paranoid-like" state.
Safe Mode operates on the principle of allowing trusted programs to run, while only prompting for confirmation when unknown programs attempt actions. This differs from Paranoid Mode, which prompts for all actions.

Enabling or disabling this option merely toggles the automatic creation of rules for trusted programs,This option is not the master switch for the “auto-allow” behavior.

In other words, whether this option is enabled or disabled, all secure program activities will still be permitted when using Safe Mode, though a pop-up will appear for unknown programs.
 
Last edited:
  • Applause
Reactions: Divergent
Safe Mode operates on the principle of allowing trusted programs to run, while only prompting for confirmation when unknown programs attempt actions. This differs from Paranoid Mode, which prompts for all actions.

Enabling or disabling this option merely toggles the automatic creation of rules for trusted programs,This option is not the master switch for the “auto-allow” behavior.

In other words, whether this option is enabled or disabled, all secure program activities will still be permitted when using Safe Mode, though a pop-up will appear for unknown programs.
Maybe you know or you don't know but you're replying to an answer which is generated by AI.
You are feeding / learning / teaching AI how things actually work instead of AI is correctly teaching / informing us.
 
Safe Mode operates on the principle of allowing trusted programs to run, while only prompting for confirmation when unknown programs attempt actions. This differs from Paranoid Mode, which prompts for all actions.

Enabling or disabling this option merely toggles the automatic creation of rules for trusted programs,This option is not the master switch for the “auto-allow” behavior.

In other words, whether this option is enabled or disabled, all secure program activities will still be permitted when using Safe Mode, though a pop-up will appear for unknown programs.

It's about time someone who understands how this application works commented. The speculation from people who haven't bothered to learn it has been frustrating.

The "master switch" for the auto-allow behavior is the HIPS Mode being set to "Safe Mode." The checkbox is merely a housekeeping option for whether to log those allowances as permanent rules.

Maybe you know or you don't know but you're replying to an answer which is generated by AI.
You are feeding / learning / teaching AI how things actually work instead of AI is correctly teaching / informing us.

Let's clear this up. I'm not an AI, your conclusion is incorrect.

I posted that as a test. If you review the thread, you'll see my original attempts to explain were deflected and called wrong. Curiously, those exact same points were later adopted by the same users who dismissed them.

Since my contributions were then being ignored, this was necessary to prove a point. Most of you have no idea how this application actually works.

I'm quite tired of this one sided attempt to make other look bad as well.

The forum owner and Admin uses AI to format his posts.


@Trident uses AI to build post not only deep search but you can see it in many other posts as he does not get all the artifacts cleaned out or build hybrid posts and does not state he's using AI.

Post in thread 'Decoding the Trend Micro Components and Protection Model' Serious Discussion - Decoding the Trend Micro Components and Protection Model


Here's an example of another member that states using AI in threads about others while they do it themselves.


Frankly I'm tired of hearing how when I use AI to rewrite my posts that I'm AI, not to listen to me. I have been around this forum longer than most of you on and off. I was once a moderator here. Do you actually think I do not know most of these topics inside out by now. I was the malware hub moderator at that. I tested these applications. So all of you egos can kiss my backside. You do not have access to the source code, this is all speculation. I built my post around knowing how the product worked and the evidence from the actual Comodo forum users and moderators. All this talk about how that is not evidence is just deflection from those stating speculation. You yourself are just admitting some evidence that proves what I stated before if you look back through the thread. I have nothing further to state here but I certainly hope some eyes were opened before the usual crowd of bullies come to the rescue of these that iniated this to begin with.
 
Last edited:
Installed Comodo Firewall (using the newest CIS Premium installer) in VirtualBox VM with Windows 11 25H2. After the restart, I added 10 HIPS rules and applied the settings. The HIPS window was closed after one second.

I decided to apply Comodo Internet Security configuration and Paranoid HIPS with enabled "Create rules for safe applications".

1760891692900.png


After running many applications and clicking on over a hundred alerts, the system worked without issues.
However, after restarting Windows and signing in. I saw only a black screen.
I thought, do not give up, and used CTRL+ALT+DEL to see what could happen. It worked.
I could run Task Manager and execute explorer.exe from it. Finally, I could see the Desktop and Comodo alert.
I did a few clicks to accept the Comodo alerts. Previously alerted applications could be executed with no alerts (HIPS not corrupted).

I decided to restart Windows and tried to sign in. I saw the black screen again. So, I did the same trick to run explorer.exe, which worked.
Adding Explorer to the Allowed Application group did not help. Although CIS saved the new rule, it was overwritten to "Custom ruleset" after running Explorer. After restarting Windows, the black screen again.

I did the trick with TaskManager to see the Desktop and disabled the setting "Create rules for safe applications" and enabled Training Mode.
After a successful restart, I enabled Paranoid Mode again. This finally worked, Windows restart and sign-in were successful.

In the end, I enabled the setting "Create rules for safe applications" and restarted Windows. No problems.
CF works with Internet Security config + Paranoid HIPS + enabled "Create rules for safe applications".
I did not encounter any HIPS corruption in my whole test (so far). We will see if this happy scenario will continue.

Conclusion (so far).
The best order of action for using Paranoid Mode:
Training Mode for a few days ----> Paranoid Mode for a few days -----> enabling "Create rules for safe applications"
 
Last edited:
The "Create rules for safe applications" rule is useful for experienced users, but most don't need it. If I remember well, many rules can affect Comodo's performance: navigating, working with modules, etc. The many HIPS rules were also one factor in the "disappearing HIPS rules" bug. These were also reasons Comodo later disabled the discussed rule.