VIRUS-L Digest Tuesday, 18 Jun 1991 Volume 4 : Issue 104

VIRUS-L Digest Tuesday, 18 Jun 1991 Volume 4 : Issue 104

Today's Topics:

Re: Checksumming
Info on Disk Killer? (PC)
virus detection by scanners ? (PC)
Master Boot Record (PC)
Re: Is there a 1024 virus? (PC)
Re: Virus scanners (PC)
"Beijing Virus - Urban Legend?"
Re: Scanning infected files (PC)
Re: Virus-writers
Result of preliminary research for Hard Disk Write-Protect (PC)
Re: Is there a 1024 virus? (PC)
Re: DOS 5 Fdisk, etc (PC)
Possible PC Virus (PC)
Interesting interaction (PC)
joshi & vsum & f-prot & ll format (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: Mon, 17 Jun 91 13:07:00 +0300
From: Y. Radai <[email protected]>
Subject: Re: Checksumming

Mike Lawrie writes:
> ... sooner or later this scenario [infecting
>files by performing SCAN while a virus like Plastique is in RAM] will
>re-occur, as you will get hit with a similar type of virus that McAfee
>has not yet catered for, even if you have their very latest version.

Right; I specifically stated that that could happen, and I mentioned
that in order to prevent such occurrences, you could add a good gene-
ric monitoring program. You didn't reply to that suggestion. But
actually, there is a surer solution which I mentioned only later on
in my posting, but which I should have mentioned here also: If you
want to be certain that such occurrences cannot occur, never run a
program like SCAN or a checksummer except when you are certain that
RAM is clean, i.e. only immediately after booting from a clean disk-
ette. (Authors of such programs should mention this; if they don't,
and that apparently includes McAfee, you have a legitimate gripe
against them.)

> A checksummer gives you no
>security whatsoever, because it does not prevent a viral infection.

True, a checksummer does not prevent infection, but at least it can
*detect* infections, and that's a lot better than no security at all!!
Knowing that certain files are infected, you can restore your files
from backups or use a disinfector, something which you wouldn't do if
the infections were not detected.
Moreover, if the checksummer is properly designed and implemented,
(1) it can detect *all* infections, and (2) it cannot be neutralized
or circumvented by hostile software. These are advantages that are
almost impossible to find in any other anti-viral software.

In my opinion, the best software solution is a *combination of
several* programs: a good checksummer (like V-Analyst), a good generic
monitor (like Secure), a known-virus scanner (too many to mention
names), a program which prevents infections through floppy boots (to
be mentioned soon), and more. I use all of them; the resident
programs don't take up much RAM, and they coexist peacefully (well,
most of them ...).

>Just that our experience that I wished to share was that with a
>checksummer in place and use of SCAN, you can end up with every last
>EXE/COM file on you hard disk looking very sick indeed.

Quite true ... *if* you don't take the proper precautions.

Y. Radai
Hebrew Univ. of Jerusalem, Israel
[email protected]
[email protected]

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

Date: Mon, 17 Jun 91 08:25:00 -0800
From: RBRIGGS%[email protected] (Rose Briggs)
Subject: Info on Disk Killer? (PC)

I have had quite a few requests about "Disk Killer" as to the
symptoms, prevention and what damage it does, etc. Does anyone have a
comprehensive overview of this virus?

Thanks
Rose Briggs/NASA HQ
[email protected]
(202)453-1767

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

Date: 07 Jun 91 14:33:23 +0000
From: [email protected] (Hermann Stamm)
Subject: virus detection by scanners ? (PC)

Hello everybody on this list !

I have a few questions concerning detection of virii in general and
1701 in special.

First of all, I hope that only good guys are on this list, because the
remarks made here would otherwise result in hundreds of newly virii.

