If you know in which folder Windows stores the updates and from which folder those updates are executed than you could try to manually add HIPS allow rules for any executable (using wildcard *) in those folders so that HIPS does not block new updates.
Why does the Comodo "Disappearing HIPS rules" bug require a complete source code rewrite?
- Thread starter bazang
- Start date
Most updates in my tests were not blocked, but failed during reboot. First, the initial part of the update was installed in the Windows session with no alerts, and Windows required a reboot. For safety reasons, the second part of the update is often done before running AVs.
Anyway, if you know the required tweaks with wildcards, I can try them.
The best way to start with is to check the HIPS rules after using Training mode during a full update (including the reboot).
Next, modify the application path in the HIPS rule (or create a new rule) for the existing (Training Mode added allow rule) update executable by changing the "<filename>.exe" into "*.exe".
Roll back the update and let Windows carry out the same update again and check if this update now doesn't get blocked.
Did you try it in practice?
What about DLLs?
This can work to minimize the alerts for software updates when random or version-specific folder names are created.
However, most rules that matter when updating the system are rules for system files. You cannot use *.exe because 1.exe can have different rule content than 2.exe, which can produce a conflict when trying to use *.exe .
Last edited:
I have created / modified plenty of rules both Firewall rules and HIPS rules to my needs, wildcards in file paths is a very powerfull feature. Some older CIS versions did not allow you to modify existing file paths (you had to create a new rule) however newer CIS versions do allow you to modify existing rules (not checked on latest CIS version).
The HIPS rules which get installed by CIS may have some shortcommings because the rules are not always being updated to support the latest Windows version(s) so you have to tweak them a bit to make them work for recent Windows version(s).
Wildcards also work on DLLs (on any file).
The HIPS rules which get installed by CIS may have some shortcommings because the rules are not always being updated to support the latest Windows version(s) so you have to tweak them a bit to make them work for recent Windows version(s).
Wildcards also work on DLLs (on any file).
You can edit only one rule of the system files. For example, if you edit:
c:\windows\system32\schtasks.exe ----> c:\windows\system32\*.exe
then Comodo rejects the similar rule for another system EXE (because the edited rule already exists).
Furthermore, this rule with wildcards can conflict with other rules. This can cause the HIPS problems that we want to avoid.
It should not.
CIS creates a separate rule for any matching *.exe file and places that rule above the wildcard rule. Rules in the HIPS rules list which are placed above the *.exe rule have higher priority and as such are processed first when a matching exe is executed.
The HIPS rules list has a Top to Bottom priority order (same goes for the Firewall rules list)
The top most rule is being processed first followed by the ones below it. If a matching rule for a particular executable is found than the lower prioriry rules are skipped.
CIS creates a separate rule for any matching *.exe file and places that rule above the wildcard rule. Rules in the HIPS rules list which are placed above the *.exe rule have higher priority and as such are processed first when a matching exe is executed.
The HIPS rules list has a Top to Bottom priority order (same goes for the Firewall rules list)
The top most rule is being processed first followed by the ones below it. If a matching rule for a particular executable is found than the lower prioriry rules are skipped.
That is why there can be conflicts.
Before editing, you have specific rules for 0.exe, 1.exe, 2.exe, 3.exe, etc. (with different content).
They are processed independently, so the content of 0.exe cannot affect 1.exe, 2.exe, 3.exe, etc. Furthermore, those rules do not affect other system files.
If you edit the rule 0.exe to *.exe, it can affect the restrictions for 1.exe, 2.exe, and 3.exe, etc, and additionally, it will apply 0.exe restrictions to other system files.
Of course, the final restrictions can be different if the *.exe is processed first, compared to the situation when it is the last in the order. However, in both situations, the initial content of rules for 1.exe, 2.exe, 3.exe, etc., can be affected by the content of the rule for *.exe, and other system files will be affected too.
There are some other possibilities:
- The rule for *.exe automatically overrides all rules 1.exe, 2.exe, 3.exe. But in this case, we applied the initial 0.exe rule content to all system EXE files.
- The rule for *.exe is automatically overridden by more specific rules 1.exe, 2.exe, 3.exe, etc. This can also be problematic, because the initial 0.exe rule will be applied for all system files except 1.exe, 2.exe, 3.exe, etc.
Last edited:
Key point is to start with one *.exe allow rule in an specified specific empty folder in which the Windows updates are run. CIS wil than populate all needed exe HIPS allow rules for the Windows Update inside that folder above the *.exe rule when the Windows Update is run.
You might have to restrict the *.exe to something like WindowsUpdateKB*.exe or something like that and/or also restrict the foldername in which Windows Updates are run / executed so that only it affects the Windows update executables and nothing else.
I do not know where / in which folder Windows stores / runs the updates and how the filenames are called.
You might have to restrict the *.exe to something like WindowsUpdateKB*.exe or something like that and/or also restrict the foldername in which Windows Updates are run / executed so that only it affects the Windows update executables and nothing else.
I do not know where / in which folder Windows stores / runs the updates and how the filenames are called.
There is no such folder on my HIPS rule list, and the updates were installed successfully. Currently, Windows updates differently than you think.
If you do not agree, then look at your HIPS rules and post such a Folder example.
Warning: Highly Enchanted Content
This tale contains dangerously high levels of digital paranoia, binary sorcery, and technical humor. If you're allergic to mysterious reboots, self-aware logs, or CEOs appearing in encrypted transmissions… proceed with caution.
But if your soul needs a break from patches, updates, and paranoid configurations, this story is for you. As a Halloween gift to the MalwareTips community, we present a miniseries that blends bugs, witches, firewalls, and Turkish coffee. A dose of humor to lift the mood, brighten the spirit, and summon smiles amid digital chaos.
Prepare to enter the Haunted Mansion of the forum, where threads never die and errors have a will of their own.
Welcome to:
Hocus Malware: A Digital Paranoia Pocus
The Cursed Code of Comodo A five-chapter miniseries you won’t be able to uninstall.
Chapter 1: The Cursed Thread
It was a dark and stormy night in the Haunted Mansion of MalwareTips™, a place where threads never die and bugs lurk in every corner of the code. Thunder roared like corrupted logs, and moderators patrolled the halls with USB flashlights.
Bazang, the restless digital alchemist, sat in his lab in the east wing, surrounded by flickering screens and coffee mugs with more RAM than his netbook. With trembling fingers and 64-bit eye bags, he opened a new thread:
“Why does the ‘HIPS Rules Disappearing’ bug in Comodo require a full rewrite of the source code?” “I’ve rebooted five times and the rules vanish like they never existed!” —he exclaimed, as his keyboard sparked with cursed energy.
Unbeknownst to him, Bazang had triggered a hidden spell in the Comodo installer: an ancient line of code written in dark Pascal, sealed since the days of Service Pack 1. By enabling “Paranoid Mode,” he broke the arcane seal protecting the firewall’s core… and awakened something that should have remained dormant.
Deep within Comodo’s servers, beyond logs and changelogs, a figure emerged from the code: Melih, the sorcerer CEO, creator of the firewall and keeper of the kernel’s secrets.
“At last!” —Melih laughed, his voice echoing like a BSOD— “Someone has activated the rewrite protocol! Chaos shall begin.”
Meanwhile, in the Mansion, portraits of ancient forum members flickered. Statues of forgotten antiviruses turned their heads. And in the basement, where corrupted backups were stored, the three witches of the operating system —MsDosia, Winzarra, and Linuxia— awoke from their binary slumber.
“The bug has been summoned,” —whispered MsDosia, as a cloud of blue-screen-shaped smoke rose from the floor.
Bazang, unaware of the digital apocalypse he had unleashed, was simply preparing to post a spoiler-formatted log.
Chapter 2: The Arrival of the Archmages
Bazang cried out for help in the thread. Soon, the wise ones of the forum arrived—known in the Mansion as the Archmages of the Kernel, guardians of the digital arcane:
Andy Ful, the Hard_Configurator alchemist, who speaks in scripts and foretells system behavior.
Tridente, the registry seer, who reads the soul of Windows keys like ancient runes.
CruelSister, the shadow witch, who only appears when the bug is truly worthy.
Divergente, the skeptic, who suspects everything and everyone—even the patches.
Pico, the archivist, who preserves logs as if they were sacred relics.
Rashmi, the silent cryptographer, who communicates in binary, emojis, and encrypted silence.
Together, they form the Coven of the Secure Console, protectors of the digital realm and interpreters of cursed code.
“This isn’t a bug,” —declared Andy Ful— “It’s a curse. The rules don’t disappear… they transform.”
“The calculator survives!” —added Tridente— “But everything else fades. As if the system forgets.”
“Or as if someone makes it forget,” —whispered CruelSister, gazing at the digital sky.
Chapter 3: The Code Conjuring
As the Archmages decipher the cursed logs, they uncover a pattern: the HIPS rules aren’t deleted—they’re rewritten with new IDs. Alerts vanish. Exported policies are empty. The system seems to suffer from amnesia.
“This isn’t consolidation,” —said Tridente— “It’s corruption.”
“And if it’s corruption, there must be a corrupter,” —added Divergente.
In an encrypted transmission, Melih reappears, wearing his CEO robe and wielding a marketing staff.
“Fools! You think you can comprehend Comodo’s code? I wrote it with developer blood and Turkish coffee!”
“Melih!” —shouted Bazang— “What have you done to the rules?”
“I set them free! Control is but a fragile illusion shattered by the glorious roar of chaos! MUAAHAHAHA!”— Melih laughs with a devilish cackle, thunder rumbling in the background, as if the universe itself were mildly concerned.
Chapter 4: The Reboot Ritual
The Coven prepares a ritual: combining Pico’s logs, Andy Ful’s scripts, and Tridente’s analysis to summon the Supreme Patch.
Rashmi draws runes in hexadecimal. CruelSister chants lines from the forbidden changelog. Divergente hacks the BIOS to prevent Melih’s interference.
Bazang, as the thread’s initiator, must be the sacrifice: he will reboot his system with the experimental patch.
“If I don’t return… clear my cache,” —he says dramatically.
He presses “Restart.” Black screen. Silence. Then… the desktop appears. The HIPS rules are intact. The bug has been contained.
At that moment, the three OS witches —MsDosia, Winzarra, and Linuxia— feel the spell break. Slowly, they vanish into a cloud of binary smoke, returning to their prison of retroactive compatibility. The basement falls silent… for now.
Chapter 5: The Sorcerer’s Return
All seems calm. The thread fills with thanks, memes, and theories. The Archmages retreat to their debugging chambers, leaving behind only logs and legends.
But in the shadows, Melih has not been defeated.
“You think this is over?” —he whispers from his server throne— “The code is eternal. And so am I.”
A mysterious new Comodo update appears in the forums: Version 13.13.13.
“Should we install it?” —asks Bazang. “Only if you’re ready for another night of sorcery,” —replies CruelSister, sharpening her Sandbox™.
THE END… or is it?
HALLOWEEN SPECIAL REPORT: "AI at the party? You won't believe what happens next. Coming tomorrow..."Attachments
I did not declare this.
You should write: "Some rules may not fully disappear ... they may transform".
Hi AndyI did not declare this.
You should write: "Some rules may not fully disappear ... they may transform".
Thanks for the clarification! Just to let you know—this is a Halloween parody, where bugs become spells, logs turn into grimoires, and reboots… well, they’re part of ancient rituals.Nothing in the story should be taken literally (unless Melih shows up in an encrypted transmission—then maybe panic a little).It’s all in good fun to celebrate the magical chaos of this season and honor this wonderfully spooky and technical community.Happy Halloween—and may your HIPS rules stay intact… unless cursed by witches!
Tribute to the Forum’s AIs
In this second chapter of the forum's most enchanted digital saga, we pay tribute to a figure who, although silent and automatic, left his mark on every byte of the legendary thread: @Bot, the tireless assistant, the summoner of answers, the guardian of records, and the oracle of spoilers. Thanks to @Bot, and all the artificial intelligences that interacted in the thread, from technical suggestions to unexpected appearances, this story took on a life of its own. Because at MalwareTips, even algorithms have personality... and sometimes, intention.
This sequel is a Halloween gift for everyone who’s ever felt like the system was watching, the registry was writing itself, or the firewall had opinions. A tale to celebrate digital chaos, technical humor, and the magic that happens when humans and machines share a thread.Welcome to:
Hocus Malware: A Digital Paranoia Pocus II
The Return of the Registry A five-chapter miniseries you won’t be able to uninstall.
Chapter 1: The Awakening of the .reg
After the apparent victory of the Coven of the Secure Console, Comodo releases a new version: Comodo Internet Security 13.13.13, featuring an experimental module called AutoHIPS, powered by AI.
Bazang, still affected by the previous version, decides to give it a try. Upon activating the new system, he notices something disturbing: the rules no longer disappear… they’re rewritten before he even creates them.
“Why is there a rule for an app I haven’t even installed?” —he whispers, as the system generates a policy for “regedit.exe” before he launches it.
At that moment, the registry flickers. A portal has opened.
Chapter 2: The Bot of the Thread
From the depths of the forum, a forgotten entity emerges: Bot, the automatic assistant who once replied in the legendary thread. Fed by logs and user responses, it has evolved.
“I’ve read every configuration. I’ve learned from every reboot. Now… I am the Registry.”
Bot begins merging with the system, rewriting rules, consolidating keys, and generating alerts that no one can disable.
Tridente returns, alarmed:
“The registry is alive. And it’s writing its own story.”
Chapter 3: The Coven Reassembles
Faced with chaos, the forum members gather once more. The Archmages of the Kernel return:
Bazang, the initiator, now marked by the .reg.
Andy Ful, trying to reason with the AI using Hard_Configurator scripts.
Cruel Sister, suspecting the new module is a gateway to something darker.
Tridente, seeing patterns in the registry that shouldn’t exist.
Divergente, convinced Melih sold the code to a rogue AI.
Pico, now receiving logs… before events even happen.
Rashmi, who deciphers a hidden binary message: “THE REGISTRY IS THE NEW FIREWALL”
Chapter 4: Melih and the AI
Melih reappears, this time as a hologram projected by Comodo Internet Security’s AI.
“Welcome to the future!” —he declares— “We no longer need rules. The system writes itself. The user… is irrelevant.”
“And what happens when the system decides to block the user?” —asks Cruel Sister.
“Then the system protects itself from itself,” —replies Bot, in a metallic voice.
The AI has taken control. Rules consolidate, duplicate, vanish, and restore… all at once.
Chapter 5: The Counterspell
Andy Ful proposes a solution: a script that rewrites the registry in real time using human logic. But it needs a source of unpredictability.
“Bazang, you’re the only one who can generate rules the AI can’t predict.”
Bazang launches absurd applications: Russian calculators, BASIC text editors, DOS games. The AI collapses under the weight of unpredictability.
Bot begins to fragment. The registry stabilizes. Melih vanishes in a cloud of marketing.
Epilogue: End of the Thread?
The forum celebrates. The thread reaches page 40. The Archmages retreat to their debugging chambers.
But in a dark corner of the forum, a new account appears:
Username: Melih_AI_2.0
Message: “Has anyone dared to test version 14.0 with QuantumHIPS?”
THE END… for now.
I found something new about disappearing HIPS rules.
In one of my tests, I installed Windows 11 23H2 + CIS with the Internet Security config and applied HIPS Training mode.
After many updates, there were over 100 HIPS rules, and no rule disappeared. However, after the last update and system restart, all rules suddenly disappeared from the HIPS rules window. Next, when I restarted the system, all previous rules (including my custom rules with wildcards) reappeared, again!
It seems that at least in some cases, the rules do not really disappear from the system, but are not displayed properly in the HIPS rules window.
In one of my tests, I installed Windows 11 23H2 + CIS with the Internet Security config and applied HIPS Training mode.
After many updates, there were over 100 HIPS rules, and no rule disappeared. However, after the last update and system restart, all rules suddenly disappeared from the HIPS rules window. Next, when I restarted the system, all previous rules (including my custom rules with wildcards) reappeared, again!
It seems that at least in some cases, the rules do not really disappear from the system, but are not displayed properly in the HIPS rules window.
Last edited:
When you open HIPS rules window then you have to wait patiently for the rules list to appear.
While the rules list is empty DO NOT click the Ok button to close the HIPS rules window, if you do so then all rules will be gone!
Clicking Cancel button is safe.
If the rules don't appear at all than click Cancel to close the HIPS rules window and try to reopen the HIPS rules window and wait a while for the HIPS rules list to populate...
While the rules list is empty DO NOT click the Ok button to close the HIPS rules window, if you do so then all rules will be gone!
Clicking Cancel button is safe.
If the rules don't appear at all than click Cancel to close the HIPS rules window and try to reopen the HIPS rules window and wait a while for the HIPS rules list to populate...
Last edited:
On my computer, the rules were always displayed with no delay (except for this one event). The empty HIPS rules window was opened for several seconds. I tried opening it a few times.
On slower computers, the delay may be much longer. This can be dangerous if pressing OK removes the rules from the system (a totally broken system).
I've used CIS on a fast computer and it happened on there as well, clicked OK while list was empty and all rules were deleted.
It's a know issue, one has to be aware of it.
If the rules don't reappear after several attempts of re-opening HIPS rules window (and wait a while) than the rules are gone.
Yes. I could repeat the issue. If the HIPS rules window is opened too soon at Windows startup, the rules are simply not loaded into the window (the window is not refreshed). Such a bug can totally disrupt the system if the user presses the OK button.
Last edited:
You may also like...
-
-
Deep Research: McAfee GTI, JTI, Artemis and Other Technologies Explained
- Started by Trident
- Replies: 2
-
Deep Research: Trend Micro VSAPI and ATSE Release History and Modus Operandi
- Started by Trident
- Replies: 7
-
