I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.

The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.

I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time...

As I understand it, any file in an NTFS partition can have one or more Alternate Data Streams associated with it, regardless of its type or location. So if you tell someone not to scan something like "Edb.log", does that imply that they should not scan "Edb.log:virus.exe" either?

I have to agree with Trend Micro on this one. Completely skipping specific files in specific directories may prevent performance issues, but it may also make it easier for malware authors to find new hiding places.

Following up on my own post, yes it is DansGuardian that can be configured to block Google searches if Google SafeSearch is turned off. So maybe Microsoft's filter is taking a similar approach? The obvious thing to try is to turn off the MS filter, check your Google preferences and make sure SafeSearch is enabled, then turn the filter back on and see if the problem persists.

I seem to recall a much older filtering software package (I don't recall which offhand - DansGuardian, maybe?) that will block Google if you have disabled "SafeSearch" in the Advanced Preferences - that is, if you have it set to "Do not filter my search results."

Who is "Deaf Leopard"? Are they bigger than Def Leppard?

Semantics, semantics. My point was that User-Agent detection is *not* the right way to handle the problem.

As long as the setup program (EXE, MSI or otherwise) handles the detection prior to installation, it meets the requirement I stated: "That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems".

User-Agent "sniffing" is a bad approach under any circumstances - it's too easy, not to mention common, to fake. And since all script-based approaches I am aware of rely on User-Agent detection, they would be effectively broken as well.

If I were doing it, I would put the OS detection in the setup EXE itself. That way, the setup program could *authoritatively* determine what OS was in use, and block installation onto any invalid systems. But we may never know since you didn't finish the download and give it a shot. ;)

IE7 is now flagged as a Critical update, whereas the "Update Rollup 2 for Windows XP Media Center Edition 2005" (KB900325) is an Optional update. And guess what? If you install IE7 first - for example, if it is done for you automatically courtesy of Automatic Updates - the KB900325 update fails to install!