Let me begin with the story:
Two years ago I bought a diskette containing chess-programs from a
PD-distributor. The chess-programs were ok, but the list.com on that
disk was infected with the 1701 virus. I recognized this, as the
first character falls down my screen with noise. After booting from a
clean diskette I found the modified files, found a search-string to
identify 1701, and wrote a program for detection and removing the
1701-virus. This was my first and up to now last personal contact with
any virus (I hope there is none I didn't recognize).

Now, as I tested scanv77 against the original diskette from the
distributor, I asked myself, how one can fool the detection mechanism
of virus-scanners. The keypoint in the case of 1701 is, that only 33
bytes of the decoding-mechanism are in executable form present, the
rest ist coded dependent on the length of the file 1701 is appended
to. Now any scanner has to look for these 33 bytes only, I think.
But, after a few modifications of these 33 bytes (permuting the order
of execution, changing the names of used registers, or totally
rewriting an equivalent code), the modified 1701 is the same besides
its decoding-part, but isn't detected by scanv77. I have tested this
versions on a portable without (!) any harddisk, and, after
activation, the new virii propagate in the changed form.

Now my questions:

- what other scanner should I try for these versions ?

- is it true, that any scanner must try to look at the
semantics of such decoders, and not at the shape ?
(undecidable problem ?)

- which systems are good by looking at the length of
files and reporting differences ?

- Is the following behaviour possible for a virus:

After getting resident, it forces to do a warm-start
with ctrl-alt-del, and then it copies itself to all
.com-files encountered during rebooting
(like command.com, ...).

I think, that this is the way most of my .com-files
were infected.

Below are the decoding parts, first the one I received by the
distributor, then two modifications, which aren't detected by scanv77.

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

Original decoding of 1701
- -u0109 012a
1DBD:0109 FA CLI
1DBD:010A 8BEC MOV BP,SP
1DBD:010C E80000 CALL 010F
1DBD:010F 5B POP BX
1DBD:0110 81EB3101 SUB BX,0131
1DBD:0114 2E CS:
1DBD:0115 F6872A0101 TEST BYTE PTR [BX+012A],01
1DBD:011A 740F JZ 012B
1DBD:011C 8DB74D01 LEA SI,[BX+014D]
1DBD:0120 BC8206 MOV SP,0682
1DBD:0123 3134 XOR [SI],SI
1DBD:0125 3124 XOR [SI],SP
1DBD:0127 46 INC SI
1DBD:0128 4C DEC SP
1DBD:0129 75F8 JNZ 0123
- -q

Modified, only SP replaced by DX, switch of first 2 stats
- -u 0109 012a
1DC6:0109 8BEC MOV BP,SP
1DC6:010B FA CLI
1DC6:010C E80000 CALL 010F
1DC6:010F 5B POP BX
1DC6:0110 81EB3101 SUB BX,0131
1DC6:0114 2E CS:
1DC6:0115 F6872A0101 TEST BYTE PTR [BX+012A],01
1DC6:011A 740F JZ 012B
1DC6:011C 8DB74D01 LEA SI,[BX+014D]
1DC6:0120 BA8206 MOV DX,0682
1DC6:0123 3134 XOR [SI],SI
1DC6:0125 3114 XOR [SI],DX
1DC6:0127 46 INC SI
1DC6:0128 4A DEC DX
1DC6:0129 75F8 JNZ 0123
- -q

Modified, only SP replaced by AX, switch of first 2 stats,
permutation of statements (i.e. 0110 MOV AX,0682)
- -u 0109 012a
1DBD:0109 8BEC MOV BP,SP
1DBD:010B FA CLI
1DBD:010C E80000 CALL 010F
1DBD:010F 5B POP BX
1DBD:0110 B88206 MOV AX,0682
1DBD:0113 81EB3101 SUB BX,0131
1DBD:0117 8DB74D01 LEA SI,[BX+014D]
1DBD:011B 2E CS:
1DBD:011C F6872A0101 TEST BYTE PTR [BX+012A],01
1DBD:0121 7408 JZ 012B
1DBD:0123 3134 XOR [SI],SI
1DBD:0125 3104 XOR [SI],AX
1DBD:0127 46 INC SI
1DBD:0128 48 DEC AX
1DBD:0129 75F8 JNZ 0123
- -q

Thanks in advance for any hints and answers to my questions,

Hermann.

[email protected]

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

Date: Mon, 17 Jun 91 11:52:37 -0400
From: padgett%[email protected] (A. Padgett Peterson)
Subject: Master Boot Record (PC)

>From: [email protected] (Fridrik Skulason)

>padgett%[email protected] (A. Padgett Peterson) writes:
>>From: [email protected] (Derek William Ebdon)
>>One thing that Mr. Doss forgot to mention is that although Central
>>Point Anti-Virus v1.0 can easily romove the Asuza virus from a floppy,
>>it cannot remove the virus from a hard drive. The only way to
>>disinfect a hard drive is to redo the low level format because the
>>virus infects the boot sector and the dos partition. A high level
>>format will not remove the virus, nor will simply removing the dos
>>partition with the fdisk program.

Aw come on fella, give a fella a break: I didn't say that, Mr. Ebdon
did.

The Master Boot Record, aka the Partition Table Record, aka physical
sector one on the hard disk contains two distinct elements:

1) The partition table located at offset 1BEh-1FCh (what is read by NU in
partition table format).
2) The executable code beginning at offset 0 that uses the table to find
the O/S boot record (also contains ASCII error messages).

