Removing Spyware

Looking for techniques for preventing and removing spyware? Checkout Mark Russinovich’s webcast. Start from section 33.

NOTE: Right-click the link and do a save as to save it to your PC. It does not seem to stream correctly by just opening the link.

– Soli Deo Gloria

The Beginning

Well, not really. I’ve been posting on news groups (USENET) since 1996 and was on FIDONet back in 1995 (remember the BBS days?). I’ve always found it fascinating how the Internet allows people to exchange information. What prompted me to start a blog was Mark Russinovich starting one here. To see what kind of geek I am you can check out my web page.

To start off this blog I’ll describe how I fixed an Excel upgrade problem yesterday. I was assigned a task of upgrading Excel 2000 to Excel 2002 on a PC running Windows XP Professional. Easy, right? Upon installing it and testing it as myself it worked fine. The next day the user called me stating it was crashing. Indeed, it was crashing quite hard. The application seemed fine until you went to File>Open and then it went to never-never land. Since it worked as me this boiled it down to a permissions or NT profile issue. I reved him back to Excel 2000 which surprisingly worked fine. The next day I went back to reinstall Excel 2002 and check things out while the user was at a meeting. Upon checking the local administrator’s group I saw that the user was already an administrator on the machine, thus eliminating a permissions issue.

I then started up Filemon which is a excellent little freeware utility by our friends at Sysinternals. I setup a filter in Filemon to just show me the excel.exe entries. The last file it read was C:\windows\system32\davclnt.dll. I decided for fun to rename this file to see if that would fix the problem. Of course, this action was not really logical….after all, it would have used the same file logged in as me, right? Any ways, I renamed the file and the appeared back within seconds. Drats! Windows File Protection (WFP) rears its ugly head. Introduced in Windows 2000 WFP protects critical Windows system files by looking for changes. If you touch a critical file by renaming, deleting, or overwriting it, Windows copies the “good file” from a secret folder called dllcache. For a while you could disable WFP by setting “SFCDisable” to FFFFFF9D in the registry. However, Microsoft later removed this feature with their service packs for Windows 2000 and XP.

To get around this you can hex edit the sfc_os.dll file. However, this didn’t work for me and is a bit messy. I like using XP Lite for this purpose. There is a trial version available for download that the author states “is yours to keep!“. In the trial version there is an option to turn WFP On, Off or to Disable it. So I can turn it off, do my dirty work and when I reboot, WFP turns itself back on. Well, getting back to davclnt.dll: renaming it did not work. I started to think the problem was in the HKEY_CURRENT_USER (HKCU) part of the registry (logged in as that user of course). So I started up Regmon this time pausing it just before I went to File>Open. I then saw something interesting. Under HKCUNetwork there was a bunch of drive mappings and one of those mappings was pointing to a bogus server! I exported this key out (always export trees before you start deleting them!) and then deleted it. Tada, problem solved!

Now the interesting question is: why didn’t this happen with Excel 2000? Who knows. In this instance deleting the user’s NT profile may have been quicker. However, I’ve only been at this company for a month and therefore I am not well versed with all desktop standards. Besides, the user was gone and his NTUSER.DAT file was 4MB: that’s a lot of information to just throw away!

That’s it for now. Look for an upcoming article on making hardware independent ghost images for Windows 2000 and XP.