While away from the computer, suddenly I started hearing Avast call out warnings one after another. I brought the computer out of monitor power down mode, only to find file after file being sent to the Virus Chest. In all, a total of 15 files. Files that include WinAMP, DirectX, Epson printer and mouse driver archives. These files have been residing in the same place for months, some for years. All are reported to have a Win32:Tenga virus. No, they don’t have a Tenga virus or any other kind of virus.
Virus definitions were last updated on 2011-04-23 @2:49 pm. Why it took Avast 14 hours later, when the computer was doing virtually nothing during this time, to suddenly find all of these false positives makes no sense. It’s as if Avast had some sort of computer seizure. But, that is not even the worse part. The worst part happened when I went to restore all the files. Turns out every single one of them is now destroyed.
What do I mean by destroyed?
I mean that Avast restored files from the Virus Chest that are not equivalent to the original files that when into the Virus Chest. These files have been altered to the point of being destroyed. They are now worthless. The files might as well have been deleted and not restored. What is the point of restoring files if they are not completely and fully restored?
Because the Virus Chest can not be trusted to restore files, I have disabled it as much as possible.
Speaking of disabling something as much as possible. Why is it that when you disable the Community pop-up thing, Avast continues to litter the temp directory with “cmc*.tmp” files. Shouldn’t Avast also stop downloading those files, which are nearly always the same file, once the option is disabled?
Don’t misunderstand, I like Avast. I just hate these two issues with a passion.
Can someone please explain to me why Avast doesn’t completely and fully restore files from the Virus Chest?
Also, can someone please explain why Avast deems it necessary to continue to download CMC files when the option is disabled?
The Avast destroyed files continue to trigger false positives in their destroyed state. This after all updates are current. All Avast destroyed files have been re-download from their respective owners. Copying these re-downloaded files back to their respective original directories results in more false positives, only this time Avast wasn’t allowed to automatically move them to the Virus Chest, so they are, for the moment, safe from Avast.
An interesting side note. Avast is so confident with it’s findings, that it doesn’t offer an option to ignore false positives through the alert user interface. Rather unfortunate when you have to go through so many false positive files in a row.
Since nobody else is reporting any false positives by Avast, I would suspect that you have been infected by something new that slipped by Avast. Try scanning with Malwarebytes and see if it finds anything.
Someone has to be the first and with my luck it had to be me.
Well, to be honest I had my doubts it was something new. I ran a full Malwarebytes scan. Below is the Malwarebytes log with additional comment supplied by me on it’s findings.
I believe the elapsed time to be inaccurate as it took longer then what’s shown here.
I’m not entirely sure about this one. I looked at this specific registry entry and all that is there are color space formats values (eg: YV12,YUY2,RGB24,RGB32,etc). I’m not familiar with “Videosoft”, so I did a Google search and found a reference to something called zCODEC, which I think is a H.264 Decoder. I’ve not heard of zCODEC before and I do NOT install CODEC packs, although it could have been slipped in with some other software.
Doing a search through the entire registry for “Videosoft” turned up something called, “VideoSoft VSPrinter 7.0” and that branch mentions “VSPRINT7.ocx”. The properties for “VSPRINT7.ocx” says that the file dates back to the year 2000. Other hits for “VideoSoft” in the registry include “Vsflex7.ocx” and “vsflex7L.ocx”, both also from the year 2000. It looks to be from something called, “VideoSoft FlexGrid 7.0 (Light)” which also doesn’t sound familiar.
I take this to mean nothing more than a general warning that Windows security is disabled. I have no use for the Windows versions with a hardware and software firewall, Avast and doing manual Windows updates.
This is a false positive and demonstrates what I believe to be a bug within Malwarebytes. Both a quick and full Malwarebytes scan repeatedly shows WinDump.exe to be malware. However, if I do a single scan through the right-click context menu with Malwarebytes on the file itself, it passes and no malware is found. Avast also green lights WinDump.exe. Also, the current downloadable version of WinDump.exe is byte for byte identical to the same version that I have, which Malwarebytes deems as malware.
So, in the end, the only questionable thing that Malwarebytes found is an old “Videosoft” registry entry.
Lastly, I’d like to take a moment to describe better the situation. I have a single directory that contains multiple sub-directories. Each sub-directory contains one piece of software that is necessary to do a complete re-install on a Laptop. Files like Avast, drivers, Firefox, WinAMP, etc are each contain in their own separate sub-directory. In addition to this Laptop archive directory, I also store duplicates, including the PAR2 files, on a separate hard drive that is disconnected from the system.
Take for example WinAMP. When I downloaded (at the time) the latest version of WinAMP in January 2011, I immediately created an associated PAR2 verification file. Each sub-directory contains one matching PAR2 file so I can test the archive’s integrity at a later time.
When the WinAMP installer was destroyed and after changing the way Avast automatically sends things to the Virus Chest, I went to the the duplicate archive and tested the WinAMP installer with the PAR2 file and it passed. When the WinAMP installer was copied back to the Laptop directory, Avast displayed a warning dialog that it was infected with the Win32:Tenga virus. I closed the Avast warning, since there was no option to “Do Nothing”, and the file was copied. I then checked the the copied file with the existing PAR2 file and it passed. I then checked with a binary compare program and the files were identical. Using the right-click context menu, I did a single scan on the WinAMP installer and it was supposedly infected. To me this has false positive written all over it.
Although some of the destroyed files were obvious, such as only being 180KB when it should have been 11 MB, it was through the use of these at the time created Par2 files that I verified the less obvious destroyed files and their eventual replacements.
Since my original post and subsequent reply, Avast’s brain file has been updated to the latest 110425-0 version. A scan of the entire laptop archive directory now shows that there are no Win32:Tenga virus. It would seem that the false positive, for the moment anyways, has been corrected.
I don’t know how to export the scan log and I see nothing in the help file that pertains to saving out the scan log. However, over the course of this entire issue, oddly enough there is only one entry listed in the scan log that says “Virus Found”. That entry is for WinAMP and reads as follows:
File name Severity Status
C:\Laptop\WinAMP\WinAMP v5.601_full_emusic-7plus_en-us.exe High Threat:Win32:Tenga
Due to the amount of action that Avast took yesterday on it’s own, I would think there would be more than one entry listed. Unless I’m looking in the wrong place for a log, the scan log is the only one I see in the Avast interface.
When you google Win32:Tenga you will easily find out it’s a file infector. A file infector infects executable files by adding itself to them, what explains that Avast! is detecting what for the user seems to be legitimate files, but they are indeed infected. What I don’t understand is that Avast! doesn’t detect Win32:Tenga itself in the first place. Maybe a new variant ?
As I am definitely no malware expert, I will ask our specialist Essexboy for his thoughts about this
I’ve known about Microsoft’s Lifecycle policy for a long time. It could be argued that it’s not a concern until and most likely well past, 2014-04-08. It’s not as if the OS is suddenly going to stop working on 2010-07-13. Besides, this in no way has any bearing on the issue at hand.
The issue is that Avast’s Virus Chest destroyed the restored files. This is of course not a OS issue, it is a Avast default setting issue. I’ve since learned that due to the low default values for the Virus Chest, the files were destroyed most likely, going into the Virus Chest. It would seem that Avast never took into account what would happen if suddenly a large amount of files or their size, would be deemed bad and moved repeatedly into the Virus Chest. With no contingency plan for this happening, such as a warning that the Virus Chest was about to become full and/or an option to immediately increase the Virus Chest size, or allow some other user interaction, the files were instead destroyed.
The main thing that would give us a clue as to whether or not you are infected is, are there any unusal behaviours or symptoms on your system at the moment ?
Although for a false positive I would have expected a flood of people on the forums. I take it Avast is quiet now ?
At this time, I very much doubt that it’s a new variant. As I mentioned, when the WinAMP installer was downloaded in January 2001 from the Nullsoft website, as I usually do, a PAR2 file was immediately created. Leaving the original in the Laptop directory, a copy of the installer and PAR2 file was placed on a temporarily mounted drive. Yesterday Avast suddenly and on it’s own, found the WinAMP installer and as well as other executable files, to be infected with a Win32:Tenga virus.
Before doing anything, I tested the copy of WinAMP with the PAR2 file on the temporarily mounted drive and it passed. I then copied WinAMP back to the Laptop directory and Avast stopped the transfer, saying that the transferring WinAMP file was infected. Without an option to “Do Nothing”, I closed off the warning and the file continued to be copied. Using the existing PAR2 file in the Laptop directory, the newly copied WinAMP file passed.
In review, WinAMP passed on the temporarily mounted drive using that PAR2 file. When copied back to the laptop directory, Avast said there was a threat and stopped the transfer. I allowed the transfer and using the PAR2 file located there, WinAMP passed. WinAMP was not added, modified or changed in anyway.
This morning a new virus brain file was downloaded from Avast. Since this recent update the same WinAMP file that Avast claimed to contain a Tenga when it was copied back to the Laptop directory, is now reported as clean.
The only explanation that I can think of that explains what happened above is that this started with a false positive. To me the worse part in all of this was finding out that the Virus Chest destroyed the original files. At this point, that’s the bigger issue.
I’m not sure why Avast would attempt to sterilize a Virus Chest file before restoring since “restore” doesn’t equal the same thing as “repair”, but lets say that’s what Avast attempted to do. A typical Tenga virus signature is about 4K in size. In one example, the original file was 11MB and after restoring it was severely smaller at 180K in size. And, according to Avast at that time, it still contained the Win32:Tenga virus. Other restored/repaired files were not restored to the point where the PAR2 file recognized it as the original file. So, the “repair” basically failed in that respect.
IMO, the Virus Chest default settings are too small. It doesn’t take into account a situation like this were the amount of files, and their size, can easily exceed the default values. As a result, with no monitoring of the current state of the Virus Chest and no option to adjust these values in real-time during the process, the files become severely damaged.
None. It’s now just as quite as it was three days ago.
Yes. While the computer is left on 24/7 and therefore it’s not possible for me to monitor it continuously, when I return to the computer there are no Avast threat warning dialogs on the screen and the Virus Chest remains empty.
Actually it is legitimate. Originally purchased at Frys Electronics as a non-upgrade WinXP Pro (includes SP1) disc. I probably still have the receipt someplace and if necessary, I’ll take the bronze looking disc and post a picture with your user name taped to the face of the disc to prove it.
The reason for not updating to SP3 is because I’m very selective about updates and all critical updates (these include what would be contained in SP3) have already been applied. It’s SP2 mostly in name only.
Well, the question was about a recommended Chest size. However, that doesn’t make one bit of difference since I gave it basically unlimited size and told Avast to always “Ask” when something is supposedly found. Regardless of these settings, Avast continues to destroy files on false positives.
This time around Avast destroyed the Microsoft Mouse driver installer, the FireFox installer and who knows how many other files, claiming, yes you guessed it, another Win32:Tenga virus. There are no Win32:Tenga viruses in these files! And, it destroyed the files when I specifically told it to do nothing.
Why? Because it probably places the file into the Chest, thus destroying the file, and when I tell it to do nothing it puts the destroyed remains back.
Will someone at Avast please fix the file destroying bug in the Chest? Please. Pretty please?
The question I keep asking myself is, why worry about getting viruses when Avast anti-virus is doing a rather decent job of acting like one all by itself.
Yesterday
From what I been able to gather, Avast destroyed 14 files by claiming they all contained the same Win32:Tenga virus. I reran MBAM and there is no difference between what was mentioned previously and now. Ran Spybot and besides a couple questionable cookies, Spybot encountered nothing of elevated concern.
I again manually restored all 14 files from backup. Then did a comparison by using the old individual PAR2 check files in the original directories and they are all identical.
In the case of Firefox, I went a step further and re-downloaded the installer. The installer passes the old PAR2 check file, a quick binary comparison and a SHA-512 comparison with the original Firefox installer. For all measurable purposes, the Firefox installer is identical! Yet, Avast wants to destroy the file as soon as the file is copied back to the original location.
After the first round of destruction, I set the maximum size of the Chest to zero (unlimited) and the maximum size of file to 2,097,152 KB (2GB) in an attempt to avoid a file from getting destroyed when it’s placed into the Chest. As I mentioned before, this didn’t make one bit of difference since these 14 files still got destroyed even though I tried my best when the threat dialog appeared to tell Avast to do nothing.
Sadly, at this point there is no direct selectable option to do nothing in Avast. The only option is the close gadget in the left corner of the threat dialog. Unfortunately, this arrogantly suggests that there would never be a time that you would want to do nothing. And yet, I watched in total amazement while Avast destroyed 14 files with each click of the close button on the thread dialog.
In any case, it’s interesting to note that some of these files are the exact same ones that were destroyed previously. These include such installers as the Firefox browser, Microsoft’s DirectX, Microsoft’s Intellipoint Software, Synaptics TouchPad driver, two WinAMP installers and two WinAMP plug-ins. All originally downloaded from their respective websites.
Based on the above, this suggests to me that while this is not likely to be a widespread issue, more likely a specific issue, Avast does has a repeatable Virus Chest bug. Of course, none of this would be happening if not for the Tenga false positives.
Today
Speaking of which, Yesterday evening I disabled the File System Shield until next reboot. A few minutes ago and without rebooting the computer, I re-enabled the File System Shield. I then did a manual scan of the same Firefox installer. No threat was detected.
I see that a new 110514-1 brain file was downloaded while I was away. It appears that this new brain file might have included a new Tenga definition. Either that, or disabling and enabling the File System Shield is related to the issue.
It would seem to me that regardless of the state of the File System Shield, which would likely only trigger the event, the fact remains that there is a Virus Chest file destroying bug within Avast.
Please, does anyone have any further suggestions to help Avast, and ultimately all of us – diagnose and find this bug?
On 2011-04-18 the v6.0.1091 program update was released. If we first consider when the program update was applied. Second, that a false positive would need to be introduced into the virus definitions to trigger the event. And three, the time required for Avast to get around to automatically scanning that particular area of the hard drive. This could explain why it took 6 days after the release for Avast to begin destroying files. One day later and a new virus definition, the same file one day before which showed a threat, no longer triggers the bug.
On 2011-05-11 the current v6.0.1125 was released. Three days later and with a subsequent new virus definition file to trigger the event, Avast began destroying files again. One day later and a new virus definition, the same file one day before showing a threat, no longer triggers the bug.
Prior to the release of v6.0.1091, I never experienced anything like this before. Ever since then, there’s been two separate, but identical incidences, where Avast has destroyed files, both related to moving files in and out of the Chest. And, if I’m not mistaken, this is an operation of the File System Shield.
I could be wrong as I’m not a programmer, but based on this it seems to me it’s possible that these “fixes” to the File System Shield in v6.0.1091 could have introduced a nasty new bug in Avast. That under the right circumstances, has the ability to unintentionally destroy files.