Since the AZUSA replaces part 2 with its own code, all that is
necessary for recovery is to mate a good part 2 with the existing part
1 (not really difficult but more complicated than just copying a
sector) and replace the infected sector.

Things get a bit more complicated if special code is in use e.g. the
selection code used with COHERANT or other MBR replacement code
(DISKSECURE does this which is why the original MBR is backed up three
times during the installation process including once on floppy).

However, I have NEVER had to do a low-level format on a disk because
of a virus, & have been able to restore infections from both AZUSA and
MUSICBUG without any great difficulty, it is just a matter of
following the correct procedure, nor have I ever advised anyone to do
so.

Hotly (having rolling blackouts of my a/c),

Padgett

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

Date: Mon, 17 Jun 91 13:03:00 -0400
From: Al Woodhull <[email protected]>
Subject: Re: Is there a 1024 virus? (PC)

> Can anyone suggest an explanation of our observation on several
> computers (various IBM pc types) of a result from chkdsk of 654336
> bytes of total memory?

On one of the computers I use I have determined that the ROM BIOS
reserves 1 K at the top of RAM memory. I first discovered this while
teaching my assembly language students about memory allocation, in
preparation for an assignment to implement some of the ideas in
Padgett's Six Bytes paper, and I was a little startled to think that a
virus might have been present in my own system for an unknown period
of time while I was playing local expert.

I verified that it was the ROM by booting from floppies with different
DOS versions that worked OK on other systems.

I don't know the purpose of this memory reservation, when I look at it
with DEBUG it seems to have been initialized to all zeros, but a few
bytes scattered throughout have other values.

The ROM in this machine is identified as DTK Corp. COMPUTER XT,
DTK/ERSO/BIOS 2.29 (C) 1986.

-- Al [email protected]

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

Date: Mon, 17 Jun 91 13:05:00 -0400
From: Al Woodhull <[email protected]>
Subject: Re: Virus scanners (PC)

> The only "test target" that can be used is the entirety of a virus,
> and at that point you no longer have a "simulator", you have the real
> thing. -- Fritz Schneider

I have only had serious problems with two viruses, Yankee Doodle and
Jerusalem. For each of these I took a file that was infected from my
"zoo" disk, and appended it to a small program that prints a message
and exits. I saved the hybrid files as executables. (I did all of this
with DEBUG). The new files contain all of the infected code and so are
good test targets, but since there is no way to execute the infected
code it is essentially just a block of data. There is no need to worry
about someone else using my computer wondering "I wonder what that
program does?"

-- Al [email protected]

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

Date: Mon, 17 Jun 91 20:38:41 +0000
From: [email protected] (Brian D. Howard)
Subject: "Beijing Virus - Urban Legend?"

Over the weekend on CNN was a reference to a 'computer virus'
triggered by the anniversary of the tianamin massacre. Other than the
brief reference here to allegations of such, was there a *documented*
sighting of such a beastie? (Not that I usually put much credence in
CNN reporting on technical things, but I wondered if the story was
based on anything *other* than an FOAF anecdote from this newsgroup.)

- --
"Hire the young while they still know everything."

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

