I've been doing more investigation on the corrupted files. (I have CD backup copies of some of my affected files, so I can compare the two and see what has changed.) Below is a technical summary of what I've found so far, which is being provided in the hopes that others working on the problem may find it useful. If you are only looking for the solution, please be aware that I haven't figured it out.

First off, note that simply changing the file names back to *.doc, *.xls, *.jpg, etc. does not work. Nor does copying them to different places. The files have been modified by this virus, which uses some sort of scrambling algorithm.

It appears that identical copies of the corrupted files were stored in both the \CDD and \FLR directories. As mentioned above, the source files have been scrambled with an algorithm that I cannot decipher at this time. An ASCII path & file name were inserted at the beginning of the resulting .fcd file. The ASCII string identifies where the source file came from.

I used a hex editor to determine the following:

There is a hex 00 byte that marks the end of the ASCII string. When I delete the ASCII string and the hex 00 byte at the beginning of the file, the known good file and the corrupted file have the same exact file length. So I don't believe any other data was added to the corrupted .fcd file.

The algorithm used to scramble the data appears to operate on 64-bit (8 byte) values at a time. It generates repeatable results every 64 bits for long strings of the same input value. The results of the algorithm also do not appear to change from one file to the next, so it does NOT look like a separate key value was used to seed the algorithm differently for each file. That's a little good news. Hopefully the results are also repeatable from one computer to the next, but I do not have any way to determine that myself (only one of my computers was affected).

Here are 4 examples of how the algorithm modifies the file data, 8 bytes at a time:

Source data (in hex) Resulting data (in hex)
00 00 00 00 00 00 00 00 CB A7 BE 9E 85 3E DA 3E
00 00 00 00 01 00 00 00 A9 A4 6B 8D 68 D6 C0 07
00 00 00 10 00 00 00 00 D8 5B 98 00 BF F7 95 83
FF FF FF FF FF FF FF FF CC B0 A4 B9 E3 28 DE 73

As mentioned above, if the 8 byte input value repeats, the resulting data repeats as well. So, taking the first example, for every set of 8 consecutive all-zero bytes aligned on a 64-bit boundary, the resulting data is always CB A7 ... This is good news, from the standpoint that there is not some continuous random number seed that percolates through the entire file.

That said, the algorithm is complicated enough to produce wildly different data when even a single bit is changed in the source data. If you look at the difference between the first two lines in the examples above, only one bit differentiates the first and second source data values. Yet the resulting data from the algorithm is quite different between the two. The same is true if you compare the first and third lines.

The scrambling algorithm is more complicated than a simple XOR. I've also looked at some LFSR implementations a little (which are commonly used for scrambling purposes), but have not found anything that explains the behavior yet.

It's not clear that I'll ever figure this out, but I'll keep plugging away at it. I can provide more examples of how the input data gets modified if that would help anybody else to decipher the algorithm. If somebody can figure that out, restoring these files would require an application program, but it would be pretty simple to implement. Good luck all.