VIRUS-L Digest Friday, 20 Sep 1991 Volume 4 : Issue 168

VIRUS-L Digest Friday, 20 Sep 1991 Volume 4 : Issue 168

Today's Topics:

Re: Boot sectors (PC)
Re: Mutant viruses (PC)
Re: Scanning LZEXE and PKLITE files (PC)
Re: FAT Infection and sundry flames/comments (PC)
bogus scan?? (PC)
New virus? (PC)
Re: FAT Infection (PC)
Norton Anti-Virus 1.5 (PC)
re: Students and viruses
Re: Boot sectors (PC)
Re: FAT Infection (PC)
Boot sequence part 2 (PC)

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: 20 Sep 91 09:00:05 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Boot sectors (PC)

[email protected] (Gryaznov Dmitry O.) writes:

> Tracing has its own drawbacks - there are several nice methods to avoid
> tracing.

For instance? Are they as safe?

> >2) It is possible (in theory) to design a virus which particularly
> >attacks this protection scheme - i.e., tries to find the file where
> >the original contents of the boot sector is, intercepts the program at
> >the point where the user is notified, prevents the system to be
> >rebooted, etc. All this could be made difficult enough but requires a
> >good amount of programming.

> Let this file be named by user or use just a random name during
> installation.

Of course, I assumed this by default. I had in mind the following
attacks:

1) Search all files on the disk that contain something like a boot
sector or other characteristic parts, if the format of the datafile is
known. Could be stopped by encrypting the file with a user-selctable
password.

2) Wait until the message is displayed (by watching INT 10h or
directly the video RAM) and kill the current process. Could be stopped
by disableing all interrupts when displaying the message and writing
the message directly in the video RAM.

3) Similarly to 2), but wait until the program asks the user for
confirmation and supply it with wrong input. Can be stopped if the
original keyboard interrupt is also traced & saved or if the keyboard
is polled directly, or if the user is given no choice but to reboot.

4) Etc.... :-)

As I said, all these could be stopped, or at least made so difficult
to implement, that the average virus writer probably won't try to; it
just requires a good amount of programming. It is possible however,
that's why I don't consider the boot sector infectors as a major
threat.

> But I wrote:
> >> ... restore the contents of interrupt vectors area
> >> just before booting DOS - virus will lost control.

Agreed, that's a point to install the program in the boot sector,
instead of having it as a standalone program. But I don't like to mess
with the boot sector - it's too dirty. :-)

> Yes. This person was A.Sessa from Dniepropetrovsk, Ukraine. He
> suggested this idea last November at All-Union Anti-Virus Conference
> in Kiev. You were there. Me too.

Nice to meet you again, then... :-)

> >1) Is the Bulgarian virus Dir II already spread there? (It is a virus
> >that cross-links all COM and EXE files to the last disk cluster.) I
> >received a report that it is already spread in Poland, so I'm just
> >wondering... (To all the others: I'll publish soon a detailed
> >description of this virus.)

> Yes, it is. I didn't know this virus came from Bulgaria. Don't you
> know the author?