Date: 17 Jun 91 21:17:51 +0000
From: [email protected] (Johnathan Vail)
Subject: Re: Scanning infected files (PC)

[email protected] (Finnegan Southey) writes:

In regards to the problem of anti-viral programs infecting files
they scan when a memory-resident virus is present: Wouldn't it be
possible to read disks sector by sector instead of opening files
through DOS calls? This reading would be much the same as a disk
editor program. The scanner could consult directory listings to find
program boundaries and then check approp- riate areas without opening
the files as a file? As I'm not an MS-DOS expert I'm not sure if this
makes sense, but I thought I'd ask.

Good question, but: wouldn't it be possible for the stealthy virus to
trap the sector I/O and "fix" it to also hide its tracks?

Hardware level I/O is about the only way to go for this and then you
still have to be careful on a 386 where the MMU can trap hardware
accesses.

jv

"Always Mount a Scratch Monkey"
_____
| | Johnathan Vail | [email protected]
|Tegra| (508) 663-7435 | [email protected](WorldNet)
----- [email protected] {...sun!sunne ..uunet}!tegra!vail

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

Date: 17 Jun 91 21:13:08 +0000
From: [email protected] (Johnathan Vail)
Subject: Re: Virus-writers

[email protected] (Fridrik Skulason) writes:

padgett%[email protected] (A. Padgett Peterson) writes:
>According to this (PC) week's Spencer Katt column, certain anti-viral
>software houses are boosting their counts by soliciting viruses for
>pay and programmers are taking them up for "big bucks".

If that is true, I and and the Virus Bulletim would very much like to
know which companies are involved - I would do my best to drive them
out of business.....

And well you should. I would find this hard to believe. I would tend
believe Spencer Katt as much as I would Dave Berry or Andy Rooney.

I do believe that the anti-virus companies are hyping up the fear of
viruses in order to sell more product. I have been working with
personal computers since 78 and with the exceptions of the viruses
that I wrote myself (the first one was in 1980) and a Mac virus that
went around here at work last year I have never seen or heard a first
hand account of a virus.

Of course I don't do much with shareware or BBS downloading which is
where I imagine most of the problems are.

jv <<-- Of course I will probably be bummin' when I do get hit...

"It's not a cormorant it's not a shag.
Its just something in a plastic bag" -- RH
_____
| | Johnathan Vail | [email protected]
|Tegra| (508) 663-7435 | [email protected](WorldNet)
----- [email protected] {...sun!sunne ..uunet}!tegra!vail

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

Date: Tue, 18 Jun 91 00:53:45 +0000
From: [email protected] (steven l. odegard)
Subject: Result of preliminary research for Hard Disk Write-Protect (PC)

I want to leave a XT with 30Mb hard disk available for public access, and still
preserve the data on it. I proposed a five-position keyed switch with the
following positions:

R. All of 0 below applies, and the reset line to the XT is activated.
The key springs to position 0.

0. All of I below applies, and the keyboard lock on the machine is
enabled.

I. Hard disk is not powered up on startup, however, if the key is moved
from position II, the HD is not powed down. In that case, all write
and read access to the HD is blocked.

II. All write access to the hard drive is blocked.

III. All read and write access to the drive is permitted.

The key is removable from all of the positions except R.

My proposal received one reply which I foolishly misplaced, of how the
write line to the disk can be shorted to high by a audio jack. However,
for some controllers the machine will not boot up in that case.

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

Date: Tue, 18 Jun 91 13:16:00 +1200
From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: Is there a 1024 virus? (PC)

[email protected] (Fridrik Skulason) writes:
> Arthur Buslik writes:
>>As Rob Slade suggests, one possibility is a virus. However, a much
>>more likely possibility is that the computers have extended bios
>>extended data areas.
> :
>>Moreover, INT 15H, AH=C1H will return the segment address
>>of the base of the extended bios area.
>
> Well, not always - I have a HP/Vectra, where the BIOS reserves a 4K
> area just below the 640K mark. However, INT 15H, AH=C1H is not
> implemented in the BIOS (I know - I traced through it), and INT 15H,
> AH=C0H will return the information that no Extended BIOS area is used.
> - -frisk

