Reading the reports of trouble over on the "alt.comp.virus" newsgroup and in the industry press makes it clear that hundreds of thousands of people have been hurt by this malicious virus. I think we can help them.

Wednesday, 4/28 -- The Decision is Made

I don't have time for another project, but what choice do I have? Too much data has been lost around the world, and it's too recoverable for us not to help everyone. Also, one strain of this nightmare virus triggers on the 26th of every month, and another strain is still holding out and waiting for June 26th. So creating a new piece of powerful data recovery freeware will not only help everyone now, but will have enduring value.

No choice, gotta do it.

At 10:45 pm I receive the first drive that's been destroyed by CIH.

Thursday, 4/29 -- First Contact

I'm committed to the freeware development project, I create the source files for the new software, and begin poking around within this first nuked drive.

Friday, 4/30 at 6:15pm -- First Successful Total Recovery!

YES! In order to design robust heuristics (rules of thumb) for the automatic reconstruction of CIH-destroyed drives, I first manually reconstructed a drive provided to me yesterday. As hoped, 100% the drive's data was successfully recovered and the drive has been restored to full health.

Now I begin the process of encoding those heuristic procedures into robust commercial-grade code so that the resulting program can be used by anyone, anywhere to perform the same recovery . . . automatically.

Saturday, 5/1 -- Quickly Recovered a Second Destroyed Drive and Began Work on the Fix-CIH Utility

Federal Express delivered a second CIH-destroyed drive to my front door Saturday morning, so using what I learned from Friday, I applied the "heuristics" I had developed so far and brought the second drive back to life within minutes. Cool.

Then I began getting ready to write a 16-bit DOS application under NT. I'd forgotten what a pain it is to do low-level 16-bit code development. Since NT doesn't have DOS underneath it (the way Windows 95/98 still really does), I write and assemble the code under NT, but all testing needs to be done on a separate machine under DOS. So I setup DOS TCP/IP networking to tie two machines together and dusted off my trusty old 16-bit DOS debugger, Periscope.

All that's done now and I've created my assembly language source code files and started coding the new app.

Sunday, 5/2 -- A Quiet Day of Coding

I still haven't figured out what I'm going to call this thing (any suggestions?) but in thinking about this problem (coming along after something bad has happened and rebuilding everything) I've again been reminded that the world really needs a truly competent and sophisticated file system structure rebuilding and recovery utility. I've thought about writing one for years, but other things always seemed more important. There are a bunch of programs that claim to do this sort of thing (Norton Disk Doctor, Hard Drive Mechanic, Tiramisu, Lost & Found, etc.) but they're pretty much for suckers (I would never let any of those things touch my hard drive) since they don't do as good a job as they could and they claim to do things that are impossible. (That's what worries and disappoints me.)

It's very possible, but not easy, to do a really excellent job, and no one has done it yet. (Otherwise there wouldn't be so many people trying.) So, as you can see if you read the screen below, I've realized that this Fix-CIH freeware will just be the "precursor" to a really cool new drive recovery capability:

But first things first. I'll get CIHFIXER.EXE finished, we'll get everyone's CIH-destroyed data recovered . . . then take it from there.

Monday 5/3 and Tuesday 5/4 -- VERY Good Progress

As you can see from the screen shot below, the program is coming along nicely:

You can get a sense for the procedure required for deterministic CIH recovery and partition reconstruction by looking down the list of work under the "Drive Reconstruction Progress" heading.

(I'm working on the heuristic/hierarchical root directory search system right now -- which turns out to be rather tricky for fully reliable and robust FAT32 boot sector reconstruction -- which is why that's as far as the list has been checked off, and the details on the lower right for that are nonsense.)

Monday 5/10 -- Nearly There

It's one thing to write a program that will fix one drive on one computer in one configuration ... but it's much more time consuming to write a program that is "smart" enough to fix any drive on any computer in any configuration. (And to do tricky — but quite necessary — things such as interacting with the user when it senses things like the current BIOS parameters being different from what they were originally.) But that's what I've been doing, and that's where my time has been spent. I've accounted for all variations in BIOS features, large drive support, misreported drive sizes, various cylinder/head/sector translations, and literally everything I've encountered during my experience of SpinRite's twelve year existence.

