Same Defense+ Alert every time I update an app

Ever since installing a new (clean) Win 7x64 system SSD, every time I update an XYplorer beta I get the same warning: “XYplorer_11.00_Install.exe could not be recognized and it is about to modify the contents of C:\Program files (x86)\XYplorer\XYcopy.exe.” I’m not sure what to do to create an exception or otherwise stop it, since I have no idea where the Install file is. The second is recognized as a legit file and has been added as an exception, as has xyplorer.exe itself, but that hasn’t stopped the alerts. This didn’t happen with XP or Win 7 before the clean install? Any suggestions? Thanks,

[attachment deleted by admin]

Is there anyone who can tell me why Comodo Firewall is not learning this install, whether I “Allow this request” or treat it as an installer? It never happened before I reinstalled Win 7. Thanks,

[attachment deleted by admin]

A new unrecognized installer is always going to generate an alert because it is a new application. You can use the Installer or Updater method to force D+ to ignore the fact that an application executable has been updated because there was already a rule in place regarding this application. This is not the case with a new installer file.

The only way to exclude a new installer from protection would be to set up a folder as a file group, and give that file group the Installer or Updater policy, then place the new installer there. Then D+ shouldn’t care what happens in that folder. It will automatically give every file in there the same policy. As the Installer and Updater policy is very powerful, this is pretty risky security-wise, and I wouldn’t recommend it.

As to why you haven’t noticed this before, were you running beta releases previously? I’m just assuming the beta releases aren’t digitally signed, while the public releases might have been.

Except for a day or two interlude when a release version comes out, I’ve been running beta releases for two years and with Win 7 since last Sept (the Xyplorer developer is very active!). Never saw this issue before the Win 7 reinstall in mid April. The install.exe file Comodo references doesn’t seem to exist anywhere that I can find, so I haven’t been able to exclude it.

Clicking on the file name above the security considerations portion of the alert window will give you more details about the file, including its path.

Edit: Fixed typo…

Thanks. Install.exe sets up in a different named Temp folder each time under C:\Users.…AppData\Local\Temp. Using Trusted Files in Defense+Alert, I can add the location using “Temp*”, but that would presumably pick up other installs too, wouldn’t it? Any other way to handle this?

No, you definitely wouldn’t want all of your temp files trusted.

You could try a wildcard in the file name. XYplorer_*_Install.exe.

If you add that to the trusted files list after enabling the option to Use file names instead of file hashes, you would be fine if the name of the .tmp folder didn’t change. If there is a discernible pattern to the .tmp file naming, you could wildcard that as well.

Something like C:\Users.…appdata\Local\Temp\temp*\XYplorer_*_Install.exe.

If that doesn’t work, about the only thing you could do is put D+ into training mode before updating. At least that way you wouldn’t get an alert. You would need to do this every time you update though, because as I already mentioned, the installer is a new file.

It seems that you trust the installers of XYplorer so I would advice to simply give the installer the Installer/Updater policy each time you install a new update but don’t tell CIS to remember your answer.

I’m missing the point of your suggestion, since remember is the (or my) default and it doesn’t matter with the Xyplorer install whether it’s checked or not.

Where is the “Use file names instead of…” option?

The name of the temp file always starts with “$$_”. If I could just show that plus the file name, it would work. What I’m not seeing is a way to edit a Trusted Files entry under Defense + Alert. Is there?

No, you can’t enter this information through the alert. You’ll need to add it to the list manually.

Go to Defense+ → Trusted Files, click the Add button and select Browse Files…. From here, you can select items to add to the list. Check the option Use file names instead of file hashes, and select anything and move it to the list. It doesn’t matter what you add because we’re going to change it.

Right-click on the entry you’ve just added and select Edit. Now you can manually enter a file path using the wildcard suggestions I made previously. When you are finished, click Apply and see if it works.

It may take a bit of experimentation to get the wildcards correct, but for securities sake, don’t make the wildcards too generic. In my suggestions, I only wildcarded the .exe’s version number, and anything that may possibly change in the temp folder path. Keep as much of the static file path as possible to alleviate any false positives. The idea is to get as specific as possible, yet broad enough to allow something like version numbers to be able to change.

I’ve never done any testing using wildcards in conjunction with the ‘Use file names’ feature, so I don’t know how successful this will be in solving your problem, but it’s definitely something to try.

Not being familiar with this installer, I don’t know if merely trusting the installer will give you an alert-less installation the way the Installer or Updater policy does. (Will the installer spawn child processes which will trigger an alert)

If the method mentioned above doesn’t work, (you get alerts during install) you may need to go the File Group, route.

You can create a new file group by going to Defense+ → Computer Security Policy → Protected Files and Folders. Click the Groups button, then Add → A New Group. Type the group name and Apply.

Now scroll down to your new group, and right-click on where it says (add files here) and select Add. Do the method I mention above to manually add the file path with wildcards. Click Apply and OK until you’re back to the main Computer Security Policy window.

Go to the Defense+ Rules tab, and click Add. Then Select → File Groups, and choose your newly created file group. Then give this group the Installer or Updater policy, and approve the message that tells you the security implications of doing this.

HeefeD - Finally got around to trying your methods and ended up using the second - and it worked! Thanks,

Glad to hear it. :slight_smile: