PC virus listing from Jim Goodwin
NOTICE: TO ALL CONCERNED Certain text files and messages contained on this site deal with activities and devices which would be in violation of various Federal, State, and local laws if actually carried out or constructed. The webmasters of this site do not advocate the breaking of any law. Our text files and message bases are for informational purposes only. We recommend that you contact your local law enforcement officials before undertaking any project based upon any information obtained from this or any other web site. We do not guarantee that any of the information contained on this system is correct, workable, or factual. We are not responsible for, nor do we assume any liability for, damages resulting from the use of any information on this site.
PC VIRUS LISTING
by Jim Goodwin
[edited without permission by Dave Ferbrache]
It is difficult to name, identify and classify PC viruses.
Everyone who first discovers a virus will name it and describe
what they think of it. In most cases, the virus is not new and
has been named and described dozens of times before. None of the
names and few of the descriptions will match. While I'm writing
this, for example, I feel certain that someone, somewhere has
just been infected by the Jerusalem virus and they are telling
their co-workers and friends about it as if it were newborn - and
for them perhaps it is. It will be impossible to verify the
strain and variety of the infection, however, unless we can get a
living sample of the virus to analyze and compare with other
strains of this same virus. So problem number one is filtering
the reports of infection and collecting samples that can be
placed under the knife.
Problem number two is - where do you draw the line between
an original virus and a true variation of the virus. The
original Brain virus, for example, could only infect a floppy
diskette. Do the varieties of the Brain that can infect hard
disks (but in every other respect are identical) deserve to be
called new viruses, or are they still the Brain? What about
further modifications that destroy data? Is this now a new
virus? What if nothing changes but the imbedded text data, so
that the virus is in every way functionally identical, but the
volume label changes to "SMURF" instead of BRAIN. All of these
modifications to the Brain have been discovered and logged. How
do we deal with them?
I choose to deal with these modifications in the simplest
way I know. If the virus differs in any way from the original
(assuming that the "original" can in fact be identified), then I
log it as a new virus. This relieves me from having to make
decisions. Those of you who see the world differently can merely
take this listing and lump together all of the different strains
that you like. That way we'll all be happy.
[have done Jim, it does seem simpler to me and allows tracing of the
evolution of viruses. I personally think an edited text string does
not constitute a new virus, although I agree the line is often hard to
This will be, by the way, my last virus document. I have
worked double time for the past eighteen months helping John
McAfee and his Homebase folks and, while I have thouroughly
enjoyed myself, I have finally burned out. It has been great fun
and I've learned a lot, and hopefully some of my works, like the
product review with Sankary and Marsh, will end up being somehow
useful to the world. But now I have the irresistible urge to go
fishing, and, perhaps afterwards, to contemplate my navel for a
few years. In-between times I intend to write a book on the
craziness in this industry and about the unique personalities
I've had the pleasure to work with in the Virus Marine Corps.
It's been quite an adventure. Thank you all.
I have arranged these viruses so that similar varieties are
described in the sequence in which they appeared within the virus
sub-group (to the best of my knowledge). Not everyone agrees
with my groupings. Many people believe, for instance, that the
Golden Gate-C (Mazatlan Virus) is a distinctly original virus and
is not a variation of the Alameda. I think differently and have
endeavored to show how the Golden Gate evolved from the Alameda,
through each precursor virus. I cannot prove, of course, that
the sequence of appearances is the correct sequence, and in many
cases I have had to guess. If you anyone wishes to re-order
these virus, I will not be offended.
I have not included any of the specific application trojans
in this list. There has been a lot of discussion about the Lotus
123 and DBASE "viruses", for example. These are not replicating
programs and I do not classify them as viruses. I had originally
intended a separate list to include these non-replicating trojans
but Time caught up with me.
[BOOT SECTOR AND PARTITION RECORD VIRUSES]
[ALAMEDA VIRUS AND VARIANTS]
(Also called: Yale; Merritt; Pecking; Seoul)
First discovered at Merritt college in California (1987).
Original version caused no intentional damage.
replicates at boot time <ctrl>-<alt>-<del> and infects only
5 1/4" 360KB floppies. It saves the real boot sector at track 39,
sector 8, head 0. Contains a count of the number of times it has
infected other diskettes, although it is referenced for write only and is
not used as part of an activation algorithm. The virus
remains resident at all times after it is booted, even if no
floppy is booted and BASIC is loaded. Contains a rare POP
CS instruction that makes it incapable of infecting 286
ALAMEDA-B (Also called Sacramento Virus)
This is the original Alameda Virus that has the POP CS
removed. Relocation is accomplished through a long jump
instruction. All other characteristics are identical. This
version runs OK on a 286.
This is the Alameda-B virus that has been modified to
disable the boot function after 100 infections. The
counter in the original Alameda virus has been re-activated
and is interrogated at each bootup. When it reaches 100 the
virus disconnects from the original boot sector (control is
no longer passed) and the diskette will no longer boot. At
infection time, the counter is zeroed on the host diskette.
This is the Alameda-C that has been modified to format the
boot diskette when the counter runs out.
GOLDEN GATE VIRUS (Also called The 500 Virus)
This is the SF Virus that has been modified to format the C
drive when the counter runs out. The activation occurs
after 500 infections, instead of 100 infections. Note that
in all three of these strains, the counter is zeroed on the
host diskette at infection time. Thus, the activation
period on this virus will on the average stretch into many
years. No corruption will occur until 500 new diskettes
have been infected from within a given machine. Since the
infection can only occur when the system is booted with a
new diskette, infection is not frequent with this virus. I
expect that the overwhelming majority of infections will
never activate. The IBM PC will have long since been
supplanted by another architecture in most environments.
This virus is the Golden Gate virus that has had the
activation delay reset to 30 infections. This virus should
activate within a couple of years in most environments.
GOLDEN GATE-C (Also called the Mazatlan Virus)
This virus is the Golden Gate virus that is able to infect a
hard disk. It is a nasty virus, since it has more of an
opportunity to do damage than previous versions. Prior
versions were limited since systems with hard disks are only
infrequently booted from floppy and booting from hard disk
overwrote earlier versions.
This virus is identical to number 7, except the counter has
been disabled (similar to original Alameda).
[BRAIN VIRUS AND VARIANTS]
(Also called, Pakistani Brain; Basit Virus)
This virus originated in January, 1986, in Lahore Pakistan.
It is the only virus yet discovered that includes the valid
names address and phone numbers of the original
perpetrators. The Brain is a boot sector infector,
approximately 3K in length, that infects 5 1/4" floppies.
It cannot infect hard disks. It will infect a diskette
whenever the diskette is referenced. For example, a
Directory command, executing a program from the diskette,
copying a file from or to the diskette or any other access
will cause the infection to occur. The virus stores the
original boot sector, and six extension sectors, containing
the main body of the virus, in available sectors which are
then flagged as bad sectors.
The virus is able to hide from detection by intercepting any
interrupt that might interrogate the boot sector and re-
directing the read to the original boot sector. Thus,
programs like the Norton Utilities will be unable to see the
Infected diskettes are noticeable by "@BRAIN" displayed in
the volume label.
BRAIN-B (Also called Brain-HD; the Hard Disk Brain; Houston Virus)
This virus is identical in every respect to the original
Brain, with the single exception that it can infect the C
This virus is the Brain-B that has the volume label code
removed. The volume label of infected diskettes does not
change with this virus. This virus was difficult to detect
since it does nothing overt in the system.
This virus is the Brain-C that saves the original boot
copyright label and restores it to the infected boot. The
Basit & [A]mjad original Brain messages have been replaced with
non-printable garbage that looks like instructions if viewed
through Norton or other utility. Even if the system is
booted from a clean diskette, it is virtually impossible to
tell, by visual inspection, whether the hard disk is
SHOE_VIRUS (Also called UIUC Virus)
This virus is the Brain-B Virus that has been modified to
include the message - "VIRUS_SHOE RECORD, v9.0. Dedicated
to the dynamic memories of millions of virus who are no
longer with us today". The message is never displayed.
[I would also tentively identify this with the ashar virus as we
have a VIRUS_SHOES RECORD v9.0 with the identifying string ashar at
This is the Shoe_Virus that has been modified to so that it
can no longer infect hard disks. The v9.0 has been changed to
[Have to question this we have a version of Brain with VIRUS_SHOE
RECORD v9.0 which is incapable of activating a virus stored on hard
disk due to the drive number being hardwired into the read routine
for loading the virus. I suspect v9.1 may be the hard disk variant.]
This is the Clone virus that has been modified to corrupt
the FAT when it is booted after May 5, 1992. There are no
other apparent modifications.
[This virus is the Shoe virus with the identifying text at
offset 0010hex reduced to "Welcome to the Dungeon © 1986 Brain", with
the text at 0202hex reading "© 1986 Jork & Amjads (pvt) Ltd".]
[TERSE SHOE VIRUS]
[A variant of Shoe virus with the initial text message truncated to
a single line]
[ITALIAN VIRUS AND VARIANTS]
(Also Called Bouncing Ball; Vera cruz)
This is a boot sector virus that was first reported in March
1988. It is a floppy-only infector.
When this virus activates (randomly) a bouncing dot appears
on the screen and can only be removed through reboot. No
other damage is done.
This is a variation of Italian that is able to infect
[Obviously they have been spared this virus which I find suprising, this
does not seem to be based on first hand evidence]
[NEW ZEALAND AND VARIANTS]
(Also called Stoned Virus)
This is a boot sector infector that infects 360 KB 5 1/4"
floppies. It was first reported in Wellington, New Zealand
in early 1988). It displays - "Your computer is now stoned.
Legalize Marijuana" every 8th bootup. No overt damage.
Unable to infect hard disk.
Variation of New Zealand. Has been changed to be able to infect
hard disks. The hard disk is infected as soon as an
infected floppy is booted. No intentional damage done,
except systems with RLL controllers will frequently hang.
This is the Stoned-B virus that no longer displays the
"Stoned" message. This virus is difficult to detect.
[SEARCH AND VARIANTS]
(Also called Den Zuk; Venezuelan)
This is a boot sector infector that infects 360KB 5 1/4"
floppies. It infects through any access to the host
diskette. It can survive a warm reboot. It will infect
data (non-system) diskettes, which in turn can pass on the
infection if an accidental attempt to boot from the data
disk occurs. It has a bug which causes it incorrectly
attempt to infect 3.5" diskettes. This will overwrite the
diskette's FAT and cause a read (or write) failure. It
cannot infect a hard disk, and will not attempt to do so.
If an infected system is rebooted from the hard disk, the
virus will de-activate. This is not the case with rebooting
from a clean floppy - which will become infected.
The virus causes CGA, EGA and VGA screens to display a
purple "DEN ZUK" graphic to appear after a <ctrl>-<alt>-
<del>. It causes no damage.
This virus is identical to the Search Virus, except it's
able to infect hard disks.
This virus is identical to the Search virus, but
unsuccessful modifications have been made to fix the 3.5"
diskette problem. The 3.5" infection still fails, plus
unsuccessful attempts to infect the hard disk will occur
which result in system failure in some systems.
This virus is really a modification of the Search-HD virus.
The display code has been replaced (no display occurs on
reboot) by code that disables the SYS program. The SYS
program itself is not modified, but any attempt to execute
SYS will result in the program not being loaded. Instead,
multiple reads to the source and target drives will occur
(to simulate the SYS activity). The normal SYS message
output is displayed by the virus at the appropriate time.
This virus will successfully avoid being removed by SYS.
The virus does no damage.
This is similar to the SYS virus, but it performs a hard
disk format on any Friday 13th after 1990. This virus, and
its precursor virus both still contain the 3.5" bug, so that
they are easily detected on systems using 3.5" drives. They
are difficult to detect on other systems.
Similar to the SYS virus but performs random reboots
beginning 2 hours after power-on or initial boot.
This is a COMMAND.COM infector that first surfaced at Lehigh
University in late 1987. It is the widest known virus, the
most discussed and the most analyzed of all the viruses, so
I won't waste any more time on it.
[A pity since there is now a further variant]
[A version of the Lehigh virus modified to retain its infection
counter in RAM, and to only trigger the destructive phase when the
counter reaches 10 infections the disk FAT table is nulled]
[TRANSIENT OBJECT FILE VIRUSES]
[DOS-62 AND VARIANTS]
(Also called the UNESCO Virus)
This virus is a COM infector. It was first discovered in
Moscow in April, 1988. It was first publicized in August
1988 when it cropped up at a children's computer Summer camp
run by UNESCO. When a program infected by this virus is
executed, it infects one other COM file in the system. On a
random basis, infected programs will perform a system re-
boot when they are executed.
This virus is similar to DOS-62 except the re-boot is
replaced by deleting the executed program.
[FRIDAY THE 13th]
[Here lies a problem, this virus is totally different from the Israeli
Friday 13th strain, for one thing it is transient in that it does not
hook interrupts and remain active in memory]
(Also called COM Virus; 512 virus)
This virus is a non-resident COM infector that first
appeared in South Africa in 1987. At each execution of an
infected program the virus seeks out two other COM files on
the C drive and one COM file on the A drive and infects
them. The virus is extremely fast and the only indication
of infection occurring is the access light on the A drive
(if the current drive is C). The virus will only infect a
On every Friday 13 the virus deletes the host program if it
is executed on that day (similar to the Jerusalem).
This virus is identical to the original except that it
infects every file in the current subdirectory. The only
way this virus can spread beyond the current subdirectory is
if an infected program ends up in the system PATH. Then
every COM file in the currently selected subdirectory will
This is the 13th-B except a message has been added that
displays - "We hope we haven't inconvenienced you" appears
whenever the virus activates.
[AUSTRIAN VIRUS AND VARIANTS]
(Also called the 648 Virus)
This is a COM infector that increases the size of the
infected file by 648 bytes. It was first reported in London
in the fall of 1988. It is not a memory resident virus. It
infects the next uninfected COM file in the current
directory (similar to the original Friday 13th). It does no
This is similar to the original, but it causes infrequent errors
in the infected COM file so that the file will not execute.
Approximately one file in ten will be corrupted.
[A .COM infecting overwritting virus, similar to the Virus 1.1 published
in Ralf Burger's book. Infected files are destroyed and replaced by the
405 byte long virus code.]
[RESIDENT OBJECT FILE VIRUSES]
[JERUSALEM VIRUS AND VARIANTS]
(Also called Israeli; Friday the 13th; PLO)
This virus is a memory resident COM and EXE infector. It
was first discovered at the Hebrew University in Jerusalem
in the fall of 1987. It contains a flaw which makes it re-
infect EXE files over and over until the files become too
big to fit into memory. The virus re-directs interrupt 8
(among others) and one-half hour after an infected program
loads, the new timer interrupt introduces a delay which
slows down the processor by a factor of about 10. On every
Friday the 13, the virus deletes every program executed
during the day.
[The sUMsDos variant I assume]
This virus is identical to the Jerusalem except it is able
to successfully identify pre-existing infections in EXE
files and will only infect them once.
(Also called the New Jerusalem)
This virus is identical to Jerusalem-B except that the timer
interrupt delay code has been bypassed. This virus is
virtually invisible until it activates.
(Also called the Russian Virus)
This virus is the Jerusalem-C that has odd text and
additional code that is never referenced. A new interrupt
eight routine is added to the non referenced area and a
number of interrupt 21 calls which appear meaningless. The
additional text includes - "ANTIVIRUS". It appears that
this virus is a modified version of some previous variety of
the Jerusalem which we have not yet seen.
This is the Jerusalem-C that destroys both versions of the
FAT on any Friday the 13th after 1990. The code that
originally deleted executed programs has been overwritten
with the FAT destructive code.
This is identical to the D variety except the activation is
any Friday the 13th after 1992.
CENTURY VIRUS (Also called the Oregon Virus)
This is similar to the Jerusalem-C except the activation
date is January 1, 2000. When the virus activates, it
erases both FATs on all connected drives and then begins
writing zeroes to every sector on every attached device. If
allowed to continue to completion, it displays the message -
" Welcome to the 21st Century".
This virus is similar to the original Century virus with the
It waits for BACKUP.COM to be executed and then garbles all
program writes. After BACKUP terminates, the output
functions return to normal.
[No mention of the sURIV 3.00 variant here]
[Nor any of the April 1st sURIV 1.01 and sURIV 2.01 viruses]
[APRIL 1ST AND VARIANTS]
[A memory resident .COM infecting virus which displays the message
"APRIL 1ST HA HA HA YOU HAVE A VIRUS" on April 1st after memory is infected by
execution of an infected .COM file and a further .COM file is executed.
The system locks up requiring a reboot. This virus has the identifying text
string sURIV 1.01.
A .EXE infecting version of .COM which will display the characteristic
message on execution of any infected .EXE file on April 1st, with
associated lockup. A similar lockup will occur 1 hour after infection
of memory on any day on which the default date 1-1-80 is used.]
[CASCADE VIRUS AND VARIANTS]
(Also called 1701; Falling Tears; [Autumn Leaves])
This virus evolved from a trojan horse disguised as a
utility to automatically turn off the num-lock light at
system boot. The trojan horse caused the characters on the
screen to fall to the bottom of the screen in systems with
CGA monitors. In late 1977 this trojan horse was turned
into a memory resident COM virus. It gets it's name from
the size increase of infected COM files - 1701 bytes. The
virus has some unique qualities:
- It uses an encryption algorithm to avoid detection
and complicate any attempted analysis.
- It contains a sophisticated activation algorithm
that is based on randomizations, machine types,
monitor type, presence or absence of clock cards,
and time of year.
- It was designed to infect only IBM clones. True
IBM systems would be spared.
The virus has a bug that causes the machine selection
algorithm to fail. The virus activates on any machine with
a CGA or VGA monitor, in the months of September, October,
November or December in the year 1980 or 1988 (systems
without clock cards will often have a date set to 1980).
This virus is identical to the cascade except that it activates
in the fall of any year.
1704 [(Also called Blackjack)]
I would prefer to classify this virus as a variety of the
1701 but it has been universally referred to as a separate
virus, so I will go along with the crowd on this one. It is
[Nope I have compared the code, identical except for a single instruction,
in my book that counts as the same virus]
functionally identical to the 1701 except that the IBM
selection bug has been repaired. The new virus is three
bytes longer. In every other respect it is the same.
This virus is identical to the 1704, except the cascade
display has been replaced with a system re-boot when the
virus activates. The activation uses the same interrupt 8
randomization algorithm, so the reboot will occur at a
random time interval after executing an infected program on
or after the activation date.
This virus is the same as the 1704-B, except the activation
date has been changed to occur in December of any year.
This virus is the same as the 1704, except the IBM selection
has been disabled (the virus infects true IBM PCs).
[No mention either of the Dbase virus Ross reported recently, of the Oropax
reported by Klaus Brunnstein, so]
A memory resident .COM/.EXE virus. When an infected application is executed
the virus will install in memory looking for an open operation on .DBF files,
any writes would thereafter have two bytes transposed at random, their
location being recorded in the file BUG.DAT in the .DBF directory. Reads of
data would be corrected by the resident portion of the virus, thus data
appeared correct. After 90 days the virus would null the root directory and
(alias music virus)
A memory resident .COM infecting virus. When an infected application is
executed the virus installs in memory trapping the DOS 21h interrupt. Thereafter
when a program attempts a create subdirectory, remove subdirectory, create
file, open file, delete file, get/set file attributes, rename file, delete file
(FCB), create file (FCB) or rename file (FCB) call one .COM file is infected
in the home directory. Command.com, com files with length divisible by 51,
com files with attribute other than normal or archive or com files with
length > 61980 bytes will not be infected. If based on a random number
the virus activates it will play 3 melodies repeatedly with a 7 minute
[In addition I have reports of a further transient object file virus]
In general the virus list seems very comprehensive listing as it does a
large number of variants of the more common viruses. It does seem to omit
detail on the Italian and Lehigh viruses in particular which any list
seeking to be comprehensive must include. I suggest that it would be
very useful to contact the author and arrange for a pooling of resources.
We now have 5 separate lists of IBM viruses in preparation. Klaus'
catalog is very detailed (from the sample entries I have examined) although
I doubt if it can achieve the coverage that Jim Goodwin's list has. As
always it comes down to arranging that we receive, disassemble and
detail new virus strains when they are discovered. Having a number of
centres world wide seems an unnecessary duplication of effort, made even
worse by the lack of sharing of information which occurs. We need a
standard format for virus reports, a list of contacts and the free
interchange of information between each of the existing sites (this should
include virus samples, disassemblies and analysis).
Comp.virus can (I think) prove useful as a contact point through which we
can track new infections, although this will be supplanted by the
establishment of national centres with a reputation (and/or government
recognition) for work in this field.
I am still collating information for an exhaustive catalog, although
indications are that with the explosion of the virus problem this is now
becoming a full time job. Co-operation is important. I entered the field
four months ago, and in that time I have seen how important the establishment
of these links is. Within the UK there are a number of isolated workers
in the virus field, this must change.
Within the Mac field there is a mailing list (Macmash) where discussion
and technical analysis of new strains takes place. I stand by my original
view that there is a place for such a list for IBM PC systems in addition
to virus-l. Many of the viruses described above have never come to light
in reports on virus-l, this should also change. There have been a number
of excellent virus reports on virus-l which have provided very useful
symptomatic analyses of viruses, without providing too much technical
Anyway, enough of the soapbox. Any comments on the above list, including
additions, omissions and corrections would be appreciated. The list seems
extensive, but lacks the detailed information required (for me at least)
to prepare user information and detection software for the above viruses.
Dave Ferbrache Internet <email@example.com>
Dept of computer science Janet <firstname.lastname@example.org>
Heriot-Watt University UUCP ..!mcvax!hwcs!davidf
79 Grassmarket Telephone +44 31-225-6465 ext 553
Edinburgh, United Kingdom Facsimile +44 31-220-4277
EH1 2HJ BIX/CIX dferbrache
To the best of our knowledge, the text on this page may be freely reproduced and distributed.
If you have any questions about this, please check out our Copyright Policy.
totse.com certificate signatures
TSHIRT HELL T-SHIRTS