I have heard that often the port address of LPT4 (location 40E hex)
contains the segment address when a kilobyte or so is "stolen" for
(e.g.) a mouse driver. So that's another thing to look for. But it,
and the int 15 test, shouldn't be taken as definative answers that a
virus isn't there. I suspect the answer is to:

(a) go through each important interrupt (13, 21, 2F, etc), tracing to see if
any use that area, and
(b) look through the code to see if there are interrupt calls, far calls to
BIOS, disk port accesses, signs of self-modifying code, etc.

Alternatively, you could have some "known" valid users of the area in
a database and check that it is one of them there (and nothing else).
Wouldn't it be nice if someone compiled a list of software and BIOSes
that used the area? (any volunteers?)

Mark Aitchison, Physics, University of Canterbury, New Zealand.

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

Date: Tue, 18 Jun 91 13:27:00 +1200
From: "Mark Aitchison, U of Canty; Physics" <[email protected]>
Subject: Re: DOS 5 Fdisk, etc (PC)

[email protected] writes:
> Readers might want to play with an undocumented /MBR switch in DOS 5
> FDISK. It appears to force FDISK to overwrite the code in a PC/PS2
> master boot record, without touching the partition table, and in
> limited testing on a half dozen machines it succeeded in cleaning up
> machines infected with the Stoned, the Stoned 2, and the Joshi
> viruses. This was with the DOS 5 shipped by IBM, not Microsoft's DOS
> 5; can somebody please test MS-DOS 5?

On a related subject:
You may use the DRDOS 5 sys command to rewrite the boot sector (not
the MBR, I think), but watch out when you have a diskette infected in
such a way that the Bios Parameter Block (that says the disk size,
etc) has been junked (e.g. by stoned). The SYS command rewrites a
good boot sector around it (fair enough), but acts on the size
information in the BPB, and you end up with a disk that needs to be
fixed with a disk editor. Remember that DOS normally ignores a lot of
the BPB and goes by the ID byte at the start of the FAT; this is
because early (version 1) DOS might write anything there. DRDOS reacts
sensibly if it contains junk *except* when it comes to the SYS
command, so beware.

Mark Aitchison, Physics, University of Canterbury, New Zealand.

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

Date: Mon, 17 Jun 91 20:51:07 -0700
From: [email protected] (Rob Slade)
Subject: Possible PC Virus (PC)

[email protected] (robert c. morales) writes:

> replicated themselves with such names as EDLIN._OM and AUTOEXEC._AT,
> all of which were 77 bytes in size with the same dates and times. This
> necessitated reformatting the hard drive. Also, the Dosshell was

Ouch.

I don't want to take any guesses as to your approximately 15K file, but I
would venture that someone has been wandering around your office with a
copy of Norton Antivirus, right? The 77 byte files are the "file
signatures" that it uses to detect changes in infected programs.

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

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

Date: Mon, 17 Jun 91 21:07:27 -0700
From: [email protected] (Rob Slade)
Subject: Interesting interaction (PC)

Noted an interesting interaction between two antivirals the other day,
and finally tracked it down. If VIRx 1.4 is run before SCAN 77, SCAN
will "detect" the presence of the 3445 and Doom 2 viri in memory and
refuse to run.

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

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

Date: Tue, 18 Jun 91 11:41:48 +0000
From: [email protected] (Terry N Reeves)
Subject: joshi & vsum & f-prot & ll format (PC)

Vsum still says no utility will remove joshi and that low
level format is required f-prot says "Cured" whne I use it gainst
Joshi, but it still says infected after that, and the hard disk is no
longer bootable. v 1.15a. those who know say ll-format NEVER needed.
I do not know how to manually rebuild partition table so I have done
three of these so far.

Is their a utility Ms Hoffman? perhaps yuou just don't want to
admit it because McAffe's can't? (i have not tried McAffee but I
assume she'd say if his did.)

f-prot must be intended to work - "cured" - so can the author
speak to this?

Thanks for any advice from any source

- --
_____________________________________________________________________________
| That's my story, and I'm sticking to it! |
|_____________________________________________________________________________|
| Public Sites micro software support | [email protected] |

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

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

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