Damn! :-( Yes, I know its authorS personally. Two kids - pupils at the
Mathematical Highschool in Varna. They are also the authors of Shake,
MG, and the first Dir viruses. They continue to write viruses and to
release them "for fun". :-((

> This August a lot of PCs were infected at WDNH in Moscow (main Soviet
> exhibition) with this virus. So it is spread all over the USSR now.

Damn and damn... :-((((

> There are already several Soviet disinfectors available.
> Once again: is it meaningfull to PUBLISH a DETAILED description of
> a virus? Will it not encourage new virus-writers? Maybe it is worth

Since the virus is already widespread, any virus writer who needs a
copy, will finish getting it... And it's better to warn the rest of
the users to be prepared.

> to organize a special E-mail anti-virus conference not so opened
> as VIRUS-L/comp.virus for exchanging such an info and viruses among
> anti-virus specialists.

This is a good idea and preparations for such thing are under way (the
CARO group & the CARO net), but there is a very difficult problem -
how to determine whom to trust?

> >2) Can you (or whoever from the SU reads this) provide us with contact
> >with the Soviet anti-virus researcher Bezrukov, Nikolaj Nikolaevitch?
> >He lives in Kiev and has published a book on computer viruses. I know
> >his snail-mail address, but could anyone provide him with e-mail
> >contact?

> I have Bezrukov's E-mail address: [email protected] . I sent a

So, SoftPanorama has got a computer and an Internet address? That's
good.

> message or two to him but got no response. Maybe something is
> wrong with this address.

That's shame... Have you tried to add .su at the end? Or is Ukraina a
separate region in Netland too? Another hint - SoftPanorama was in
that institute for avio-engineering. Maybe you have to insert its
weird abbreviation somewhere in the address? Could you please try to
phone Nikolay Nikolaevitch (his phone was 2681026 the last time I saw
him; you should add the appropriate code for Kiev which I don't have
handy right now) and ask him about what happens with his e-mail
address? Please, ask him to try to e-mail to me. Thakns!

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54

------------------------------

Date: 20 Sep 91 09:32:14 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Mutant viruses (PC)

[email protected] (Gryaznov Dmitry O.) writes:

> >Which ones? Can you send examples (encrypted please) to the VTC
> >Hamburg? We already got a Russian encrypted and mutating virus that is
> >currently unknown to the public. It was sent to us by two Russian
> >anti-virus researchers who claimed that they have created it in order
> >to show that virus scanners are inefective... The so-called Washburn
> >approach... :-((

> Can you name these researches?

I'll send you personal e-mail about them.

> One mutant virus is STARSHIP - it contains encrypted string
> ">STARSHIP_1<". It is both MBR and file infector. Uses 4th text video
> page - so it doesn't work on PCs with monochrome. When an infected
> program is being executed the virus just infects BOOT and doesn't
> remain resident. It stays resident when an infected disk is booted.
> Infects .EXE and .COM files being copied to floppy.

This one seems unknown... Could you provide an example to the VTC? It
would be useful too to send a program that can identify most of the
Soviet viruses, so we could recognize them when (and if) they spread.
Is Lozinsky's program still the best one?

> Another one is TEQUILA. Also MBR/file infector. Contains encrypted
> strings "Welcome to T.TEQUILA's latest production", "Contact
> T.TEQUILA/P.o.Box 543/6312 St'hausen/Switzerland", "Loving thoughts to
> L.I.N.D.A.", "BEER and TEQUILA forever!", "Execute: mov ax, FE03 / int
> 21. Key to go on!". Infects .COM and .EXE when executed.

Oh, we know this one. It's really from Switzerland. It's mutating
technique is rather silly; far from the sophisticated tricks used by
V2P6... Is Tequla spread in the Soviet Union?

> I meant POWERFUL ENOUGH regular expressions. For example, including
> variant samples.

Did you mean extended (i.e., egrep-style) regular expressions? Or just
cloumsy enough regexps? :-)

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54

------------------------------

Date: 20 Sep 91 09:43:01 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: Scanning LZEXE and PKLITE files (PC)

[email protected] writes:

> If you PKLITE an arbitrary executable, *ANYONE* can decompress it with
> their copy of PKLITE. Developers who wish to make it less easy for
> anyone who may wish to be able to examine their code may register for
> a customized copy of PKLITE whose output cannot be decompressed by
> end-user PKLITE. This is bad in that even the largest commercial
> developers have been known to be inadvertently infected and distribute
> infected applications, and if they choose to get the special PKLITE,
> we can no longer check the original code ourselves. However, it isn't
> easy for malicious virus-writers to insert their virii into such files
> at the source -- so I don't think this is much of a concern.

Furthermore, it's stupid to claim that files compressed by the
customized version of PKLite are unexpandable. They have to be
expanded in memory when run, don't they? They're just not expandable
to their -exact- (byte by byte) original source. But, of course, the
code (which contains the instructions and where the virus hides) -can-
be expanded exactly. Besides, Ross Greenberg's VirX scans in such
"unexpandable" programs perfectly.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54

------------------------------

Date: Fri, 20 Sep 91 14:25:59 +0000
>From: [email protected] (Morgan Schweers)
Subject: Re: FAT Infection and sundry flames/comments (PC)

Some time ago [email protected] (Vesselin Bontchev)
happily mumbled:
>[email protected] (Brian J Moore) writes:
>
>> >If it overwrites only the first FAT copy, you won't lose anything...
>> >and you probably won't even notice that something nasty has happened.
>
>> Running CHKDSK will tell you if the FATs don't match...
>
>It won't, if the virus modifies the DPB to indicate that there is only
>one FAT copy...

If the virus did that, then DOS would have trouble with the disk.

I think that it should be pointed out that you cannot INFECT the FAT,
but a virus might use it as storage space.

The FATs are PURELY data areas. No executable code, therefore no
possiblity of infection. On that score, you can relax.

There are a *LOT* of delicate features that you can't muck around
with too much under DOS, and most of them you don't discover until
you've crashed your machine a *LOT*! <Grin>

There is a limited set of areas that can be infected by a virus.
Essentially, the files, the MBR and the Boot Sector. The methods used
in infecting these can vary *WIDELY*, however.

There are some things that viruses have not been written to do
yet, thankfully. There are some things that viruses CAN not be
written to do, simply because it's impossible. (INFECTING the FAT is
one of these.)

As a side-slam against viral researchers who write viruses
(slamming them is a favorite hobby of mine) they seem to think that
the first category (viral methods which haven't been written yet) are
a prime candidate for showing off their own technical prowess.
Frankly, any viral researcher who writes a virus 'to demonstrate that
it can be done' is doing the community a *GREAT* disservice.

I am not a proponent of security through obscurity. I believe
strongly in 'be prepared for the worst', however I do not believe that
one should CREATE the worst, to prepare people for it. (As Mr.
Bontchev suggested, that is the Washburn approach.)

My colleagues and I commonly brainstorm and talk (privately) about
possible new viral technology. We try to come up with ideas that will
make each others programs ineffective. The other person (or both of
us) come up with ideas on how we would have to handle that sort of
problem. Neither one of us would WRITE the things we talk about.
*shiver* It's the 'researchers' who don't just *TALK* about this, but
*DO* it which worry me.

I've been off comp.virus for a while, but I see there's still this
thread about 'Virus Simulators' going on. I figure I'll drop in my
two cents... I was aghast when I found out that our strings were in
it. Just goes to show that the little disclaimers we post at the end
of our messages really are true! *grin*

Other side comments: Mr. Bontchev mentioned that to his awareness
VirX was the only program which scanned inside of PKLite'd files as
well as LZEXE'd files... That's not true. McAfee Associates places
high import on the ability to scan inside of compressed executables.
PKLITE and LZEXE detection have been standard inside our programs for
some time now.

It's my firm opinion that the virus problem will not go away until
the operating system manufacturers move their OS into protected mode,
and implement file protection checking in protected mode. This would
also, of course, assist in implementing multiprocessing, etc. Now,
viruses would still propagate under earlier versions of the OS and
earlier processors than the 80386, but it would *STOP* the continual
increase of viruses. (With the obvious exception of people who
implemented their file protection poorly. But that's a system
managment problem.)

If Digital Research does it first, and advertises it properly,
they could kick a serious hole in Microsoft. If Microsoft does it
first, and advertises it properly, they could gain a *LOT* of goodwill
in the computer field. Both of them have a lot to gain. The question
is when they'll get off their lazy ---es and start WORKING!

-- Morgan Schweers
- --
[email protected] | Morgan Schweers | Happiness is the planet Earth in your
[email protected]| These messages | rear view mirror. -- Jeff Glass
Kilroy Balore | are not the +--------------------------------------
Freela | opinion of anyone.| I *AM* an AI. I'm not real...

------------------------------

Date: Fri, 20 Sep 91 10:35:00 -0400
>From: [email protected]
Subject: bogus scan?? (PC)

Hi.

I found the following messages this morning in the FIDO echonet virus
conference:

- ---- begin forwarded messages --

To: Olaf Greve Message #: 4877 3245 <Thread> 4878
>From: Martin Saintonge Submitted: 18 Sep 91 09:22:00
Subject: Number of viruses Status: Public
Received: No Group: VIRUS (30)

>Well you probably have NOT got it wrong but you probably DO have an
>older version of SCAN for version 80 is able to detect some 700
>viruses, I've also read that version 82 (version 81 was probably a
>trojan) will be released very soon.
>Olaf

I've got SCAN version 83 ! I don't think it's a fake, It works fine and
all the documentation is authentic. I got it from a friend from Montreal
and I verified it and performed a scan on it (with version 72) with no
problem.

- --- via Silver Xpress V2.27 [NR]
* Origin: RAMBAB LE babillard du Haut-Richelieu 347-5983 (1:167/570)

- ------

To: Volker Weber Message #: 4993 1204 <Thread> 5013
>From: Paul Ferguson Submitted: 18 Sep 91 20:43:00
Subject: New McAfee's ?? Status: Public
Received: No Group: VIRUS (30)

* In a message originally to All, Volker Weber said:

VW> KH> CLEANBTA.ZIP McAffee Clean Version 8.2
VW> KH> WSCANBTA.ZIP McAffee Scan Version 8.2b / WINDOWS
VW>
VW>Can anybody verify this?

Hmmm... Somethings definitely afoot... McAfee Associates just
released their v82 a couple of days ago, but that was definitely
not the filenames...
Suggest you check with the McAfee rep in your area or contact
someone )BBS) that you thoroughly trust...

VW> A dog is the only thing on earth that loves you
VW> more than he loves himself.
VW> - Josh Billings

- -- I remember the good old days when computers were mainframes,
analysts were magicians, and programmers punched cards.
- Paul Ferguson

Cheers

- ---
* Origin: Sentry Net BBS, Centreville, VA 703-815-3244 (1:109/229)

- ----- end forwarded messages --

Does anyone on this list know something about either a "windowScan" or a
version 83?

Best to all, Claude.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Claude Bersano-Hayes HAYES @ URVAX (Vanilla BITNET)
University of Richmond [email protected] (Bitnet or Internet)
Richmond, VA 23173

------------------------------

Date: Thu, 19 Sep 91 15:52:00 -0500
>From: [email protected]
Subject: New virus? (PC)

In reference of an earlier report from my self about a possible new
kind of vir us, very faster and lethal, i have no way to isolate the
virus because the mach ine that was shoot, was reformatted, i was
trying to locate any virus signature within the backups that i have of
the machine involved in the attack, but all the atempts were
unsuccessful. I begining to suspect that we are dealing with a
local-born virus, this may explain the fact that no anti-virus program
has not ices about him, and probably is very specific for the SCAN
program.

I don't known if the virus attachs his code to a .EXE or .COM file or
if he can "insert" his code within the file's code.

------------------------------

Date: 19 Sep 91 08:21:27 +0000
>From: [email protected] (Vesselin Bontchev)
Subject: Re: FAT Infection (PC)

[email protected] (Nick FitzGerald) writes:

> At this point there is much potential for confusion. Some BSI/PTI
> viruses _affect_ (NOT infect) the FAT. This happens with Stoned and

Yes, I know that of course, but I didn't mean that. I didn't neither
say that the virus will DESTROY the FAT, nor that it will INFECT it. I
said that it will use the first FAT copy (yeah, the first, NOT the
second) to hide there the second part of its body (the first being in
the boot/master boot sector.

> For what Vesellin is hinting at to work, I think what would be needed
> as part of the infection process would be a little "byte twiddling" in
> the partition table entry for the affected partition and the addition/
> modification of some code in the MBR loader.

Well, almost. The "byte twiddling" will be only in the Disk Parameter
Table, which is contained in the DOS boot sector (NOT in the MBR).

> Yes - but note my warning above. If this was prompted due to
> corruption of the FAT by some (Stoned-like or other?) virus, you may
> not be able to "repair" the FAT by copying the second copy back on top
> of the first. Whether this succeeds or not depends upon many factors

To repair the FAT if only one copy is damaged, you have to copy the
CORRECT copy over the DAMAGED one (if there are at least two copies,
which is the usual case). Particularly with Stoned, the damaged one is
the first copy. Unfortunately, DOS sometimes copies the first copy of
the FAT over the second one, without careing whether they are equal or
not. This, of course, will damage the FATs beyond repair.

> >Note however, that it won't help if a virus has been especially
> >designed to hide in the first FAT copy - you'll need probably a
> >specific disinfector.

> Huh - what I'm thinking of would be easily reversible by copying FAT2
> back to FAT1 and fixing the PT entries.

Yeah, but what if there is no second FAT copy any more? :-)

> Yes of course, because it would have to use some good (as in "well-
> implemented") stealth techniques (but wouldn't it then be slightly
> simpler to implement using FAT2 as the hiding place instaed of FAT1?).

Nope. Well, OK, I'll describe it. It is not a very dangerous idea - it
just has not been implemented yet. Someday some hacker will discover
it even without my hints. Well, Ken, if you feel that the idea IS
dangerous, please delete the following description.

In the boot sector of each disk/partition (the DOS boot sector, not
the MBR), at offset 0Bh, the following structure (called Disk
Parameter Block) can be found:

Offset: Length: Comment:
0Bh 2 Number of bytes per sector
0Dh 1 Number of sectors per cluster
0Eh 2 Number of sectors before the first FAT
10h 1 Number of FAT copies
11h 2 Number of 32 byte dir entries in the root directory
13h 2 Total sectors on the disk
15h 1 Media descriptor byte
16h 2 Number of sectors per FAT copy

In general, each DOS disk (or partition) consists of (1) reserved
sectors (their number is at offset 0Eh), (2) n FAT copies (n can be
found at offset 10h) of x sectors each (x can be found at offset 16h),
(3) (r * 32 + 511) div 512 sectors for the root directory (r can be
found at offset 11h) and (4) data space for files, which begins right
after the directory entry.

Now consider a boot sector virus, which overwrites the DOS boot sector
and places its second part, together with the original contents of the
disk over the first FAT copy. It the increases the number at offset
0Eh in the DPB (which indicates the number of reserved sectors before
the first FAT copy), so that it includes all the sectors which were
previously occupied by the first copy of the FAT (now part or all of
them are occupied by the virus). Then, the virus decreases the number
at offset 10h in the DPB, to indicate that there is ONE LESS FAT copy.
On most systems this will indicate that there is now only one FAT copy
(the one which was second before the infection).

Everithing seems OK now and neither DOS, nor CHKDSK, nor anybody else
will notice something unusuall, since the disk structure is OK, the
disk space is not decreased; there is just one less copy of the FAT.
Of course, the virus could aslo have stealth capabilities, in order to
fool the user even further (e.g., it may report a disk error if the
user tries to write on the "reserved" sector, or may indicate that the
number of FAT copies is not changed and redirect all FAT accesses to
the second copy, but all this is not nessacary (although it will help
the virus to spread unnoticed).

The above scheme has only a small drawback - DOS usually dosn't use
that DPB structure when accessing floppy disks. For instance, the
Stoned virus overwrites this structure on the infected diskettes, but
they are strill perfectly readable, without the virus being stealth.
However, this can also be circumvented. It is sufficient to modify the
FAT media description byte (not the one that is in the DPB, since the
whole structure is not used, but the media description byte that is
contained at offset 0 in the FAT), to 0F8h, which will fool DOS that
the diskette is in fact... a hard disk. In this case, DOS will always
use the DPB structure.

Well, that's all, now we have just to watch for such viruses too...
:-((

Note: the idea is not mine, this method has been invented and
described to me (although never implemented) by T.P. - the author of
the Vacsina/Yankee Doodle viruses.

Regards,
Vesselin
- --
Vesselin Vladimirov Bontchev Universitaet Hamburg, FB Informatik - AGN
[email protected] Schlueterstrasse 70, D-2000 Hamburg 13
New address after October 1, 1991: Vogt-Koelln-Strasse 30, D-2000, Hamburg 54

------------------------------

Date: Fri, 20 Sep 91 09:34:17 -0700
>From: bob morales <[email protected]>
Subject: Norton Anti-Virus 1.5 (PC)

Hello there!
At the risk of sounding "virus illiterate" (of which I am trying
to emerge from), I have a question regarding my copy of NAV 1.5.
According to the programs Scan Options, I may set it to "Scan
Executable Files Only" (or words to that effect) which tells me that
virus programs can only be transferred via executable files only,
i.e., files ending in .COM, .EXE, or .SYS. My questions are: (1) is
this a safe bet? and (2) is my assumption correct?
Help me get out of the dark ages. Show me the light!
Thanks.
Bob Morales
7340P@NAVPGS

------------------------------

Date: Fri, 20 Sep 91 12:52:00 -0400
>From: "Jon Womack (Ext. 2-2141)" <[email protected]>
Subject: re: Students and viruses

[email protected] writes:
>It has been my experience that, for as long as I have worked here,
>that administrations of colleges try to keep the subject of viruses
>low-key. They don't want to worry the students, and they don't want to
>admit they have a problem.

[email protected] (Tim Martin; FSO; Soil Sciences) writes:
>Are there any Administrators reading this group, who can explain to me
>the logic behind such administrative head-in-the-sandedness?

I just wanted to comment on this subject. At the Citadel,
approximately 1 week ago, we had a massive infection of the STONED
virus. The Software Support people who run our computer labs,
IMMEDIATELY tagged all infected computers. They were in the process of
evaluating anti-virus packages and selected F-PROT to do the job.

Our head of Information Resources, then sent E-Mail to all
Faculty and Staff to inform them of the problem with this VIRUS (we
have a faculty and staff distribution list). Since then, we have done
everything we can to warn the users (faculty, staff and students) of
the problem, and disinfecting is well on its way. Naturally, there are
still alot of infected diskettes, but but they are identified when the
students attempt to use them, and they are required to go to the
software support people to disinfect them.

Naturally, this has caused us to rethink our virus protection
scheme (one bitten twice shy). ;-)

We have found in general, that if we keep our users informed
of the problems that we encounter and make every effort to learn from
those problems, they are much more forgiving and willing to work with
us. This head-in-the-sand approach simply won't work!

I have been a regular reader of this digest, but this is the
first time I have had a chance to comment. Thanks of all the great
input and keep it coming!

Jon

********************************************************************************
* | What are the three most dangerous things *
* Jonathan W. Womack (Jon) | in the world? *
* The Citadel | *
* (The Military College of SC) | 1) A technician with a program patch. *
* Bond Hall Rm. 403 | 2) A programmer with a screw driver. *
* Charleston, SC 29409 | 3) A user with an idea. *
* (803) 792-2141 | *
* | A lack of planning on your part does NOT *
* BITNET: [email protected] | constitute an emergency on my part! *
********************************************************************************

------------------------------

Date: Fri, 20 Sep 91 15:07:32 +0000
>From: [email protected] (Brian D. Howard)
Subject: Re: Boot sectors (PC)

[email protected] writes:

>[email protected] (Rob Slade) writes:

>> In addition to the psychological advantage, "BSI"s have some
>> technical values as well. For one thing, they get the first
>> chance at the system, before most "protection" has started. For
>> another, a BSI, to be effective at all, must be memory resient.
>> For a third, because hy make changes to system areas which are
>> not normally seen, te changes are often undetected in normal
>> operation.

>In fact there is a way to overcome ANY boot sector infector on PC. To
>do this it is enough to restore the contents of interrupt vectors area
>just before booting DOS - virus will lost control. It is also desired
>to set a correct amount of RAM into an appropriate BIOS variable (loc.
>0:413H). It is possible to place a necessary program code into a DOS
>BOOT sector (not MBR - such a code must be loaded AFTER all possible
>Boot sector viruses). Being installed on a virus-free PC such a
>program can "remember" the necessary info and then check it and, if
>neccessary, restore each time PC is booted. Such an approach was
>implemented at least in one program in USSR.
>- --

That is the approach that we have been taking here at the U-C. I call
it the DELTA approach (Don't Even Let Them Aboard). Of necessity it
treats *any* tsr as a virus, but since we run public systems for any
student to sit down at and use, its not a bad thing for us if all the
machines look the same.

- --
Dallas,TX "Where we shoot Presidents and shoot people who shoot Presidents."

------------------------------

Date: Fri, 20 Sep 91 18:10:53 +0300
>From: [email protected] (Gryaznov Dmitry O.)
Subject: Re: FAT Infection (PC)

[email protected] (Vesselin Bontchev) writes:

>[email protected] (Brian J Moore) writes:
>
>> >If it overwrites only the first FAT copy, you won't lose anything...
>> >and you probably won't even notice that something nasty has happened.
>
>> Running CHKDSK will tell you if the FATs don't match...
>
>It won't, if the virus modifies the DPB to indicate that there is only
>one FAT copy...

If a virus will modify the BPB in such a way, then a start of a root
directory and data area will be calculated wrong - file system will be
corrupted.

Moreover, I experimented with formating a floppy with one FAT copy
(using my own program). DOS (3.30) ignored BPB data saying "one FAT
copy" and considered there were two of them - so it calculated the
start sector of a root wrong and showed a nice picture both with DIR
command and Norton Commander.

Brian is wrong, of course. CHKDSK will not help because such a virus
MUST be stealth - see my previous message on the same subject to the
VIRUS-L.

- --
Sincerely,
Dmitry O. Gryaznov
E-mail: [email protected] or [email protected]
Phones: office: (08535)-2-1731, (08535)-2-0715 home:(08535)-2-1465

------------------------------

Date: Wed, 18 Sep 91 13:45:37 -0700
>From: [email protected] (Rob Slade)
Subject: Boot sequence part 2 (PC)

FUNBOT3.CVP 910918

Boot sequence - part 2

Obtaining the state of the environment immediately after the boot sector
has been run is not as easy as it might sound at first. The computer,
while functional, does not have all parts of the operating system
installed at this point, and it is the "higher" levels of the operating
system that users generally interact with.

The last section of the boot sector program points to the files or areas
on the disk in which to find the next step of the operating system. At
this point the specific files and subsequent steps start to change from
one operating system to another. However, it is fairly common for all
operating systems to have "hidden" files along this route which may be
subject to viral attack. Given that the files are not evident to the
user, they are more subject, not to attack, but to an undetected change.

When setting up antiviral defences, it is important to know the sequence
of events in the boot process in order to know which programs will
protect to which level. The MS-DOS sequence provides the clearest
example, and those knowledgeable in other systems can use the examples it
provides in order to analyze the specific details of their own systems.

After the master boot record and boot sector proper have been run, MS-DOS
normally runs two additional programs which set up input/output routines
and the most basic operating system. (As these programs are called by
the boot sector, it is possible to re-route this process to call
specialized driver programs first, or with them. Some esoteric disk
drives use such a process.) Traditionally, these files have "hidden"
attributes and are not visible to the user on the disk. After they have
run, the system has sufficient programming to interpret a text file which
contains listings of various additional programming which the user wishes
to have in order to run specialized hardware. This file, CONFIG.SYS, is
the first point at which the intermediate user may normally affect the
boot process, and is the first point at which antiviral software may be
easily installed. As can be seen, however, there are a number of prior
points at which viral programs may gain control of the computer.

After the programs listed in CONFIG.SYS are run, the command interpreter
is invoked. The standard MS-DOS interpreter is COMMAND.COM, but this may
be changed by an entry in the CONFIG.SYS file. After COMMAND.COM is run,
the AUTOEXEC.BAT batch file is run, if it exists. AUTOEXEC.BAT is the
most commonly created and modified "boot file", and many users, and
antiviral program authors, see this as the point at which to intervene.
It should be clear by now, however, that many possible points of
intervention are open before the AUTOEXEC.BAT is run.

In spite of the greater number of entry points, viral programs which
attack the programs of the boot sequence are rare, and not greatly
successful. For one thing, while very disk has a boot sector, not every
disk has a full boot sequence. For another, different versions of a
given operating system may have different files in this sequence. (For
example, the "hidden" files have different names in MS-DOS, PC-DOS and
DR-DOS.) Finally, viral programs which can infect ordinary programs
files may not work on boot sequence files, and vice versa.

copyright Robert M. Slade, 1991 FUNBOT3.CVP 910918

=============
Vancouver [email protected] | "If you do buy a
Institute for [email protected] | computer, don't
Research into CyberStore | turn it on."
User (Datapac 3020 8530 1030)| Richards' 2d Law
Security Canada V7K 2G6 | of Data Security

------------------------------

End of VIRUS-L Digest [Volume 4 Issue 168]
******************************************

Downloaded From P-80 International Information Systems 304-744-2253