Author Topic: reported number of "Tested files" may not be accurate  (Read 3459 times)

0 Members and 1 Guest are viewing this topic.

ady4um

  • Guest
reported number of "Tested files" may not be accurate
« on: January 21, 2011, 03:15:12 AM »
My system:
Avast Free 5.1.889; Vista Home Basic 32 bits x86 with SP2.

Let's say I download some file.
Immediately after the download finishes, I open the folder where the downloaded file was saved.
I right-click the downloaded file and select "Scan" with Avast.
When the scan finishes, a "report" dialog is displayed, where I can read, among other info, the number of "Tested files".
When the report states that the scan result is OK (no virus found), I exit the mentioned dialog.
Then I open the file's properties, and click on the "Unblock" button and close the file's properties by clicking "OK".
Now I repeat the scan on the same file using the same method as before.

Here's what I see:
One downloaded file still "Blocked" -> number of "Tested files" is TWO.
The same file scanned after I "unblock" it -> number of "Tested files" is ONE.

I Don't know if the number of actual "Tested files", when the file is blocked, is "correct", in the sense that maybe "something" is being done in the background (either by Avast or by the OS itself) that makes the process to scan actually 2 files. If this is the case, then in that sense the report is technically correct.

I haven't checked / compared the other numbers of the report (like scanned size).

Offline Charyb-0

  • Avast Evangelist
  • Massive Poster
  • ***
  • Posts: 2508
Re: reported number of "Tested files" may not be accurate
« Reply #1 on: January 21, 2011, 03:35:39 AM »
What do mean block and unblock? Was one of the files quarantined?
Are you using AppLocker or some other application locking program?
« Last Edit: January 21, 2011, 03:58:10 AM by Charyb »

ady4um

  • Guest
Re: reported number of "Tested files" may not be accurate
« Reply #2 on: January 21, 2011, 03:58:08 AM »
Really? I was so not clear?

What do mean block and unblock?

Quote from: ady4um
Then I open the file's properties, and click on the "Unblock" button and close the file's properties by clicking "OK".

Quote
Was one of the files quarantined? Where can I download this file?

No quarantine; just ANY file downloaded to any NFTS volume under Windows (NT and up if I remember correctly) is automatically "marked" as "blocked".

So, to reproduce the behaviour, just download ANY file, save it to your "Downloads" folder, and open the file's properties. At the (default) "General" tab, on the bottom-right corner you'll see the "Unblock" button.

It's a permissions-related attribute.

Quote
Are you using Windows 7 Ultimate or Enterprise? Are you using AppLocker?

Quote from: ady4um
My system:
Avast Free 5.1.889; Vista Home Basic 32 bits x86 with SP2.

So no Windows Seven, and since it is Home Basic, no AppLocker.

TIA.

Offline Charyb-0

  • Avast Evangelist
  • Massive Poster
  • ***
  • Posts: 2508
Re: reported number of "Tested files" may not be accurate
« Reply #3 on: January 21, 2011, 04:20:44 AM »
I understand now. I was thinking you were using the term block in place of quarantine. Completely different subject here. I don't know exactly how the block/unblock information is stored within this file. Please read here: http://www.petri.co.il/unblock-files-windows-vista.htm

Towards the middle of the article it states (I know it shows Vista but same idea for XP):

"The reason for this is because, in Vista, the file's zone information is being preserved within the file. As a general practice, this identifies where the file came from and kicks off warnings as appropriate, telling you to be careful. However, we, as masters of our computer, know better (Lamer note: Remember that previous note about having a good and updated AV and Malware protection software, right?)."

This may explain the additional file in the scan. When you unblock it I assume that the file with this additional information is deleted. However, when I unblock the app, the file size does not change. I suppose you would have to know inside windows programming to know exactly how this file information is attached to the downloaded file.

« Last Edit: January 21, 2011, 04:59:18 AM by Charyb »

Nesivos

  • Guest
Re: reported number of "Tested files" may not be accurate
« Reply #4 on: January 21, 2011, 04:53:57 AM »
Quote
Vista Blocked File Protection Control

Windows Vista is known to be much more picky about the file types it allows the user to use than previous operating systems. Some file types are considered to be a potential threat, and therefore are blocked........................

The reason for this is because, in Vista, the file's zone information is being preserved within the file. As a general practice, this identifies where the file came from and kicks off warnings as appropriate, telling you to be careful. However, we, as masters of our computer, know better (Lamer note: Remember that previous note about having a good and updated AV and Malware protection software, right?).

