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 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 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:kREBaum@Vax1.CC.Lehigh.EDU BitNet: RB00@Lehigh.Bitnet ", / 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: Subject: Write protect tabs (PC & Apple ][e) In volume 1 : Issue 53, Steve Woronick 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: DAMIAN@JHUIGF.BITNET IGF system manager MANAGER@JHUIGF.BITNET 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 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 len@evax.milw.wisc.edu | | 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: 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 MJBURGE@OWUCOMCN.BITNET ------------------------------ Date: Tue, 20 Dec 1988 15:42:12 EST From: Ken van Wyk 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 ********************* Downloaded From P-80 International Information Systems 304-744-2253