I will first release a version that will only recover a single, first, FAT32 partition on a drive. Since most FAT32 formatted drives are all one huge partition, this will solve most people's needs, and I can have it ready sooner so people won't need to wait as long.

Then, shortly afterward, I'll release an enhanced version which will explore beyond the first recovered partition to restore additional partitions.

Tuesday 5/11 -- Looks Like I'll Finish Today or Tomorrow

I'm working on the final partition-sizing heuristics, and then on the root directory finder. When those are in place, it's all done:

Without either a partition table or a boot sector, determining the exact original size of the partition is tricky when the size of the drive doesn't make it obvious. We only have the size of the second FAT table to base our decision upon, and since we can't know how many of the entries in the FAT's last sector were in use, this creates some uncertainty in the determination of the final partition size. But I've come up with some nice heuristics which will do the right thing in every instance.

Tracking down the location of a FAT32 root directory will then be the final requirement. On FAT16 partitions the root directory is a fixed-size block immediately following the second copy of the FAT. But on a FAT32 partition the root is treated like any other file. The boot sector of a FAT32 system tells the system where the root starts ... but, of course, the CIH virus completely wipes out the boot sector. So the root needs to be found out on the drive.

Tuesday 5/11 -- Something for YOU to Play With!

Work today went much more slowly than I'd hoped, and I only managed to get the partition-sizing heuristics completed, though I think they'll be very robust, since they are very good at identifying lost partitions beyond the first, which allows us to nail down the end of the first.

Since I KNOW how anxious everyone is to get their hands on this utility, I decided to let you play with a "read-only" version which collects all of the data for the reconstruction of the first partition, but does NOTHING whatsoever to any drives at any time.

The program is loaded with safety measures and "early-outs" which prevent it from ever modifying anything unless it's VERY sure about what's going on. So I'd be interested in knowing whether anyone hits any of those right now during its analysis of the CIH viral damage. I'd also love to know how many "Damaged Sectors" it reports when you run it on your CIH destroyed drives.

Wednesday I'll write the final piece of code ... the infamous root directory finder ... and then we'll have the first working CIH recovery utility for you!

And thanks for your patience ... I'm working on this for you as hard and rapidly as humanly possible ... while (as you'll see in the 14k result above) refusing to sacrifice anything in the way of operational quality.

Wednesday 5/12 (morning) -- Some Initial Feedback Tweaks

When I awoke, a number of people had already written to mention that FIX-CIH was refusing to help them, since it detected an apparently healthy partition table. These people HAD used FDISK after the CIH attack in an initial attempt to repair their drives.

So I quickly added the ability to FORCE FIX-CIH past this if the user knows why the partition table (MBR) is apparently okay, and is willing to assume responsibility for discarding its contents.

I also added a pop-up note at the end of the work since it was not clear to many people that the work was already completed (it flies by pretty quickly).

So now I write a robust root directory finder ...

Wednesday 5/12 (end of night) -- Wow! A Day of Feedback Tweaks

A whole bunch of you downloaded FIX-CIH.EXE and gave it a whirl.

As a result I spent nearly the entire day corresponding with early testers and tweaking the rapidly evolving program. I generated about ten updates during the day, and as a result it's way better than it was this morning:

The 'FAT Finder' was being fooled when the front of the lost partition didn't have many files in it since it was confirming its hunch about the FAT's starting point by looking for cluster linkages. So I made the 'Fat Finder' much smarter and it is now finding FATs that it couldn't find this morning.

One guy was SURE that he had a 32-bit FAT system, but FIX-CIH just wasn't finding it. So I added a COOL new ability for it to determine the size of a lost partition's clusters even if it's unable to locate any of the FATs! It turned out that this guy had 32k clusters (oops!) and thus a 16-bit FAT. But what's cool now is that if people aren't sure whether they had a 16 or 32 bit format, FIX-CIH will tell them for sure!

