Practical computer tips, with a smattering of digital philosophy
I’m happy to report that I just stumbled across a bit of information that fixes a serious flaw/oversight in my malware removal how-to guide, and sheds a great deal of light on the inner workings of one of the more obnoxious families of malware currently slithering around on the Internet.
For those of you who are anxious to get to the fix, check the symptoms section (directly below) to make sure that these instructions apply to your situation, and then jump straight to the larger text at the very bottom of the page.
The malware that this fix addresses is a rather common breed, often bundled in with some larger malware packages – but there’s no question it’s an extremely nasty monster in its own right, because it has the ability to:
Those of us who know a bit about networking will probably be tempted (as I was, repeatedly) into thinking that this bug simply relies on the age-old trick of mucking with the hosts file – which makes it all the more infuriating when you open your hosts file and discover that it is apparently completely uncompromised. No, this particular varmint is considerably more subtle and sophisticated than a simple hosts-file corrupter. In fact, it’s not even an executable, nor an executable .dll – which means that there’s no way to either find or kill it using a task manager (even Process Explorer) – because it technically isn’t a task. As it turns out, the bug is actually nothing less than a full-blown system driver, powering a virtual device that actually doesn’t exist – but one which (as far as Windows is concerned) is every bit as real as your mouse or graphics card. And in the course of investigating this bug, I’ve discovered that Windows seems to protect all files associated with active devices in such a manner that they are completely impossible to see, much less delete. Which means that the general malware-removal method I outlined previously will do absolutely nothing to kill this thing – except, of course if the driver is no longer loaded. That means that those who opt to clean out their system32 and system32/drivers directories via a Linux live CD will have no trouble at all – but those who aren’t inclined towards that kind of thing will need a different solution.
Go to Start > Control Panel > System > Hardware > Device Manager > View > Show Hidden Devices.
Scroll down to “Non-plug and Play Drivers” and click the plus icon to open those drivers.
Then search for “TDSSserv.sys”
Right click on it, and select “Disable”
Note: If you select Uninstall, it will install itself again when you reboot the system, so DON’T select Uninstall.
Restart your pc.
You can now update your Antirus/Malware/Rootkit softwares and the go.google rubbish will stop.
Its now up to the Anti-Virus/Malware/Spyware companies to make an effort to stop this, and not rely on simple basic home PC user’s like myself to save the world
In simple terms, TDSSserv.sys is a service/server redirecting all software updates to 127.0.0.1 (your own computer) so they won’t update
If you’re an extremely zealous/through sort, you could even go and remove (*carefully*) all the instances of “TDSS” in the registry, but I’ve never done so, and no computer I’ve worked on has suffered as a result. Once the driver files themselves are decomissioned/deleted, the bug is vanquished.
Google search optimization section (ignore this):
cannot run malwarebytes, cannot install malwarebytes, searches redirected, google not working, cannot use google, go somewhere else, broken, cannot acces, cannot update anti-virus, blocked
Chances are that if you’ve read this far you have a pretty good idea what I’m talking about, so I’ll refrain from describing the phenomenon in detail here, and simply refer you to this discussion from the Ubuntu forums. In general, however, what happens is that an afflicted computer will somehow kill the power to its own keyboard (and, in some cases, its mouse as well) upon resuming from sleep or screensaver mode. It does this for no apparent reason, and (in my experience) at totally random intervals. The operating system isn’t technically frozen, but it might as well be – particularly if you (like me) have your computer set up to prompt you for a password after being idle for x minutes. The only way to “fix” the problem is to pull the plug on your computer (do a cold reset) – never a particularly pleasant or safe experience, and potentially a truly disastrous one if you happen to have unsaved documents open at the time of the failure.
At any rate, I’ve yet to find any particularly convincing theory as to what might cause (or prevent) this phenomenon, so after a few bouts of research and much tinkering I’ve decided to put forth my own. I sincerely hope someone will (a) benefit from it, (b) test it, and/or (c) provide evidence that it’s totally and completely wrong. My main interest here is just to hone in on what’s actually causing the problem, because although it seems to be fairly widespread, few in the linux development community seem to be paying it much heed.
Anyway, to get to the point:
I realize that this notion may make absolutely no sense from a technical perspective, but I’m going off of pure empirical evidence here, and the evidence stands as a follows:
– This kind of failure always occurs during a period when a given computer is idle – when one would expect a screensaver to be invoked.
– I’ve often noticed various strange screen saver glitches and “artifacts” appearing immediately prior to the failure; sometimes the screen saver might fail to appear entirely; sometimes it might be fragmented, and certain sections of the screen would seem to be covered by black boxes, and so forth.
– The Ubuntu discussion mentioned above, which is by far the longest analysis I’ve been able to find of the issue, ended without really concluding anything, but some participants thought that the problem might be caused by compiz. I’m almost positive this isn’t the case, however, because I’ve encountered the issue under SuSE 10.2, which definately was not using compiz.
– I disabled my screensaver entirely a few days ago on my Ubuntu installation, and my keyboard hasn’t yet failed.
– Even if the GL screen saver engine were known to be buggy, who would make it a priority to rewrite/debug it? My guess is that screen savers probably aren’t on anyone’s list of top 100 (or 1000) development priorities.
Some of you will doubtless already be experts on Google’s privacy policies (or lack thereof), and many of you have probably heard vague mentions of some of their more disasterous public appearances – but to all those who haven’t had a chance to actually read Google’s formal statement of its policies regarding user-supplied content, be warned: the following will blow your mind. At least, it should. If the statements below don’t at least give you pause for thought, I’d suggest that you really need to take a closer look at the long-term implications of these kinds of policies (which, in fariness, are hardly unique to Google).
Without further ado, here are the golden words, which (as far as I can tell) apply to every single one of Google’s online services (gmail, calendar, docs, bookmarks…)
“11. Content licence from you
11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive licence to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services. This licence is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.
11.2 You agree that this licence includes a right for Google to make such Content available to other companies, organizations or individuals with whom Google has relationships for the provision of syndicated services, and to use such Content in connection with the provision of those services.
11.3 You understand that Google, in performing the required technical steps to provide the Services to our users, may (a) transmit or distribute your Content over various public networks and in various media; and (b) make such changes to your Content as are necessary to conform and adapt that Content to the technical requirements of connecting networks, devices, services or media. You agree that this licence shall permit Google to take these actions.
11.4 You confirm and warrant to Google that you have all the rights, power and authority necessary to grant the above licence.
Are you really comfortable with every word that you write or read on-line being scanned, indexed, store, and shipped off to a variety of unspecified coorporations for the purpose of giving you a “more immersive web experience?” Or having an email to your cousin used in Google promotion?
If you’re even moderately outraged, good. But hold on – there’s a rather complex caveat that might confound your ire. Though I too find this whole arrangement thoroughly noxious, I must admit that google’s overall philosophy towards content ownership does in some ways seem remarkably in-tune with the “open culture”/ creative commons / copyleft movements – trends which I heartily applaud and support. The question of whether anyone can truly be said to “own” content in the Web 2.0 universe – and whether or not, in this day and age, the whole notion of content ownership is in fact totally obsolete – is one of great importance, and as much as I’m loathe to admit it, google’s “you no longer have exclusive rights to anything you produce on-line” doctrine can some ways been seen as little more than an unapologetic – and even, perhaps, foresighted – dose of reality.
Forward-looking though they may be, Google’s policies still rankle. And I’m not sure I’m entirely comfortable with the kind of future such polices forshadow.
I’ve just spent an invigorating hour trying to figure out a solution to the (apparently rather common) “I want to mount a partition at boot, but I don’t want it mounted as root” conundrum.
For many file systems, the mount man pages tell us, this problem can simply be solved by adding uid=<your user id #>,gid=<your group id #> to the options section of the fstab entry for the partition in question, which will cause it to be mounted with you as the owner. For the record, the problem can also be theoretically be solved by allowing the partition in question to be mounted with root as the owner, and then laboriously going through and changing the owner of every file in the partition (chown <you> /<the pesky partition>/* -r). But honestly, who wants to do something that inelegant? (Okay, fine: yes, I probably would have gone right ahead and resorted to this, but for reasons which remain unclear to me this didn’t work in my particular situation).
However, I happen to be using XFS, and the mount man pages make no mention of the uid= and gid= options being suitable for use with XFS filesystems. Since the man pages also say nothing about them NOT being usable with XFS filesystems, however, I gave them a try, and am now happily reading and writing from my mounted partition as myself.
I know this is probably pretty basic stuff for some of you, so please feel free to chortle depreciatingly, if the mood strikes you.