VIRUS-L Digest Monday, 28 Oct 1991 Volume 4 : Issue 198
Today's Topics:
Boot Sector Modified (PC)
Bloomington (NoInt, StonedIII) Virus? ? ? Info (PC)
Re: Experiences with hardware protection (Thunderbyte) (PC)
Re: Experiences with hardware protection (Thunderbyte)
Re: DIR II (Cluster) Virus (PC)
Re: DIR II (Cluster) Virus (PC)
Re: Virus-writing course for teenagers
Stamping out "Stoned" (was Hardware) (PC)
re: SVC 5.0 (PC)
Re: Virus-writing course for teenagers
re: Hardware and software (was: Leopards)
re: Interpreted things
Re: Help urgently needed for stoned virus (PC)
Viral code association
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Mon, 21 Oct 91 10:53:52 +0700
>From: Mike Albrecht <
[email protected]>
Subject: Boot Sector Modified (PC)
Hello All,
I've read Virus-L for over a year now but until now have had no reason
to submit a question. Hopefully some of you can help me out.
The student computer labs that I manage for the College of Business
and Economics at Washington State University are comprised of PC's &
PC/XT's. We've had our share of the common viruses (Yale/Alameda,
Jerusalem, Stoned) but have managed to almost eliminate the problem in
the labs through regular scanning of student diskettes, use of (site
licensed) F-Prot, and recently installing Padgett Peterson's NoFBoot
(no problems so far, Padgett, and a big help.)
However, twice now F-Prot has issued the warning:
Warning !! - boot sector has been modified
The first time this happened I attributed it to a student replacing
the autoexec.bat file with the correct checksums (for f-oschk) for
that machine with an autoexec from another machine in the lab with
different checksums. I suspected this since I make the autoexec.bat
file and others read-only and hidden and on this particular machine
the autoexec had indeed been modified and was no longer hidden. I
didn't check further but just re-ran f-oschk to generate the correct
checksums, edited the autoexec accordingly, and forgot about it. No
problems. Today another machine booted up with the above warning. I
cold booted with a clean, write protected floppy, scanned for viruses,
even used the analyse feature in F2.EXE -- nothing unusual reported. I
looked at the boot record with Norton's Disk Edit and the only thing
that appeared unusual was under the heading 'Special hidden sectors:'
which reported 8388639 instead of the usual 31 for this drive (Seagate
ST-225R.)
I re-ran f-oschk to get new values, thought they looked strange (the
last one was 0 which I'd not seen before), checked to see that I had
copied them correctly, edited autoexec, and re-booted (this time from
the hard drive: same warning. Ran f-oschk again and got different
values (they looked more typical), edited autoexec, and re-booted:
O.K.
So...., both machines seem to be working normally; I checked the first
machine for unusual boot sector values - looked O.K. What could be
altering the boot sector causing f-oschk to trigger? I'd appreciate
any suggestions on what to look for. It doesn't seem to be a big
problem but it seems curious. I've got copies of the boot sector and
PBR if they'd be of any use.
Hope someone can help. Thanks.
Mike Albrecht, Systems Analyst
W.S.U. College of Business and Economics
------------------------------
Date: Mon, 21 Oct 91 16:23:27 -0700
>From:
[email protected]
Subject: Bloomington (NoInt, StonedIII) Virus? ? ? Info (PC)
Recently we have found (several? ? ?) viruses on 3 ALR PC 386
machines. Norton Anti-virus says it is a boot sector infector named
Bloomington. Mcafee v84 called it "Stoned III." Other scanning
products have called it "NoInt" and "LastDirSect".
I haven't been able to find information on any of these. (I checked
CERT/Brunnstein list 7/91). Anybody know what this virus does, how to
get rid of it. . . etc. etc.
Thanks in advance.
Frank E. Bien Email:
[email protected]
TRW Computer Security Services Phone: (213) 812-5072
One Space Park, S/2724B
Redondo Beach, CA 90278
------------------------------
Date: 21 Oct 91 20:28:48 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Experiences with hardware protection (Thunderbyte) (PC)
[email protected] (Harry Stox) writes:
> Although personally I don't have any experiences with the Thunderbyte
> hardware, my guess is that is is unusable with modern IDE or SCSI
> drives, since the hardware is placed between your MFM/RLL controller
> and your harddisk.
Oh, I forgot to say that the current version is not compatible with
the MCA architecture.
> Given the abominable quality of the TBScan software, which stems from
> the same company, I personally wouldn't trust the software which
> controls their hardware lock.
While I tend to agree with the comment about the quality of TbScan, I
still insist that the Thunderbyte card does pretty good job - at least
for me.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 20:22:11 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: Experiences with hardware protection (Thunderbyte)
[email protected] (Reinhard Kirchner) writes:
> I got produkt information about a hardware virus protector called
> 'Thunderbyte' which intercepts all mysterious writings to the disk, e.g.
> absolute ( not through dos ), writing to exe/com files etc.
> Such a thing costs appr. the same as a software package, and it does not
> depend on updates for new viruses.
> So I want to ask: Is there any experience with such devices, thunderbyte
> or others ? Is it worth the money ?
Yes, I have some experience with it. It's really a very good product -
the best one to my knowledge that realizes hardware virus protection
(except the Big Red Switch <grin>). Since it's reletively cheap, IMHO,
it is worth the money, especially for a single user. I don't know if
it is acceptable for companies that have to protect 100 or so PCs. I
repeat, it provides an extremely good level of protection. However, if
you are looking for the "ultimate protection", forget about it. There
are alread viruses that are able to bypass it (without even knowing
that it is present). And I can certainly see how more such viruses
could be made.
> From the documentation I have such a hardware protector looks like a
> ultimate solution.
Well, it isn't. It's just pretty good. The ultimate solution is the
Big Red Switch.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 19:53:27 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II (Cluster) Virus (PC)
[email protected] (Johnathan Vail) writes:
> My claim is that DIR 2 can legitimately be called a virus since it is
> logically still part of another program and relies on a host program
> being run in order to get an execution thread.
Hmm, it's not that easy... Dir II does -not- attach itself to other
programs. It only manipulates the system information (in this case -
the directory entries), so that the files -seem- to begin with the
virus. However, the boot sector and the companion viruses do similar
things and we still call them viruses.
I'd call it a virus - it is a virus, according to the Cohen definition
and I'm happy with that.
Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: 21 Oct 91 19:34:19 +0000
>From:
[email protected] (Vesselin Bontchev)
Subject: Re: DIR II (Cluster) Virus (PC)
[email protected] (Dmitry O. Gryaznov) writes:
> >> listed in the structure above. The original is scrambled by using a
> >> straight forward rotating xor encryption. Once an altered entry is
> >
> >It's not that "straight forward"... :-) It's not easily computable by
> >hand and is based on a key, which tends to be different for different
> >disks. The key depends on the DOS partition size, the number of
> >sectors in a cluster, etc.
> For anti-virus researches: this key (2 bytes) can be found at
> displacement 033FH inside the virus body ("infected" cluster(s) on an
> infected drive).
Yeah, I know, since my disinfector uses it... :-) I meant that the
- -method- is not easily computed by hand - try to rotate the key in
your head as many times as the number of the current directory entry
and to xor the result with the current contents of the last two of the
10 reserved bytes... :-)
> >When a file, whose directory entry is infected is run on a clean
> >system, the virus installs itself in memory, marking its current PSP
> >as 0008 (as if it belongs to COMMAND.COM). MAPMEM will show that
> 0008 mark in MCB means *NOT* COMMAND.COM but DOS itself.
Yes, of course, that was a stupid mistake.
> Not in the current but just in the *ROOT* and not to execute but just
> to open. Maybe we have somewhat different versions of DIR II ?
Very unprobable; the original spreads so fast that it just does not
leave any place for other, competitive, variants... :-) You're right
again - it's an open, not an execute. The execute instruction is a few
bytes below and has the totally different purpose to execute the
original program. So, the open only causes infection of the current
directory on drive C:, not of the directories, listed in the PATH.
> as "never been accessed". So DOS will re-read the root directory and
> the virus will get a good chance to infect all .EXE and .COM (except
> System) files in the root including COMMAND.COM.
VolumeLabels and Directories are also excluded from infection.
> 2) being run under DOS 5.0 the virus will "hang" a computer due
> to a method it uses to call DOS.
Yeah, because in DOS 5.0 the original INT 21h handler is no more at
that offset in the DOS segment... However, the virus works perfectly
on my copy of MS-DOS 5.00.224-beta...
Reagrds,
Vesselin
- --
Vesselin Vladimirov Bontchev Virus Test Center, University of Hamburg
[email protected] Fachbereich Informatik - AGN
Tel.:+49-40-54715-224, Fax: -246 Vogt-Koeln-Strasse 30, D-2000, Hamburg 54
------------------------------
Date: Tue, 22 Oct 91 17:23:00 +0300
>From: Y. Radai <
[email protected]>
Subject: Re: Virus-writing course for teenagers
Previously I quoted from the syllabus of a science-for-youth course:
>> Assembler. In this language you'll be able to acquire tools for things
>> which cannot be done in any other language, like: how to 'create
>> viruses', how to write protection programs and how to crack them.
and I commented as follows:
>> Needless to say, the matter has been brought to the attention of the
>>program director, and it is expected that the above applications will
>>not actually get mentioned when the course is presented. It has also
>>been suggested that part of each course be devoted to a discussion of
>>computer offenses and rules of ethics.
Rotan Hanrahan replies:
>I don't see how avoiding mentioning such matters would avoid the
>further proliferation of virus-like entities. To deny our most able
>members of society the knowledge of such matters is a form of
>censorship that, frankly, I cannot accept. ....
> .... The most able people should be given the knowledge to tackle
>this problem. I suggest that such courses in "virus construction" be
>given. ....
> .... It is time we changed too, and stopped trying to deny the
>apparent reality which surrounds us.
1. Offering a course in creating viruses and cracking protection
programs to any interested teenager is like offering a course in
cracking safes or building bombs to any interested person. Do you
advocate such courses too? Would you say that to deny "our most able
members of society" the knowledge of safe-cracking and bomb-building
is also "a form of censorship"?? Would that constitute denying the
"apparent reality which surrounds us"? (Interesting phrase. Sounds
to me more appropriate to Metaphysics-L than to Virus-L.) If you
advocate such courses too, then you are in an extremely small mino-
rity. If not, please state where you find a significant difference.
2. Such a course is even closer to Burger's book, which gives actual
source code for viruses such as the Vienna virus. Today there are at
least 42 variants of this virus and several similar viruses, and it's
safe to assume that the overwhelming majority of them are the direct
result of Burger's book. Please explain to us just what benefit has
been derived from publication of the source code which could compen-
sate for the damage which has been caused.
From what I have written above, you might get the impression that
I'm old-fashioned and unenlightened (not to mention in favor of "cen-
sorship"). I could show, by several other examples, that this is not
true, but I don't wish to start another debate (my original posting on
the current subject was intended merely as an FYI). However, to
disseminate the details of how to construct a virus is beyond the
bounds of my liberalism. Whatever you imagine may be the supposed
benefit to humanity of learning how to write a virus, I'm sure it's
far smaller than the risk involved.
>..... But denial is not the correct manner or civilized way in which
>the problem should be tackled. To co-present the techniques of virus
>construction with the ethical considerations is perhaps the most
>desirable approach. ....
> .... The medical community have established reasonable
>ethical frameworks. Isn't it time the computer community did likewise?
>Let's not hear any more about cencoring information about viri and
>concentrate more on ensuring that the people who compose our community
>are more responsible with the knowledge that is given to them.
I find the comparison with ethics in the medical community almost
amusing. The "community" we are dealing with here (and probably when
talking of virus writers in general) is the community of youngsters,
for whom virus writing is a challenge and an outlet for their mische-
vious impulses. Those who are attracted to this course will be
precisely those who say to themselves, "Gee, I've always wanted to
write a virus, but I never knew how. Here's my chance to learn!" They
may learn ethics too, but the urge to release a virus will be much
greater in some cases. And even if only one of them actually does so,
the damage may be much greater than the imagined benefit. Would you
be willing to accept the responsibility if this happens? I wouldn't.
Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]
------------------------------
Date: Tue, 22 Oct 91 17:12:13 +0000
>From:
[email protected] (Kevin Buhr)
Subject: Stamping out "Stoned" (was Hardware) (PC)
[email protected] (TEE LUNS) writes:
>An idea I've been toying with lately has been
>to write a dummy partition table which Stoned will recognize as being
>itself. This would defer infection. For $5 a shot, do you think
>anybody would go for it?
Wait! I've got a better idea. You should write a program that
resides in the boot sector of floppy disks. When the user boots from
disk, the program should go resident (possibly in the last couple of K
of memory, which the user won't miss), and so the user won't always
have to boot off the floppy, your program should place a copy of
itself in the hard drive partition table saving the original in a safe
place. Of course, your program would contain those vital first few
bytes that Stoned uses to recognize itself so your hard drive would be
immune.
But there's still a problem! The user could boot off an infected
floppy. Stoned wouldn't install itself on the hard drive (because it
would find those special bytes in your program), but it would still go
resident and start infecting the rest of the user's disks. The virus
could still spread! For this reason, your program should also be sure
to place a copy of itself on every floppy read or written (even if
stoned got control of INT 13 AFTER your program, it would still think
that the floppy had ALREADY been infected, because of the special
signature in your program, and would not reinfect). With this
measure, all the users floppies would be safe.
There would be an additional fringe benefit, too. When the user
passed disks he or she had used to friends, they could boot from the
disks, installing the program on their own machines. Depending on the
rate of prolifigation of your program, the Stoned virus could feasibly
be stamped out in a matter of months!
Of course, as already mentioned, the user of anti-viral products
should know that they are resident. Therefore, your program should
put a message on the screen on bootup. It wouldn't have to happen
every time, since the user would only need to be occassionally
reminded that your program was hard at work protecting him or her from
the Stoned Virus. Once, say, every eight or so times, your program
would display "YOUR COMPUTER IS protected from being STONED! <BEEP>".
Now I'd pay at LEAST $10 for a program like that! ;->
Kevin
<
[email protected]>
------------------------------
Date: 22 Oct 91 13:13:41 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: re: SVC 5.0 (PC)
> From:
[email protected]
I tend to agree with Andrzej; the 5.0, at least, isn't really complex.
Except for intercepting a few extra DOS calls in order to be
stealthed, it's your typical resident virus. The style is the same
rather "wordy" and awkward style as the SVC 3.1 (probably a
self-taught author, hehe).
> I do
> not know for what reason virus do not infect files if the file name
> contains characters 'MM' or 'MB' (maybe protection of author software).
Most likely that's a quick-and-dirty way of avoiding infecting
COMMAND.COM, IBMBIO.COM and IBMDOS.COM, the system files in IBM
PC-DOS.
DC
------------------------------
Date: Tue, 22 Oct 91 17:33:18 +0000
>From:
[email protected] (Kevin Buhr)
Subject: Re: Virus-writing course for teenagers
[email protected] (Werner Uhrig) writes:
[Someone uncredited writes:]
>> To co-present the techniques of virus construction with the ethical
>> considerations is perhaps the most desirable approach.
> then you also believe that giving everyone a gun and a course
> in ethics (together with the practical training) would have
> kept the nut in Killeen, Texas (just up the road from here)
> from shooting all those people earlier this week?
> (or make the world a safer place, in general?) :-((
The difference between guns and viri is that, while having practical
knowledge about how guns fire bullets is of limited use when you have
been shot, knowledge about how viri infect computers is very useful
when your computer has been infected.
It seems to me that there are far too many messages posted by
desperate, internals-ignorant computer users on this list alone who
have been infected by a virus and are trying to understand the
difference between boot sector viri, EXE/COM viri, etc.
The biggest problem with available methods of viral protection may be
not that protection of type X is insufficient and we need protection
of type Y (which is arguably true for many choices of X and Y) but
that the vast majority of users know so little about how their
computers work on the lowest level that they cannot be expected to
know what prevention measures should be effective and how they might
fail.
On the other hand, I find the thought of heaping vast quantities of
"how to" knowledge about viri on (possibly) immature and reckless
teenage programmers more than a little scary. Some people would argue
that the best way to show someone how to stop viri is to show them how
to make viri. Because of the other dangers involved, this is probably
not true.
To use your gun analogy: if you want to teach someone how to protect
themselves from bullets, you should concentrate on the effects of
bullets on people (with and without bullet proof vests for example)
and not on how to build a gun and make ammunition.
Kevin
<
[email protected]>
------------------------------
Date: 22 Oct 91 13:18:37 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: re: Hardware and software (was: Leopards)
> From:
[email protected] (Fred Waller)
> when I said that it HAD worked, it was said that it
> couldn't be useful against some still-unknown viruses, and now I'm
> taken to task for not testing the system against such still
> nonexistent viruses. ... :-)
No, no one's faulting you for not *testing* against non-existent
viruses. I was just pointing out that your test against existing
viruses with you as the user wasn't good evidence for how the system
would work against existing viruses on machines used by Real users, or
against nonexistent-but-obviously-possible viruses (like database
or spreadsheet infectors). It might work very well with real users,
and database/spreadsheet/etc viruses might in fact not be something
we need to worry about! But I don't think you can criticize people
*too* strongly for not taking your word for it. *8)
> It WAS proof, and it was indicative. Small-scale proof may
> rightfully be extrapolated.
But there can be differences of opinion about the extrapolation.
You think it's clear that your test will extrapolate nicely into
the real world. Others are more skeptical. An honest
difference of opinion, that only time and the marketplace can
judge...
> But which other approaches are meant?
> I don't know of any existing software method that is as effective
> as hardware protection.
Against existing viruses (and that's the context in which I was
talking), there are *lots* of software methods (and products
embodying them) that are just as effective as hardware: that is,
they stop and/or detect all currently widespread viruses.
> If one exists, it should be implemented
> immediately everywhere!
Aye, there's the rub! The reason that scanners (for instance) haven't
stopped most virus problems is *not* that scanners don't work against
viruses, I would claim. It's that most people don't use scanners.
Every serious scanner works *perfectly* against the 1813 (Jerusalem)
virus, for instance. Then why does it continue to spread? Because
most PCs are not protected with (even something as trivial as) a scanner.
I suspect that a good hardware solution would face the same problem?
But again, market one, and we'll see if you get rich! *8)
DC
------------------------------
Date: 22 Oct 91 13:32:15 -0400
>From: "David.M.Chess" <
[email protected]>
Subject: re: Interpreted things
>From:
[email protected] (Fred Waller)
Writing about viruses in databases and spreadsheets and
other data-like things:
> However, I also believe that it would be
> much more difficult to make such virus as deceiving as our current
> furtive ("stealth") viruses, or as difficult to detect.
That's quite likely true. It's worth noting, though, that "stealth"
techniques, while they sound snazzy in the press, and are fun to talk
about at conferences, are *not* in fact a significant part of the
virus problem. Most widespread viruses are not stealthed, most
stealthed viruses are not widespread, and stealthed viruses are not in
fact any more difficult to detect (at least from the end-user's
viewpoint) than non-stealthed ones. Stealthing is a way that virus
authors have extra fun (I guess), but as far as I know it hasn't
really had any effect on the spread of viruses in the actual world.
So even if an interpreter-virus couldn't be stealthed, all that that
means is that it could only become as widespread as other
non-stealthed viruses. Like the Jerusalem and the Stoned, for
instance! *8)
DC
P.S. I have no strong opinions about how widespread a
interpreter-virus could become; I don't know enough
about the current, or especially the future, patterns
of sharing of interpreter-things. I'm just pointing
out that there's no particular evidence that stealth,
or lack thereof, is relevant to the question...
------------------------------
Date: Wed, 23 Oct 91 10:20:00 +1300
>From: "Nick FitzGerald" <
[email protected]>
Subject: Re: Help urgently needed for stoned virus (PC)
[email protected] (Peter H. Lemieux) writes:
> Okay, if you know what you're doing you can try this. You need a copy
> of Norton Utilities. Use the explore disk function to examine
> ABSOLUTE sector 1. You should see the number 55 in the last byte of
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> the sector if your disk is Stoned.
Sorry, but WRONG! We continue to be a source of misinformation of the
worst kind.
Of all the Stoned infections I've seen, _NONE_ would be diagnosed by
using this test. Most early versions of Stoned seem to overwrite the
55AA "bootable disk" flag _on floppies_ with two NULs (at least in my
collection of Stoned variants), but leave these bytes intact in HD's
MBR's - something to do with skipping over the partition table.
Maybe the Stoned variant running rampant in Peter's neck of the woods
does write 55 into the last byte, but it sure doesn't make anything
like a definitive test.
Whilst here, I'd like to add that while Peter's manual disinfection
routine will work, it doesn't cover the situation of the possible
corruption of the original boot-sector/MBR code. On a HD there is no
easy solution if the original MBR has been corrupted (if you are in
this situatiom, email me for detailed help), but with floppies there
is.
Cold boot the PC from a write-protected clean system disk. Use
Nortons, PC-Tools or similar to read the boot sector from the floppy
you booted from, swap the system diskette for an infectted diskette
and get your disk editor to write the sector back to disk. One
important caveat to this is that the disk you read the clean boot
sector from _must_ be the same formatted density as the disks you are
disinfecting. If you have high and low density infected disks, now
that your system is clean you can safely format a disk in drive A: to
get examples of clean boot sectors for both densities.
- ---------------------------------------------------------------------------
Nick FitzGerald, PC Applications Consultant, CSC, Uni of Canterbury, N.Z.
Internet:
[email protected] Phone: (64)(3) 642-337
------------------------------
Date: Mon, 21 Oct 91 15:18:10 -0700
>From:
[email protected] (Rob Slade)
Subject: Viral code association
FUNPIV4.CVP 911020
Viral code "association"
The simplest way for a viral program to avoid the detection that
results from modifying the code of an existing program is not to
modify the original program. This is an elementary solution,
but would seem to have the drawback that, unless you do change
the file in some way, the virus will never be called.
There is a "solution" to this problem, and (if I may be allowed
some enthusiasm for the concept, if not the reprehensible act) a
rather elegant one at that.
In a given situation, computers may be presented with a number
of possible courses of action. The action taken first is
decided by pre-programmed precedence. A number of programs may
have very similar names, leading to potential confusion about
which one is to be run in a given invocation. In the case of
MS-DOS, for example, SET.COM, SET.EXE and SET.BAT are all
"executable" files. In the normal course of events, any one
could be invoked by giving the command "SET". If all three
files exist, which one is to be run?
The precedence of program invocation under MS-DOS is that .COM
files are first, .EXE second and .BAT last. If three files of
the same name do exist, this does not imply that all three will
be run in that sequence, but rather that giving the command
"SET" will always invoke only the SET.COM file.
A certain class of viral programs; known variously as
"companion", "spawning" or "precedence" viri; use this feature
of the operating system. They "infect" a file with an .EXE
extension simply by creating another file with the same name,
but a .COM extension. Thus the .COM file is always executed in
place of the original .EXE file. The original file remains
unchanged, and no manner of "change detection" will tell you any
different. (In order to further avoid detection the viral file
will generally end with a very specific "call" to the original
program, and the viral program has the "hidden" attribute set.
In the Macintosh and other GUI operating systems, it is possible
for a virus to take precendence by "overlaying" an existing icon
with another which is either transparent or identical to the
first.)
Fortunately, companion viri are by no means perfect. For one
thing, they are limited to those programs which are "lower" in
the order of precedence. For another, the "hidden" attribute is
relatively easy to overcome (particularly in MS-DOS), and an
alphabetical listing of files will quickly turn up the anomaly
of identical names. Of the antiviral packages tested so far, no
change detector alerts to duplicate names, although many may
alert the user by asking the user to "validate" a file that has
been in use for some time. It will probably not be long,
however, before this is a common feature.
copyright Robert M. Slade, 1991 FUNPIV4.CVP 911020
=============
Vancouver
[email protected] | "Power users think
Institute for
[email protected] | 'Your PC is now
Research into CyberStore | Stoned' is part of
User (Datapac 3020 8530 1030)| the DOS copyright
Security Canada V7K 2G6 | line." R. Murnane
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 198]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
