I was running a routine system scan with MalwareBytes.org's Anti-Malware program, which has served me very well in the past. It found files left behind by the Vundo virus I had that Spybot, Norton, and NOD32 all missed. MBAM also didn't show any of the numerous false positives I encountered with NOD32 (which prompted me to stop using it) so it earned my trust rather quickly.
The scan finished, and it said there was a problem with my boot.ini file. Putting my trust in the program that had yet to lead me astray, I allowed it to quarantine the file. I figure, worst case, most quarantined files can be restored if it causes a problem. That's true, provided you can get to Windows and run the program that quarantined the file in the first place. This is where the trouble started.
I knew boot.ini was important, but figured Windows would/could rebuild the file during the next reboot, based loosely on our experiences here, and the significance of this event was lost on me. Rather, it was until the next day when I turned on the computer.
Rather than the usual black and white DOS-flavored nonsense, the Windows progress bar, and then my friendly login screen, all I got was a black screen with white text telling me that the computer could not start up due to a problem with my hal.dll file either being corrupt or missing entirely. That still cracks me up: is it missing or corrupt? You'd think a computer would know the difference.
A quick search revealed that this can be a quick fix, or a pain-in-the-butt fix to work through. If the hal.dll (Hardware Abstraction Layer, protects hardware, memory, etc. from malicious software) is truly well and fu…er, corrupt, you need to try to repair your Windows installation from the Windows CD, use the recovery console to manually fix it, or wipe and reinstall your whole OS. Not exactly something I was dying to do this fine afternoon, especially when I was already supposed to be working. I fiddled around with this for a while, unable to get the repair/recovery console fixes to even do anything, so I opted to look into the other methods.
The simpler fix said that sometimes hal.dll errors pop up if there's a problem with – you guessed it – your boot.ini file. Apparently Windows couldn't/didn't rebuild it after I allowed Anti-Malware to quarantine it, as it's something you need prior to Windows even starting. If I can't get to Windows to rebuild the file, DOS wouldn't even start, Safe Mode was hosed, what's a guy to do? Gut the computer, that's what.
It was a Sony VAIO SZ-series laptop, and opening the thing can be a pain largely due to its compact size (one of the things I love about it). Still, I'd done it before, so away we went with the screwdriver, and I was at the hard drive before long. The idea here was to take out the HDD, hook it up to another computer as a secondary drive, rebuild the boot.ini file on the drive manually, pop it back into the laptop, restart, and (fingers crossed) all would be well.
This is where you say, "But it's a laptop drive, silly; you can't just throw it on a regular cable in another computer, you'd need something special!" and so I do. I used this handy dandy Vantec everything-to-USB adapter I picked up at Micro Center instead of a single-use hard drive enclosure. I extracted the afflicted hard drive, connected to the appropriate SATA connector on the adapter, powered it up, plugged it into an available USB port on my girlfriend's computer, and presto: there were the drive's contents on display.
Now to the task of rebuilding the boot.ini file. There are some standard ones out there to work from, but since my original boot.ini was quarantined, I couldn't open it to see if my system had any specifics. Fortunately, my gf has almost the same laptop as I, only with Windows XP Home, whereas I have Pro. Easy enough to copy her boot.ini and edit the name of the OS it should be looking for. Things seemed ready to rock.
Popped the drive back into my laptop, closed it up, hit the power button, and got the same error, unable to start up due to a problem with hal.dll. Come on, HAL, just open those pod bay doors for me, would you?
Now granted, on a typical system, you would be finished here. The problem at this point ended up being that I had a "hidden" recovery partition that Sony likes to make on some systems. My gf's computer apparently doesn't have one, so she only has one partition, whereas I have two. Because of this, I had to bump the numbers for partition identification up to 2 instead of 1. Like this:
[operating systems]multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="Microsoft Windows XP Professional"
[operating systems]multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional"
It's a teeny tiny thing, but makes all the difference. This time when I fired it up, everything worked. Now that I had access to Windows and Anti-Malware again, I wanted to see what was so damn special about the previous boot.ini that it got flagged and created this whole mess to begin with.
I restored it to the original location, renamed it (just in case, so it wouldn't boot with the questionable file in case there really was something wrong with it), and opened it up in Sandboxie (again, can't be too careful). Instead of having legible command lines in plain English, it was the sort of thing you expect when you open a compiled file, all sorts of random characters, spaces, and other gibberish that makes no sense to the average human, but computers understand.
I don't know if this happened prior to the Anti-Malware scan (or more importantly, how it would have happened) or during the quarantining process, but I figured if it was bad once, it should be bad again, right? So I right-clicked the file, ran Anti-Malware specifically on it, and it came back with "No Malicious Items Found." Um, okay. So I scanned the entire computer again with the same result, no malicious items found. Weird.
I still don't know what that was all about, but I deleted the "suspect" file anyway since I'd built a working one in its stead. I still trust MBAM, though its flawless armor now has a chink in it. It's simply one more example of how even the best security software isn't perfect. Heck, if I didn't know how to repair the damage, MBAM could have effectively done more harm to my system than many of the threats it's designed to protect against.
How's that for a healthy dose of irony?Powered by Sidelines