Practical computer tips, with a smattering of digital philosophy
FYI – if a linux distro mounts a disk as “sda1,” that by itself does not, apparently, serve as definitive proof that the drive in question is in fact a serial drive – if the drive happens to be in a laptop. For those of you who are scratching your heads and wondering what exactly I’m blathering about, here’s the deal: as I understood it, the standard convention was for most linux distros to automatically assign the name hd* to IDE hard disks, and sd* to all disks with serial interfaces (either USB or SATA). This rule of thumb apparently does not apply to laptop hard drives, however, which I just found out the hard way.
Of all the issues I was thinking of discussing first, this one seems by far the most urgent, since the epidemic of computers being infected by malware masquerading as anti-malware is growing worse by the minute.
If you’ve come to this page by way of a google search for the aforementioned “applications,” chances are you’ll already have encountered (and possibly tried to follow) several different sets of conflicting instructions for removing your nasty parasite. While many of these how-to guides do offer useful advice, most are unfortunately somewhat incomplete; they point you to a few heavy-duty, heavily-specialized anti-malware applications that can detect MOST – but not all – of the artifacts associated with the bugs infesting your computer. After some 20 hours of fiddling with the programs recommended by these sites, as well as some other top-notch diagnostic utilities, I’ve managed to devise a removal method that is extremely fast, straightforward, and effective, and that doesn’t really require the use of ANY third-party applications at all! Because I suspect most of you are primarily looking for a quick fix, I’ll spell out exactly what you need to do first; those of you who are interested in the derivation of this technique, and proof that my suggestions are based on empirical evidence, please see the section following this step-by-step procedure. Without further ado:
Basically, antivirus 2008 xp, antivirus 2009 xp, antispware 2008 xp, and whatever other titles these bugs have decided to call themselves all work roughly the same way: they embed randomly-named files with misleading extensions in your system folders, and then use valid windows components (rundll32.exe, for example) to execute themselves. Several features of this design are, I am forced to admit, fiendishly clever. Because the malicious files have randomly-generated names (kjO1xpf.log, for example), neither you nor your antivirus application can check the files against a list of dangerous filenames. [Update: for malware from other families, there’s a chance that a different, but equally devious tactic will be used to disguise the dangerous files: they may be give names that are identical, or nearly identical, to the names of critical windows files. winlogon.dll seems to be a popular one.] Furthermore, because most of the damage is done by files that aren’t themselves executables, tracking them down by means of process analysis (looking at the list of currently-running processes on your computer) is also nigh on impossible, because the processes associated with the bug (other than the “Antivirus 200?…” process, which doesn’t actually do anything other than annoy you, and can be instantly re-generated by its hidden helper-files) are almost all instances of some Windows component (again, like rundll32.exe) which look completely legitimate.
However, these bugs have a couple of critical weaknesses: though they can engage in some pretty sophisticated spoofing, they cannot change the time and date that their files were created, and they cannot identify their files as Microsoft products. Typically, all the files responsible for generating and sustaining these bugs are created within the same two-day period – and because they’ve chosen to store themselves in a folder filled with system files, which generally aren’t modified very often, they are likely to be the vast majority of those files that appeared in that particular time/date range. Therefore, here, more or less, is what you need to do (I’d recommend doing all of this with Windows explorer in “detailed list” view mode – it makes sorting and finding things a lot easier).
– Restart the computer.
I’ve developed this strategy over the course of several months, during which time I’ve had the pleasure of encountering no less than five heavily-infected laptops: four being plagued by variants of the “antivirus 200x XP” bug, and one suffering from a variety of bugs that were almost certainly from a different family (see below). In all five cases, I was able to completely remove the malware (granted, in a couple of cases some artifacts remained, but these were just consequences of all the disgusting policy-hijacking these programs love to engage in; no trace of an active infection remained. And I suspect that if I’d used the policy fixers I now know about on those machines, those remnants would have disappeared).
At any rate, I just had an opportunity to joust with a particularly bad infestation on a laptop – and though the process took over 3 hours, the information I gleaned in the process was extremely valuable. What was particularly remarkable about this situation was that though none of the bugs on the machine in question seemed to have any direct relation to the “Antivirus 2009 XP” family of malware, the procedure described above proved equally effective here – with a few minor tweaks. In other words, my experience this evening has confirmed something I’ve suspected for quite some time: many malware developers are apparently relying on a relatively narrow and predictable set of techniques to conceal their wares – and though these techniques are often extremely effective at bamboozling anti-virus engines, many of them cannot survive even the most cursory examination by a human who knows what to look for.