RADAI1@HBUNOS.BITNET (Y. Radai) (11/22/89)
Last month I wrote that whereas the original DataCrime virus per-
forms its damage from Oct 13 to Dec 31, DataCrime II does it from Jan
1 to Oct 12. David Chess and Alan Solomon both replied that in their
copies of DC II, the dates were the same as for DC I: Oct 13 - Dec 31.
That left two possibilities: either there's a mutation with the date
range modified, or my sources were mistaken.
One source for the Jan 1 - Oct 12 range was the July/August issue of
the Computer Security Newsletter. I did not at the time accept this
as necessarily correct. But when I saw a similar statement in the Sep
issue of the Virus Bulletin by Joe Hirst, who does independent disas-
semblies and who always seemed very accurate and reliable in the past,
I became convinced that this was correct.
After the differences of opinion, however, Joe admitted that he had
been mistaken and that the date range for DC II was the same as for DC
I even on his copy. Since there apparently haven't been any further
claims for the pre-Oct 12 dates, I tend to believe that the CSN was
also mistaken. Of course, one *could* easily modify DC II to activate
on Jan 1 - Oct 12 (or on any other date range), but it makes more
sense for the infection period to be long than for the damage period
to be long.
Joe also wrote originally that Sundays are excluded from damage by
DC II. This also turned out to be incorrect, although in this case
the correct behavior is different than for DC I: Mondays are excluded.
Following is the relevant part of the code for each virus (I have
translated the disassembly into a pseudo high-level language; the
variable Hdflag contains 0 if there is no hard disk, 1 if there is):
DataCrime I
If current date > Oct 12 then go to Hard-disk test;
Go to Infection routine;
Hard-disk test:
If Hdflag not 0 then go to Damage routine;
DataCrime II
If current date > Oct 12 then go to Day-of-week test;
Go to infection routine;
Day-of-week test:
If day-of-week (0 for Sunday, 1 for Monday, etc.) not = Hdflag
then go to Hard-disk test;
Go to Infection routine;
Hard-disk test:
If Hdflag not 0 then go to Damage routine;
Thus in DC II the damage will be performed only if there is a hard
disk and the date is after Oct 12 *and the day is not a Monday*.
To summarize, there are (at least) six differences between DC I and
DC II:
DataCrime I DataCrime II
Type of files infected: COM COM/EXE
Size increase: 1168 or 1280 1514
Days excluded from damage: None Mondays
Encrypted? No Yes
Files excluded from infection: 7th letter = D 2nd letter = B
Message: DATACRIME VIRUS DATACRIME II VIRUS
So much for corrections. Now for some new info on these viruses.
Both of them contain code which low-level formats Track 0 on all heads
from 0 to 8. The pseudo-code looks like this:
H := 0;
Loop:
Format Track 0, Head H;
If error go to Continue;
H := H+1;
If H not = 9 then go to Loop;
Continue:
But what happens in the case of disks having less than 9 heads? Pre-
viously, it was assumed by many that this would result in an error, so
that the extra heads would be ignored, i.e. the virus would format
only Cylinder 0. But Joe has discovered by experimentation that in
most cases the number of tracks formatted is actually 9, even if this
goes beyond Cylinder 0. The explanation is that most BIOSes convert
an invalid head number into the valid equivalent. On a 17-sector/track
disk, this will wipe out 153 sectors, which on most hard disks contain
the partition record, boot sector, both copies of the FAT, the root
directory, and possibly some files.
Fridrik Skulason reported in Virus-L that he was able to recover
from an attack of DC II by using the Norton Disk Doctor. This might
seem to contradict the above findings. However, he rebooted before
the virus had a chance to format very much of the disk. It seems
likely that if he had not done this, all of Norton's horses wouldn't
have been able to put his disk together again.
There is a package available from Simtel20, called COLUMBUS, which
is supposed to be of use against the "Columbus Day" [i.e. DC] virus.
It consists of two simple programs, ST0 and RT0. ST0 saves the con-
tent of a certain portion of the hard disk on a diskette file, and RT0
restores it in case of damage by the virus. Just which portion is
saved is not very clear from the documentation. In one place it says
"Track 0", while in another place it says "cylinder zero". Experiment
shows that ST0 saves Track 0 on Head 0 only, which is of little use
against the DC viruses. A look at the source code shows that the
author left the possibility of saving all of Cylinder 0 by defining a
certain symbol at compile time, but as we now know, even that isn't
enough. However, the source code can presumably be modified to save
all 9 tracks damaged by a DC virus by simply replacing "maxhead=0" by
"maxhead=8" in both ST0.C and RT0.C.
Joe Hirst has written a small resident program to prevent damage by
the DC viruses, or more generally, to halt any program which attempts
to low-level format any part of a hard disk by a call to Int 13h func-
tions 5-7. It (along with the above clarifications on the extent and
dates of the damage) appears in the Nov issue of the Virus Bulletin.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
RADAI1@HBUNOS.BITNET