There's still one mystery that's unsolved where FIX-CIH isn't locating the second FAT on a partition that was formatted by Partition Magic, and had been touched by "Lost & Found" after the CIH disaster. But the drive's owner is pretty sharp and said that "Lost & Found" didn't modify anything. In cases like this, I can't think of anything to do but for me to see the guy's partition data . . . So I've just added a bunch of command-line switches to FIX-CIH which allows a drive's physical contents to be quickly written out to a file on another drive. The file can then be zipped and eMailed to me for immediate analysis. That way I ought to be able to diagnose ANY weird FIX-CIH behavior by eMail!

With all that happened today (though it was all very necessary if FIX-CIH is going to be useful to everyone) I only just got started on the coding of the root directory locator (thought the algorithms are all set).

I'll nail it Thursday FOR SURE!

Thursday 5/13 (Friday, 3:30 am) -- Fine Tuning on Many Systems . . .

The bad news is, I'm moving more slowly than I had hoped (and than I know all of you have been hoping), but the good news is . . . when this tool is ready it's going to be much more mature, stable, and well-tested than I'd expected.

MANY people have been downloading the "read-only" work-in-progress FIX-CIH.EXE running it on their machines, and telling me about their results. It turned out that PowerQuest's Partition Magic doesn't format FAT32 partitions the way that Microsoft does, sigh, and my FAT Finder was still not finding some FATs on highly fragmented drives or drives with few files near the front of the drive. (It's AMAZING what's out there!)

So I re-designed the FAT Finder a third time and finally resolved all of the "FAT not found" problems that it had encountered.

So, while I wish it was already completed ... and I'm working on nothing else all day and night ... when it is ready I have a very good feeling about how safe it will be and how well it will work for you. (And whenever it DOESN'T work, you and I will correspond by eMail, figure out why ... and fix it for you!)

Friday 5/14 (start of day's work) -- Another New Wrinkle . . .

Early this morning, at about 4:30am as I was winding down the day's work, I hit a built-in error from FIX-CIH that two other people out in the field had reported. (FIX-CIH is careful in the extreme. It performs all sorts of "sanity checks" and will refuse to touch your drive unless it's very sure about what it has found and what it is doing.) So I knew what the error was (it was one of my own messages popping up) but I had never experienced it happening.

But, since it happened to me I was able to track it down . . . and a nightmare I had not considered presented itself! FIX-CIH was picking up and detecting remnants of PREVIOUS instances of a file system on the drive! The good news is that even though I'd failed to consider that possibility, my "sanity checks" would not allow FIX-CIH to proceed since it knew that something was wrong, but it wasn't smart enough to know what. So I went to sleep with another puzzle to solve: How to separate the most recent aspects of a file system from old ones which were left over and were part of a previous (now completely invalid) file system.

Well, it's morning (just barely) and I have the answer. I also made very good headway on the root directory finder yesterday, though, as typical lately, not as much progress as I was hoping to make since I'm simultaneously maintaining many dialogs with people all over the world who are running FIX-CIH and reporting on its behavior. I need to be so very careful with self-validation code so that FIX-CIH won't ever make things worse or damage what's there. I know that it will pay off in the program's robustness and usefulness.

You should know that I've also run afoul of several instances of Phoenix BIOSes out in the field which seem to be misbehaving badly — but it's also likely that there's just something I don't understand about them since they seem to be okay for DOS. I can't stop to track that down just now, so the FIX-CIH solution, for some people with a Phoenix BIOS, may take another day after everyone else has it running and their drives have been reconstructed.

Thanks for everyone's support, feedback, and patience. I'm working as hard and fast as humanly possible.

Friday 5/14 (just past noon) -- Prior FileSystem Awareness Works!

Just a quick follow-up to the morning's posting. I implemented the "prior filesystem awareness technology" and it worked right off the bat, causing FIX-CIH to ignore fragments of the past that didn't make any sense. This allowed it to keep looking for those that do make sense, until it has enough evidence to proceed with full safety.

Now back to the root directory finder ...

Friday 5/14 (evening)  –

Unfortunately for many weeks prior to the CIH Attack, I have had plans to be out of town this weekend from tonight until Sunday night, so I have no more time until I return to verify FIX-CIH's operation . . . and I must carefully watch it run through a few more drives (which have been sent to me by CIH victims) before I'm confident enough to let it loose on the world.

