I’m having the Avast “Sf.bin” problem as mentioned in another thread. It happens because the Avast service executable (AvastSvc.exe) runs a file Sf.bin, which changes often to enable coded emulation. This file rightfully causes Comodo to either raise a Defense+ alert or to Sandbox the file Sf.bin until it’s scanned and deemed safe, depending on your settings.
However, I know that Comodo has a brilliant thing called Defense+ Rules under Computer Security Policy.
I’ve added a custom rule for AvastSvc.exe under “run an executable”, allowing it to run the file [Avast program location]defs/*/Sf.bin
Brilliant! Thanks Comodo for such a powerful tool!
However, this rule is only used if the automatic sandbox feature is disabled (“Treat unrecognised files as” = unticked).
When the automatic sandbox feature is enabled, this custom Defence+ rule is ignored and I get the Sf.bin file in the sandbox/unrecognized file area until it is deemed safe by Comodo cloud. This causes hangs and locks in the system.
This asks the question - Automatic sandbox enabled means Defense+ rules are ignored/disabled?
Is the only way around this to add an exclusion to the sandbox itself? (Defence+ Settings->Execution Control Settings->Exclusions)
It seems you have three choices:
Use Defence+ exclusively (Paranoid mode)
Use Defence+ plus trusted files/whitelist - requires automatic sandbox to be disabled through unticking “Treat unrecognised files as”.
Use Automatic Sandbox, but Defense+ rules are ignored/disabled and files have either partial/limited/restricted/untrusted/blocked rights or ALL rights when added to the trusted/whitelist area.
The reason I ask is I use solution 2 and have no issues, but my family and friends use solution 3 (less confusing popups) but I’m having this issue with Sf.bin and a few other programs due to this limitation.
You can go around the sandbox when you give the sf.bin file the Installer/Updater policy in Defense + Rules (under computer security). I think giving AvastSvc.exe the Installer/Updater instead may also work.
When making a policy make sure that the rule for AvastSvc.exe of sf.bin is somewhere above the All Applications rule. Use drag and drop. When policies are somewhere underneath the All Applications rule they follow the rule set by the policy of All Applications (they are subordinate).
Thanks for the reply, but I’ve found the problem described in the opening post still stands. I have tried moving the rule to the top of the list, but nothing changed. Also tried setting full rights (Installer/Updater and Windows System Application) for various programs and files - again no difference.
Automatic Sandbox enabled = custom Defense+ Rules ignored, it still moves Sf.bin to untrusted, tries to check the cloud and hangs the whole system for a few minutes.
If I disable the automatic sandbox, it uses the Defense+ rules I’ve set and no problems. This is on a fresh install of XP SP3, ATI Catalyst 10.2, latest Comodo and finally the latest Avast added.
I think what’s happening is programs on the whitelist and trusted files list have rights that over-ride anything set in Defense+ when automatic sandbox is enabled. Disable auto-sandboxing, and Defense+ rules are used again for unrecognized files.
Regardless, it causes a locked system my end in certain circumstances with Avast and Catalyst 10.2 on a fresh install.
Once the file has been moved to trusted (by the cloud eventually or straight away manually) it is fine, as it seems to then have full rights like AvastSvc.exe and doesn’t trigger any restricted rights.
Only problem is when Avast decides to change the file again (Sf.bin), as it does all the time, then the process starts again. I think trusted and whitelisted files are CRC checked for changes? Defense+ files are not it appears.
Anyway, for now the solution is to switch to Avira and forget about Avast, so I can continue to use the superb automatic sandbox feature for Family and Friends. Tired of Sf.bin causing problems being restricted/blocked and building up in the trusted file database everytime it changes and is eventually verified in the cloud.
On my own machine, I’ve disabled auto-sandboxing and cloud verification and used defense+ to create a rule that works. It’s only in my dual boot XP SP3 anyway, kind of like a second opinion virus scanner, in Win7 I just use the full Comodo suite.
Just had an idea, this is from another post but it’s relevant to this issue too, so it’s a cut and paste.
I’ve found Whitelisted and Trusted files have absolute rights to do everything - defense+ rules set for these CRC checked files are ignored/over-ridden unless you go into paranoid mode. You can also disable cloud lookup so unknown files are forced to use defense+ rather than immediately get Trusted status from the cloud.
If you disable the automatic sandbox, you can use Defense+ rules for unknown files under the safe policy and below (rather than them being listed in Unreognized files) but Whitelisted and Trusted files still have absolute rights to the system and over-ride defense+ rules.
It would be better to be able to process Defense+ rules/policy for whitelisted and trusted files also!
If this causes problems the solution is simple - have a separate tab that contains a Defense+ policy for trusted/whitelisted files, so you can specify a rule that all files notify you when certain events occur (like protected startup keys). You end up with the current Defense+ policy tab for unknown files, and a Defense+ tab for whitelisted files which starts out blank.