|
Virus- L Digest, Vol 1, Issue 54
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.
From: Kenneth R. van Wyk (The Moderator) <[email protected]>
Errors-To: [email protected]
To: [email protected]
BCC: [email protected]
Subject: VIRUS-L Digest V1 #54
Reply-to: [email protected]
--text follows this line--
VIRUS-L Digest Tuesday, 20 Dec 1988 Volume 1 : Issue 54
Today's Topics:
Re: Trapdisk (PC)
Re: nVIR? (Mac)
Re: Confusion about the Brain virus. (PC)
Warm boot & thwarting the Brain (PC)
Writing with a write protect tab (CP/M & PC)
Write protect tabs (PC & Apple ][e)
write locking floppies (PC)
Write Protection on the Apple II series
IBM BIOS ROM source listing of disk write (PC)
---------------------------------------------------------------------------
Date: 20 December 88, 15:42:14 MEZ
From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1
In-Reply-To: Poster of 16 Dec 88 13:59:46 -0800 from SLCLANCY at UCI
Subject: Re: Trapdisk (PC)
> but I do not like that it remains memory resident.
Steve,
this is the only way a program can monitor other programs' activities,
e.g. disk writes. So you have to live with it.
If I'm right, a memory-resident program can only monitor disk-writes
that are initiated through normal DOS (and perhaps BIOS) calls, but no
low-level disk-writes (which would normally be even more destructive).
So don't feel too sure with Trapdisk and the like!
Best regards
Otto
------------------------------
Date: Tue, 20 Dec 88 10:24:33 EST
From: Joe McMahon <[email protected]>
Subject: Re: nVIR? (Mac)
nVIR is a not-too-bright, kind of silly virus that really doesn't do
anything much other than count the number of infections (and to say
"Don't panic" or beep on a 1/16 chance).
>From what you were saying, its sounds like you may have the "suicide
resource" around somewhere. Check your System file for an nVIR ID=10
with ResEdit. If that resource is there, nVIR (at least one version)
will remove itself from applications. Note that the mere presence of
the resource is checked; the nVIR 10 need have nothing in it.
- --- Joe M.
------------------------------
Date: 20 December 88, 15:50:16 +0100 (MEZ)
From: Otto Stolz +49 7531 88 2645 RZOTTO at DKNKURZ1
Subject: Re: Confusion about the Brain virus. (PC)
> Could some one please explain why a warm boot by itself is not enough
> to prevent the spread of infection
When a program makes itself memory-resident, as many Virus strains
(e.g. Brain, Israel, Blackjack) do, it can hook (and subsequently
respond to) ANY interrupt. These are normal MS-DOS services.
Probably, the Brain virus (I've actually never seen one) hooks the
keyboard interrupt, and responds to the CTRL-ALT-DEL key combination
with re-initializing itself and booting the rest of the system. For a
bootsector virus, as Brain, this should be particularily easy, as the
necessary code is already there.
Given this possibility, it is wise to switch an MS-DOS system OFF and
again ON after every virus infection, as long as you don't know really
everything about you un-welcome guest. If you switch off a PC, the
whole memory is erased (only CMOS is retained, which is rather small,
and contains the hardware-configuration & clock-time). But don't forget
taking out the infected diskette before you switch on again :-)
> Could some one please explain how a write-protected boot disk could
> get infected
Yes, indeed, could someone explain? I was quite sure that the write-
protect tab is a hardware-feature! Am I wrong???
Some possibilities, I could think of, regarding that recent posting on
a perceived infection of a write-protected diskette:
1. The diskette was infected some other time, when it was not protected.
Remember, we read these days in VIRUS-L that some Brain variant is
very clever in hiding itself: it even fools DEBUG and other utilities
in displaying a copy of the original boot-sector (from a "bad" sector)
instead of the infected one.
2. The write-protect tab was not applied properly.
Remember, that the logic of 3.5" diskettes is opposed to the 5.25"
logic, which could give rise to confusion. Remember that we read some
months ago in VIRUS-L, that certain sorts of half-transparent tabs
do not work with certain devices.
3. The hardware used did not work properly.
So far, we've read only about one single incident on one single
computer! Remember, that there are indeed devices that can write
regardless of the tab. (How else could Microsoft deliver their soft-
ware on diskettes without a write-enable notch?) Some months ago,
when this matter was discussed here, somebody wrote that there's only
one wire to inhibit writing; if this wire is broken, what would be
the effect? And who knows all brands of all diskette-drives, and
their properties?
I'd apprecieate greatly, if these possibilities would be checked
thoroughly and reported back to VIRUS-L. I hope the person who embarked
on this topic could contribute (I forgot who it was, and have not enough
disk space available to store the digests, permanently).
Best wishes for a merry Xmas without virus attacks :-)
Otto
------------------------------
Date: 20 December 1988, 10:25:50 EST
From: David M. Chess CHESS at YKTVMV
Subject: Warm boot & thwarting the Brain (PC)
> How can a virus stay "effective" after a warm boot?
"Warm boot" just means pressing Ctrl-Alt-Del. A virus could install
itself so as to be able to detect when you've pressed those three keys,
and simulate a boot, leaving itself resident in memory (a boot
virus discovered at Yale the other month does just that). So a
warm boot isn't necessarily safe, because the virus may be watching
for it. A cold boot (turning off the power switch) is something
the virus can't see and simulate! *8)
> This may seem off the wall right now but I think we all
> need to think of some solution to this "modification of boot record"
> business, especially because most programs can't treat it like a
> normal file and hence can't check for any changes to the boot record.
Programs can read the boot record just as easily (well, almost as
easily) as they can read the contents of a file. It wouldn't be
hard to write a program that would read the boot records, save
the data to a file, and then periodically compare the current
contents with the previous one. I think some of the commercial
programs do this. Of course, for true security you have to make
sure that you are on a "clean" system when you run the check,
otherwise the virus could be intercepting your "show me the
boot sector" requests, and lying to you! (Same goes for checking
the contents of files, really.)
DC
------------------------------
Date: Tue, 20 Dec 88 10:56 EST
From: X-=*REB*=-X <[email protected]>
Subject: Writing with a write protect tab (CP/M & PC)
I have two points on this subject. 8" disk drives on CP/M (and other)
systems used what we know as a "write protect" tab as a "write enable"
tab. To my knowlege, all 5.25" drives operate with "write protect"
tabs.
A while back there was some concern about diskette manufacturers who
provided metallic write protect tabs. This wouldn't have been
important if a manufacturer of disk drives (don't know which one any
more) hadn't designed his write protect circutry to use an optical
sensor. It seems that the circut tried to reflect light off of a
mirror on the opposite side of the slot where the diskette was
supposed to go. This would have worked under ordinary circumstances.
But with the metallic - and reflective - write protect tabs, the light
bounced back regardless of the state of the tab. Thus the tabs
provided no measure of safety whatsoever. This was before the advent
of PC's as we know them today and I doubt any of these drives ever
made it to current machines.
Richard Baum
________________________________________________________________
/InterNet:[email protected] BitNet: [email protected] ",
/ SlowNet: 508 E 4th St Suite #1, Bethlehem, PA 18015 215-867-8433",
/NJ Slownet: 861 Washington Avenue Westwood, NJ 07675 201-666-9207 ",
"--------------------------------------------------------------------"
If you'll be my Dixie chicken, I'll be your Tennessee lamb,
and we can walk together down in Dixie land...
------------------------------
Date: Tue, 20 Dec 88 11:06 EDT
From: <[email protected]>
Subject: Write protect tabs (PC & Apple ][e)
In volume 1 : Issue 53, Steve Woronick <[email protected]> writes:
> 5) About a virus writing on a disk inspite of a write-protect tab,
>I don't believe it. I think there must be a misunderstanding
>somewhere. I suppose the details of enforcing a write-lock vary, but
>they all rely on hardware that disables the write-mode of the disk
>drive. There is no way software can circumvent this protection,
>unless your drive is defective and the write-lock-tab feature isn't
>working properly.
Well, I don't know about the PC's *you* are using, but I believe it is
quite possible to circumvent this restriction on certain machines. An
old pirate friend of mine, a few years back, had his Apple ][e rigged
so that he could copy things to the backs of disks without cutting a
notch into it. According to him, it was done from the software end.
Now, this could be either an exploitation of a since-fixed bug, or
maybe just bull on his part, but don't rule it out as a possibility.
(Actually, what we need is someone who knows well the innards of, say,
disk driver software and that ilk.)
Damian Hammontree EMail: [email protected]
IGF system manager [email protected]
Interactive Graphics Facility
Johns Hopkins Medical School, Baltimore, MD 21205 Tel: (301) 327-2959
==============================================================================
=="This new learning *amazes* me, Bedevere. Explain to me again how sheep's ==
=============== bladders may be used to prevent earthquakes..."===============
==============================================================================
------------------------------
Date: Tue, 20 Dec 88 11:06:41 CDT
From: Len Levine <[email protected]>
Subject: write locking floppies (PC)
>This topic has been kicked around unconclusively here for some time
>now, and unless someone can come up with a verifyable and duplicatable
>method to get around a properly write-protected disk, then I think
>that we should assume that it is not possible to circumvent.
Sorry folks, but my technical folks tell me that the write tab on a
floppy is a soft thing.
I now get that there is a line from the drive to its controller that
is high when the disk is write protected. A switch (this was actually
done) in that line can emulate a write locked or unlocked state
independent of a tab on the disk. Thus, at the drive level, the
protection is not hardware.
My people tell me that the controller merely sets an interrupt when an
attempt is made to write to a locked disk. They feel, but have not
tested, that an attempt to write around the bios can ignore this
interrupt. If they are right, there is no such thing as a write
locked disk in the pc environment.
They also tell me that the controller ROM is loaded into RAM at boot
time, and may be reloaded by the processor during program execution.
I am not sure what this implies but it seems to improve the chances
that a change in the driver will be corrected from time to time.
I think the question is very very open.
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine e-mail [email protected] |
| Professor, Computer Science Office (414) 229-5170 |
| University of Wisconsin-Milwaukee Home (414) 962-4719 |
| Milwaukee, WI 53201 U.S.A. Modem (414) 962-6228 |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
------------------------------
Date: Tue, 20 Dec 88 14:58 EDT
From: <[email protected]>
Subject: Write Protection on the Apple II series
On the Apple IIe series computers, one can enable or diable
write protect checking via simple software switch. Disk writing
routines are available in the Disk Controller card, and can be
accessed from the machine level easily. The entire disk writing
operation is trivial and well documented at least one magazine-
Hardcore Computist, has published complete source for the Disk
Controller, as well as all pertinent information for their usage.
Hope this helps somewhat. Even if it is information for the Apple II
series.
Mark James Burge
[email protected]
------------------------------
Date: Tue, 20 Dec 1988 15:42:12 EST
From: Ken van Wyk <[email protected]>
Subject: IBM BIOS ROM source listing of disk write (PC)
Ok folks, all this talk about floppy disk write protect tabs is
getting nowhere quickly. I have the IBM Personal Computer Technical
Reference manual right here in front of me, and I'm looking at the
disk i/o portions of the 8088 assembly language source code to the ROM
BIOS (page 5-68 in this revision of the manual)...
When writing to floppy disk, the code instructs the disk controller to
perform the write sequence, and *THEN* it checks to see whether that
failed due to (among other things) a write protect situation. That
sure indicates (to me at least) that the write protection is done in
hardware, or at least, if it is in software, then the software is
isolated in the disk controller or disk drive itself.
This issue of VIRUS-L has sure seen a lot of discussion on write
protect tabs... However, I remain convinced that the write protection
is supplied via hardware (or at least via software/firmware local to
the controller or to the disk drive itself) until anyone can send me a
few lines of MASM code that will write to a properly functioning
write-protected floppy disk. Any takers?
Ken
------------------------------
End of VIRUS-L Digest
*********************
|
|
