avast! Home Edition refuses to let me delete exclusions

[alanrf]

I believe that my participation in this forum speaks more for my willingness to test many conditions with avast (and thereby to risk my system) and to report the results with veracity than anything this individual can question with any degree of belief.

Rather than indulge in any further barbs with this person and to try to retain this forum as a place of friendly debate I will leave the field open to the original poster - come what may.

[alanrf]

Further to the last post of solcroft I will provide to the avast team - should they request it - every scrap of my system details, settings, logs etc and every piece of testing I have done in connection with this thread. 

   

[Vlk]

I'm afraid I have to agree with solcroft on this one. The way start seems to behave is that:

1. normally, it uses the program associated with the file extension (and if there's none associated, it asks the user what program should it open it in)
2. however, if the file is a valid DOS/Win16/Win32 application (i.e. has a MZ header), it really executes it regardless of the extension, and its association settings.

This doesn't seem to be documented anywhere (in official MS documentation - or did I miss something?), but I was able to verify this behavior by analysing the implementation of the start command; it first uses the CreateProcess API function, used to execute applications; only if this call fails, it tries to use the ShellExecute function which uses the extension association settings.

BTW alan, one explanation of the fact that it didn't work on your machine would be that (maybe) you used a COM file virus (and not EXE) [e.g. eicar.com] - as COM files don't have any recognizable headers, it would behave exactly as you described.

Thanks
Vlk

[alanrf]

Vlk,

you have hit on it in one ... the virus I used was a com file ... sorry that I didn't comply with the unspecified parameters of the original poster  ... I must try harder. 

[Vlk]

Thanks for confirmation - I'm glad it's at least consistent.

BTW solcroft, how'd you find out about this behavior? I have to confess I was not aware of this, and it IS an important detail...

Cheers
Vlk

[solcroft]

Thanks for confirmation - I'm glad it's at least consistent.

BTW solcroft, how'd you find out about this behavior? I have to confess I was not aware of this, and it IS an important detail...

Cheers
Vlk

No particularly clever methods involved, to be honest. It was just by chance.

[Vlk]

BTW the way we plan to fix this is that each entry in the exception list would also have a bit mask RWX (read, write, execute) and this way it would be possible to choose on which of these actions will the exclusion take place.

The default extensions would be RW only.

[alanrf]

Good move!

Next point release or next big release?

[solcroft]

Thanks for the update. If only the virus analysts at Alwil respond this fast to malware submissions...

Just out of curiosity, why not do it the way many other vendors do, and include an option to scan files based on content-type rather than extension? Is there any particular reason why the "regular" solution isn't adopted in this case?

[igor]

The scan itself is somehow content based - but the exclusion list is meant for excluding; if you want to exclude a known "grey-area" program, or even a false alarm - you want to exclude it even when it's an executable file.

[Vlk]

Just out of curiosity, why not do it the way many other vendors do, and include an option to scan files based on content-type rather than extension? Is there any particular reason why the "regular" solution isn't adopted in this case?

First, which "other vendors" are you refering to, exactly?

Now, there's no "content-type" concept in Windows, really. To determine a file's content-type the AV would need to open the file, read a chunk of its data and based on what's read, decide of what type it is. This is generally not too fast (but in fact, it is done by avast in certain cases, e.g. while recognizing on-exec (looking for the MZ header) and OLE files on-open (looking for the OLE "d0cf11e" signature)).

But how would that help in the context of scan exceptions?

[Vlk]

Thanks for the update. If only the virus analysts at Alwil respond this fast to malware submissions...

I wasn't sure at the beginning, but now I'm positive this is solcroft from Wilders'

But of course, this is a valid point, too. I sometimes keep asking the same question myself. Things are moving forward, though. Infrastructure changes are on the horizon and I believe the improvements it eventually brings will be quite dramatic.

[solcroft]

First, which "other vendors" are you refering to, exactly?

But how would that help in the context of scan exceptions?

AFAIK, KAV and Avira do this, for one. As for how it would help in the context of scan exceptions, though... my bad, I was thinking of something else when I was typing that post. Guess I got a bit mixed up.

[Vlk]

OK.

As for specification of what to scan - avast uses the content-type concept, too, of course.
This is what the "Normal" scan sensitivity does.

Quick = based on extensions (no other files are opened)
Normal = based on content-type (all files are opened, content-type is determined and potentially infectable files are scanned)
Thourough = all files are scanned (no matter of extensions and content-types)

Cheers
Vlk

[solcroft]

OK.

As for specification of what to scan - avast uses the content-type concept, too, of course.
This is what the "Normal" scan sensitivity does.

Quick = based on extensions (no other files are opened)
Normal = based on content-type (all files are opened, content-type is determined and potentially infectable files are scanned)
Thourough = all files are scanned (no matter of extensions and content-types)

Cheers
Vlk

Aha, so that's what that slidebar does.

I've always wondered that myself. Personally I've always preferred my applications tell me exactly what their options mean, like "scan extensions only", "scan by content" and "scan all files", but I suppose it's not as "user-friendly", so to speak...