By the way, if you download a .zip file then extract the files, each of the extracted files gets a named stream that points back at the .zip file. This means you still get the warning.


BTW, this "feature" is not native to Vista alone, Windows XP SP2 + IE 7 also exhibit this behavior.

More on link :)


http://www.petri.co.il/unblock-files-windows-vista.htm

ady4um

  • Guest
Re: reported number of "Tested files" may not be accurate
« Reply #5 on: January 21, 2011, 05:13:43 AM »
Towards the middle of the article it states (I know it shows Vista but same idea for XP):
Yes, it is more or less the same for XP. I say this for OTHER users who might want to know about this, not because of mine OS, which is Vista, not XP.

Quote
This may explain the additional file in the scan. When you unblock it I assume that the file with this additional information is deleted.
It is not really an additional file, but an attribute of the SAME file.

NOTE: For anyone reading this, please do not confuse this "attribute" with the more common attributes:
 r: Read Only
 s: System
 h: Hidden
 a: ready for Archive

If there is any other "additional" file, is only a temporary one, created for the only purpose of scanning it (by Avast). I don't know "who" is responsible for that "additional" file, Avast or the OS itself.

Quote
However, when I unblock the app, the file size does not change. I suppose you would have to know inside windows programming to know exactly how this file information is attached to the downloaded file.

Well, *I* as a simple user, don't really *need* to know anything about this "additional" file. I don't even know if there *is* an additional file, or is some kind of issue in the Avast report.

As I said, *if* there is an actual additional temporary file, then the Avast report is "technically" correct.

My first intention is to see if other users can reproduce this same behaviour, or is it only my own system.

My second goal is to report this issue to Avast devs, so they can check / test this by themselves. I am just a simple user. Avast devs, as Avast programmers, should know where to look at, and eventually decide if this behaviour is adequate.

Even if Avast devs conclude that this type of Avast report ( "double" "+1" number of "Tested files" ) is technically correct, maybe they want to review this issue eitherway.

What I mean is, from a UI point of view, there are no "additional" files being scanned.

Of course, this is no different from reporting a number of "Tested files" different from "ONE" when Avast scans a compressed zipped file which actually contains, say, 100 files inside. In this case Avast will not report just "ONE" file scanned, since it also scanned all the content of that zip.

To be clear, I don't have any problem with the "block" attribute and I understand what's all about. I just wanted to share what I saw in my Avast report. This MOST probably will not even be considered as an "issue".

TIA.
« Last Edit: January 21, 2011, 08:57:49 AM by ady4um »

Offline igor

  • Avast team
  • Serious Graphoman
  • *
  • Posts: 11849
    • AVAST Software
Re: reported number of "Tested files" may not be accurate
« Reply #6 on: January 21, 2011, 10:00:22 AM »
Even though it is an "attribute", technically the information is stored in an NTFS alternate data stream. So yes, there is an additional object scanned.

As for whether there's nothing else being scanned from the "UI" point of view... that's certainly questionable. If you enable creation of a report file (for the scan you're running) and let even "OK files" be included there, you'll see that additional object there. Also, if there was significant amount of data in the alternate data stream (or malware, which is certainly possible), you could also see its name in the progress display or in the list of scan results.

ady4um

  • Guest
Re: reported number of "Tested files" may not be accurate
« Reply #7 on: January 21, 2011, 02:51:29 PM »
Igor,

I agree with you that technically there is another object.

What I meant with the "UI" comment is that a simple (specially newbie) user thinks that he selected just one file to scan, and the results dialog states that there were 2 instead. "Where is that other files (object) that was scanned?", he might think. Or maybe "Is there any (hidden and problematic) file (object) included?" might be another idea of such a newbie.

By a "simple user" I mean a user that just wants to use the system/program. As usual, a simple adequate comparison is with a car's user who doesn't know anything about motors or thermodynamics.

The example of a zip file is clear. A downloaded zip archive containing 3 simple (txt) files, when scanned, will represent 5 "Tested files". From those 5 "Tested files", 3 are the content of the zip, 1 is the zip itself, and 1 additional object is the NTFS alternate data stream you mentioned. Unblocking the zip and rescanning will give 4 "Tested files".

Sure, setting the logs to report "everything" might clear the possible doubts.

As I said, I understand what's all about, and probably this is not even an issue. If other users can reproduce this exact behaviour, and Avast devs / team think the report is "adequate", then it's all fine with me.

Thank you all for your answers.