But I will be back to it the moment I return in two days, Sunday night, and I'll have it available for EVERYONE to use on MONDAY!

IN THE MEANTIME . . . You can try the version that's now on our FTP server at https://www.grc.com/files/fix-cih.exe which performs ALL of the analysis but is COMPLETELY SAFE TO USE since it stops before modifying anything and will then ONLY exit to DOS.

If this version runs all the way through until it tells you it's got everything, you can be CERTAIN that it will work on your CIH-damaged drive(s) on Monday! (And if it doesn't, let me know and after the initial release of FIX-CIH for everyone else, I WILL work with you one-on-one to figure out what's happening and get it running for you and all your data recovered!)

Monday 5/17 (mid-morning) -- Status Update:

Hi everyone! I'm back from my trip and found a flood of eMail waiting for me. I'm posting this here, rather than attempting to reply to every individual eMail, since doing so would take too much time away from the FIRST RELEASE of FIX-CIH.

What I want you ALL to know is that I'm EXTREMELY INTERESTED in understanding every instance where FIX-CIH refuses to proceed on your systems and that I will work with everyone who is experiencing that behavior until we get it figured out fixed. Okay? Really. In other words, it's very clear to me that the first release of FIX-CIH will not be the last, however, I need to get it released, first, as is, so that the majority of people for whom it already works, will be able to reconstruct their drives.

Here's just a few of the typical "success" notes I received over the weekend:

So, I wanted those of you who have never seen that final "success" screen in FIX-CIH to know that I WILL be back in touch with each of you shortly after I've released the first version which will work for everyone else.

We'll figure out what's going on with your systems and we'll get ALL of your data recovered!

Monday 5/17 (late night) -- It's Lookin' VERY Good!

I spent the better portion of the day recovering CIH blasted drives with the FIX-CIH utility.

As a result of its contact with so many drives today, I found a few minor bugs that I quickly knocked out. But I also hit upon one bug in the root directory finder that I have not yet tracked down. I wanted to get all these drives back to all of the people who took the time to send them in, and who have been waiting so patiently. So that had to be my top priority today.

I made an "image" of that one drive that confused FIX-CIH so that I could complete its recovery by hand then get it back to its owner. Then Tuesday, with all of the destroyed drive backlog cured by FIX-CIH, I'll nail this last glitch in the root directory finder . . . and post a sufficiently mature release of the program for everyone to use.

Tuesday 5/18 (evening) -- The final bug ?

I found the problem with my root directory finder. I had forgotten to take deleted files into account when scanning clusters to determine whether they might be directories of the file system. Since I start out not knowing anything about the file system, I can't know which clusters are directories and which aren't. So, I use a process of disqualifying clusters for directory status as I scan through the entire partition space.

One of the principal means of disqualifying a cluster as a directory is whether absolutely ALL of the file name entries in the cluster are legal. But I failed to take deleted filenames into account! When a file is deleted the first character of the name is replaced with a hex E5 character. But since this is an illegal character I was immediately discarding the entire cluster as not possibly being a directory. Oops. I'm working to fix that now.

I should also mention that while tracking this down I did notice a few other things that weren't working right, so the day was useful for more than just this one problem.

Oh! And during yesterday's amost-automated recovery of all of the drives I'd been sent, and also from my dialogs with many of you, I realized that people will often have moved a blasted drive from a "dead" computer into another computer where the recovery will take place. But since the boot sector needs knowledge of the "BIOS number" of the drive, it will be necessary for me to add one additional screen to FIX-CIH which will let you specify the "operating destination" of the reconstructed drive so that you can specify where the drive will be operating after its recovery is complete and it's returned to its home.

I'm continuing to work on this with my full time and attention, fully aware of how much you all want to have the final product for the repair of your drives.

I will not let you down . . . but it does need to be right.

(The truth is, it really does now seem to be working perfectly . . . but I want a few more hours in the morning to add the final features.)

Wednesday 5/19 (afternoon) -- FIRST RELEASE POSTED ! !

Please see the new FIX-CIH Download and Version History page for details about this specific release.

PLEASE LET ME KNOW if this doesn't work for you so that I can find and fix the problem!

Thanks for your support, and please spread the word so that as many people as possible can be helped!