VIRUS-L Digest Thursday, 10 Oct 1991 Volume 4 : Issue 186 Today's Topics: re: Hardware, hardware... Re: Hardware, hardware... Recommend Anti-virus s/w for Novell Netware SF Worms/Viruses (Re: HW not a solution) Re: Morris worms through courts Re: Forget Turing... Re: DIR II (Cluster) Virus (PC) Re: DIR II Removal Information (PC) Re: HW not a virus solution OS/2 2.0 (OS/2) Re: Tequila virus (PC) Virus Protection - Global Software Solution Re: Stoned on preformatted Verbatim Disks? (PC) Bontchev paper available 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 VIRUS-L@IBM1.CC.LEHIGH.EDU (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: krvw@CERT.SEI.CMU.EDU. Ken van Wyk ---------------------------------------------------------------------- Date: 08 Oct 91 09:59:34 -0400 >From: "David.M.Chess" Subject: re: Hardware, hardware... > From: turtle@darkside.com (Fred Waller) > > ... No virus can defeat hardware protection by itself. > It's physically impossible. No reasonable person could hold > otherwise. Sure, no one's disputing that. The point is, though, that that fact isn't really interesting. It doesn't, for instance, imply that a hardware-based protection method would keep a system free of viruses in the real world. The "by itself" is, as you noted, the key. A virus can't defeat hardware protection by itself; on the other hand, it will invariably have help, because people always want to run new software on their systems, or otherwise want to open up the software-space of their storage media for writing now and then. (Or, if they don't, they've got an "application machine" as Bill Murray described; those machines you *can* protect, but they aren't the place where we have the problem.) So it's true that a software virus can't by itself get past hardware protection. But it's equally true that on a general-purpose computer you have to turn off the hardware protection now and then, and then an appropriate virus can infect you. It's an open question whether or not such a scheme would limit virus growth to below epidemic proportions. But then, it's also an open question whether or not any of various software schemes would. So, although they seem very different, it's not clear to me that there's really a huge difference in kind between hardware and software anti-virus schemes. Your later posting ("Forget Turing...") is talking, I gather, about physically write-protecting the disk with the programs on it? If I may risk oversimplifying! *8) That works nicely until you have to write-enable it for whatever reason, or until a virus shows up that infects some sort of object that you forgot was an executable (.BAS files or spreadsheets or whatever). As I said above, that -may- be such a small window of attack that no virus will ever actually get to you, but it's an open question. DC ------------------------------ Date: 08 Oct 91 16:10:38 +0000 >From: groot@idca.tds.philips.nl (Henk de Groot) Subject: Re: Hardware, hardware... turtle@darkside.com (Fred Waller) writes: >bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev), > quotes from an article of mine: > >> But hardware alone is enough. To illustrate: there's no virus > >> in the world that can bypass a simple hardware device called > >> a write- protect tab. This humble little piece of black paper > >> doesn't care one bit about Cohen's theories. Disobeys them > >> every time. :-) > and replies: > > Wrong. Completely wrong. There is a Bulgarian virus, called > > Darth Vader, which infects COM files only when you copy them. > Darth Vader can infect only AFTER becoming TSR in the system. > HOW did that virus (of which I have some copies) would manage to > become TSR on the system? During COPY? Certainly not. So why the > attempt at confusing the issue with such misleading remarks: "Wrong. > Completely wrong"..? What you are saying is that a virus can never go resident on your system and that you only remove the write-protect tab if you are copying files. You are right that your system can not be infected but you DON'T NEED A WRITE-PROTECT TAB either! If you claim that a virus can not go resident on your system than that implies that your system is clean. If your system is clean you can not infect a floppy, protected or not! This mean that if you use your system with the software currently on it and never add new software from the outside world (and only use the floppy's you always used on your system without exchanging them) than you are 100% shure you won't get a virus (and most certainly not new strains) even if you don't use write-protect tabs or whatever measure. This whole thread is rediculus. If you use your system as a standalone system which never gets in touch with other computers by any means, you will not get infected, never! This also applies to a group of computers as long as it never makes contact with the outside world, not ever! Most people however use there computer differently, and that are the computers that are threathend by viruses. People exchange disks with others, upgrade their software. There is no write-protect tab that can stop this because when data is exchanged via a floppy than the write tab must be removed during the write action. At that point de disk can be infected. The only thing a write-protect tab can do is prevent that all your other disks get infected. Every infection via floppy went trough the cycle: write infection on disk -> read infection on uninfected system. Simple but the write protect tab doesn't help because it's removed in the first stage. I hope this will stop this stupid converstion. Henk. - -- / / Henk de Groot | Department: PG 9000i - System Services /---/ __ __ / V2/A12-A13 | Internet : groot@idca.tds.philips.nl / / (-_ / / /( Tel: +31 55 432099 | == PHILIPS INFORMATION SYSTEMS == Disclaimer: I only speak for myself, not for my employer! ------------------------------ Date: 08 Oct 91 16:34:56 +0000 >From: jose@andromeda.rutgers.edu (Alberto Jose) Subject: Recommend Anti-virus s/w for Novell Netware Hi all, Does anyone have info/recommendations on a virus detection/prevention program for the novell netware environment (286Adv 2.15 rev.C)? I heard the CENTRAL POINT's ANTI-VIRUS s/w is LAN compatible...I'd appreciate any help/info anyone would have..thanx. - - Archie - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | jose@andromeda.rutgers.edu | | - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ------------------------------ Date: Tue, 08 Oct 91 20:01:21 +0000 >From: smith@sctc.com (Rick Smith) Subject: SF Worms/Viruses (Re: HW not a solution) jay@markv.com (Jay Skeer) writes: >P.P.S. I got the idea of a computer virus from an old S.F. book. In >the book they actually describe a worm (and called it that) ... >.... This was in 1983 or 4. >Does any one know the name of that book, or of an earlyer reference to >computer viruses? There's Gerrold's "When Harlie was One" which dates at least to the early 70s. There's "Adolescence of P1" (a Morris-like worm) which I read in the mid-late 70s, but I don't remember the author. I've heard people refer to "Shockwave Rider" as a classic example of worm/virus SF though I've never read it and don't remember the author's name. Rick. smith@sctc.com Arden Hills, Minnesota ------------------------------ Date: 08 Oct 91 21:39:07 +0000 >From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: Morris worms through courts For those of you who missed it, Morris's appeal to the Supreme Court was rejected without comment or opinion. Thus, his conviction stands, and the interpretation of 18 USC 1030 is now known to be that no intent to damage need be proven in court -- only intent to access. - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 Internet: spaf@cs.purdue.edu phone: (317) 494-7825 ------------------------------ Date: 08 Oct 91 22:02:19 +0000 >From: spaf@cs.purdue.edu (Gene Spafford) Subject: Re: Forget Turing... Without going into all the gory details.... What Cohen proved in his thesis was that a program to exactly detect all viruses on a Turing machine was an intractable problem. That is, you cannot write a program that will run on a Turing machine and will print "infected/not infected" with 100% accuracy for any arbitrary program on that same Turing machine. Now, this result has been misquoted and misinterpreted by nearly everyone writing about viruses....including Fred himself in later articles. It's not surprising, really, as the concepts of Turing machines and intractability are not well understood -- especially by systems hackers. :-) (That includes me, by the way.) Let me throw out some observations on the situation: #1. There is no similar proof (that I know about) for either multi-headed automata, or multi-tape machines. Thus, I'm not sure that a formal statement can be made about the detection of viruses in the Turing machine equivalents of a multiprogramming system or in a multiprocessor system. If anyone knows the status of these problems, and can cite a publication addressing them, I'd be grateful. #2. The proof shows that you cannot build a perfect detector on a Turing machine. However, the proof depends on the fact that the theoretical Turing machine has unbounded space for programs/data, and has unbounded time to run. If you bound either, the proof no longer holds. For example, if memory consists of only 3 words, you can easily write a detector that knows if there is a virus present or not, and it runs in finite time. Now, consider that real machines have bounded time and space for execution of programs. The intractability result DOES NOT hold on these machines. The problem may be exponential in nature, or worse, but it is not intractable. The halting problem does not exist on machines with finite memory and/or execution time bounds. #3. A perfect detector on a Turing machine is intractable. However, an imperfect program is possible. That is, you may write a program that makes either or both Type I and Type II errors in its classification scheme (Type I in this context would be labeling an uninfected program as infected, and Type II would be labeling an infected program as clean). Building a program that makes only Type I errors might be possible, and could be completely appropriate for our needs. Informally, a crude method would be to label all programs as infected, but that would not be appropriate for general use; however, it is a constant-time/constant-space solution to the problem -- not intractable at all! The problem comes about when trying to reduce the frequency of these errors to an acceptable threshold, and to be sure that no Type II errors occur. Picking any arbitrary levels of confidence may result in an NP problem, but not an intractable one. So, could we please stop claiming that it has been proven that no perfect virus detector can be built, or that finding viruses is an intractable problem? We have an interesting theoretical result, but it does not give us any particular result with respect to the problem at hand. - -- Gene Spafford NSF/Purdue/U of Florida Software Engineering Research Center, Dept. of Computer Sciences, Purdue University, W. Lafayette IN 47907-1398 Internet: spaf@cs.purdue.edu phone: (317) 494-7825 ------------------------------ Date: Tue, 08 Oct 91 21:40:16 +0300 >From: grdo@botik.yaroslavl.su (Dmitry O. Gryaznov) Subject: Re: DIR II (Cluster) Virus (PC) bontchev@fbihh.informatik.uni-hamburg.de (Vesselin Bontchev) writes: >0004886415@mcimail.com (Joe Wells) 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). >> last two bytes of the unused area is zeroed out. Viewing the last >> cluster is also redirected. > >Not exactly. The virus intercepts the disk device drive call BuildBPB >and modifies the returned disk size, so that the disk looks two >sectors "shorter". Two sectors if a cluster consists of not less then 2 sectors, three sectors otherwise. Since the virus can use not the last cluster (in case when cluster is not less then 2 sectors and several last clusters are marked as bad) it doesn't *ALWAYS* hide his clusters. >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. >COMMAND.COM occupies three memory blocks. Afterwards, the virus tries >to execute a file with the name consisting of one character with ASCII >code 0FFh in the current directory of drive C:. Of course, such file 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 ? >will not be found, which will lead to the search of the current >directory on drive C: and of all directories, listed in the PATH >variable. Since the virus infects the directory entries on any sector As I've mentioned above, a sample of the virus I have tries to *OPEN* not to *EXECUTE* an unexisting file in the root directory. To enforce DOS to call driver the virus marks an appropriate Device Info Block 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. If your sample of the virus tries to execute an unexisting file via DOS function 4BH it won't lead to the search of directories, listed in the PATH variable - COMMAND.COM uses PATH, DOS itself never. So, only files in the current directory and in directories on the way to it will be infected. E.g. if the current directory is C:\ABC\DEF\GHI then DOS will search root directory for ABC subdirectory, then ABC for DEF and so on. >When a machine with an infected command interpretter is booted, the >virus detects this and installs itself in memory in a different way. >It waits until the command interpreter's memory control block is >created and then extends it and copies itself in the added space. When the virus receives control, command interpreter's MCB is already created and used - the virus was loaded as COMMAND.COM and DOS Memory List is initialized *BEFORE* executing any program. The virus just checks if its MCB is the next to DOS's (as in the case of COMMAND.COM first loaded after bootstrap) and in the case it extends DOS's MCB to include the virus. Several things others forgot to say: 1) after installation in RAM the virus executes an original program - just like the Jerusalem virus. Since the virus is active, a normal, not infected program will be loaded; 2) being run under DOS 5.0 the virus will "hang" a computer due to a method it uses to call DOS. - -- Sincerely, Dmitry O. Gryaznov | PSI AS USSR grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su | Pereslavl-Zalessky Phones: office: (08535)-2-0715 home:(08535)-2-1465| 152140 USSR ------------------------------ Date: Tue, 08 Oct 91 22:41:42 +0300 >From: grdo@botik.yaroslavl.su (Dmitry O. Gryaznov) Subject: Re: DIR II Removal Information (PC) Joe Wells <0004886415@mcimail.com> writes: >The virus code will be found in the last cluster on the drive. It will >occupy 2 sectors. The code is 1024 bytes. First of all - a disinfection must be made only when there is no the virus in RAM. The virus code will not *ALWAYS* be found in the *LAST* cluster. In fact on 1.2 and 1.44Mb floppies it'll occupy two clusters starting with last-1. On a hard disk the virus can reside in a cluster far from the last if all the following clusters are marked as "bad". >To disinfect, read the virus code from the last cluster. Get the >encryption key and save it. > >The key is the word at offset 33F in the virus code. > >The prototype simply checked all sectors and did simple testing to >determine if it was a directory listing or not. Any other method of >finding the sectors would work as well. Once a sector is found, set a >pointer to the first entry. Check the word at [ptr + 1Ah] for the >last cluster number. The word at location [ptr + 14] is normally 0 in As I've written above the virus does not always use the *LAST* cluster - - you can read the last cluster and find no virus there while the virus *IS* on the disk. This cluster number can be found in the virus body at offset 0334H. And the easiest and correct way to obtain the virus body is to read an infected file (we suppose there is no virus in RAM). So disinfector can check all the .EXE and .COM files for the virus body. When found, it is necessary to check if the cluster (its number is at offs. 334H) *REALLY* contains the virus - you could get an infected file by copying it on a not infected PC. In the latter case a disk most likely is not infected and a file contains just the virus body, its directory entry being quiet normal. - -- Sincerely, Dmitry O. Gryaznov | PSI AS USSR grdo@botik.yaroslavl.su or grdo1@node.ias.msk.su | Pereslavl-Zalessky Phones: office: (08535)-2-0715 home:(08535)-2-1465| 152140 USSR ------------------------------ Date: Wed, 09 Oct 91 13:08:00 +1300 >From: "Mark Aitchison, U of Canty; Physics" Subject: Re: HW not a virus solution There are TWO solutions needed to viruses: (1) "Smart" software that lets you write to some files, but not others (2) "Smart" hardware (or maybe softare) that stops people by-passing (1). There are a huge number of viruses that can easily be stopped by software in the first category... not just detected, but stopped dead in their tracks. for example, software that says "you cannot write to this file", and other precautions that assume the virus goes through normal channels, like DOS. There are no prizes for inventing such software, since it already exists; what is needed is better and better tests that, for example, allow programs that write to themselves to store configuration information to keep working without an annoying pop-up or a lengthy configuration session when you first install the program. I can't see (1) being done with hardware, it is just too complicated. The worry some people have at the moment, quite rightly, is that modern viruses can get past the software virus detectors, and (in theoy at leat) past the best software-only solution you might ever come up with. Hence the discussions that go along the lines "software can beat software", and the worrying fact that viruses have the advantage because they come *after* the anti-virus software they're trying to circumvent - the next generation of a-v programs might beat them but there will be a good time for them to spread before that. Now, as pointed out, the hardware solutions suffer from the fact that people will turn them off when they need to do something useful, at which time the virus has a chance, or they will deliberately let spreadsheets, .BAS programs, etc go through unhindered for convenience. The obvious answer is that a COMBINATION of hardware and software is needed; the hardware to stop people getting around the software. You might be able to think of some complicated software that will get around particular combined solutions, but it doesn't have to be 100% watertight - so long as the virus would have to be very big and clumsy, or has a lower chance of spreading from machine to machine than the chance of being spotted at any stage. Talk about the "psychology" of virus writing before leads me to think that all that is required is for virus writers to be faced with a pretty slim chance of success (and a good chance of being caught), for virus writing to suddenly go out of fashion. For that, we either needed a lot of users to adopt pretty simple software solutions (the type that MS or DRI could have built into their operating systems ages ago for free), or we need that plus a bit more now, to knock the bulk of the viruses on the head. I feel the DRDOS 5, with its password protection system was a good first step, and DRI & Microsoft should be encouraged to take more steps like that, since it is obvious the average user won't. Mark Aitchison. ------------------------------ Date: 08 Oct 91 22:09:09 -0400 >From: BARNOLD@YKTVMH.BITNET Subject: OS/2 2.0 (OS/2) We did some limited testing DOS viruses under a widely distributed July 1991 Beta version of OS/2 2.0 (driver number 6.149, if anybody cares). The following notes hold *only* for that Beta version; the ship level version (whenever it happens) may be different in some particulars. (I'm not in any way affiliated with the OS/2 2.0 development group, other than working for the same company.) Positives: (+)Direct writes to the disk at the INT 13 and INT 25 level were disallowed. Bimodal viruses, and viruses that use INT 13 or INT 25 to do damage will have a harder time than under DOS. (We didn't try calling the BIOS INT 13 routines directly.) (+)OS/2 DOS sessions go away, completely, when you double click on them. A memory resident virus active in a DOS session will not remain in memory after the DOS session is terminated. (+)Boot sector viruses don't survive the OS/2 2.0 boot process. A system can still be infected, particularly with a master boot record virus such as the Joshi, but it won't spread the infection to diskettes while OS/2 is active. I know of an instance where an OS/2 1.3 system was infected with the Campana (Telefonica) virus. It was set up for "Dual Boot", which is crude support for booting OS/2 from DOS and DOS from OS/2. When OS/2 was booted, the Campana was inactive; when DOS was was booted, the Campana became active and spread to other diskettes. (The Campana is a master boot record virus.) (+)If you try to run a DOS program from an OS/2 session, the command interpreter (or something) recognizes it, and starts up a DOS session just for that program. When the program terminates, the DOS session goes away, including any virus resident in memory. (+)The few anti-virus tools that I tried in this environment worked fine. IBM VIRSCAN runs in both OS/2 DOS and protect mode sessions. (This particular driver had a bug in the DOS session findfirst/findnext INT 21 call, with a simple workaround.) Minuses: (-)No file-level access controls. (Arggghhh!) (-)Unfortunately, while the address space isn't shared among DOS sessions, the filesystem *is* shared. This includes everything in the /OS2 and /OS2/MDOS directories (/ == backslash), which are in the default DOS session PATH. For instance, this means that a memory resident virus that attaches itself to COMMAND.COM (such as the 4096) will become a permanent feature of any DOS sessions started subsequently. Bill Arnold ------------------------------ Date: Wed, 09 Oct 91 06:17:39 +0000 >From: mcafee@netcom.com (McAfee Associates) Subject: Re: Tequila virus (PC) rsr%garnet.Berkeley.EDU@ucbvax.Berkeley.EDU (Roger Rosenblum) writes: >Patricia Hoffman's virus summary indicates that the Tequila virus >can be detected/removed by McAfee & Associates SCAN/CLEAN programs >(Version 80+), yet I see no mention of this virus in the documentation >(VIRLIST.TXT) for version 80 or 82. Am I missing something? Just that it wasn't put into the documentation :-) Seriously, my workload (not to mention the number of viruses) has been increasing and I have not had as much time to work on the documentation as in the past. I've just returned from my vacation to find thatVersion 84 was released. I'll put some sort of comment in to the docs on the next release. Regards, Aryeh Goretsky McAfee Associates Technical Support > >Roger Rosenblum Internet: rsr@garnet.Berkeley.Edu >Workstation Software Support Bitnet: rsr@ucbgarnet.Bitnet >University of California at Berkeley - -- McAfee Associates | Voice (408) 988-3832 | mcafee@netcom.com (business) 4423 Cheeney Street | FAX (408) 970-9727 | aryehg@darkside.com(personal) Santa Clara, California | BBS (408) 988-4004 | 95054-0253 USA | v.32 (408) 988-5190 | CompuServe ID: 76702,1714 ViruScan/CleanUp/VShield | HST (408) 988-5138 | or GO VIRUSFORUM ------------------------------ Date: Tue, 08 Oct 91 15:41:47 -0400 >From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Virus Protection - Global Software Solution >From: Jay Skeer > Jay's Virus Proof Machine > Jay's Virus Proof Machine has two disk drives a "program" disk and a >"data" disk. It also had a big red switch labeled "install/run". > Sounds good huh? It wont work. It WILL make the life of computer >users miserable, but it WONT prevent the spread of viruses. > This scheme fails because it does not take into account the >observation (invention?) that some bright guy (Von Neuman?) made in >the 50's -- You can't tell program from data. You just can't. - ------------------------------------------------------------------- This is the first time I have seen a reply appear in the same posting as the original - a dose of Asimov's endochronic somethingoranother I guess. >From: turtle@darkside.com (Fred Waller) >Subject: Hardware > Fred's Virus-Resistant Machinee > ------------------------------ > Fred's Virus-Resistant Machine also had two disk drives, a "program" > disk and a "data" disk. It, too, had a _small_ switch (not red), > labeled: "Install/Run". > Unlike Jay, Fred (Waller) also had this silly idea that it isn't > necessary to make viruses impossible in order to provide adequate > defenses against them. He didn't care if they existed, as long as >it was somewhere else. > In this way, while Jay decided that his machine couldn't possibly > work, Fred discovered that his machine (which wasn't virus-proof, > but only virus-resistant) *did* work, and extremely well. None of > his favorite viruses (hundreds of them, my goodness!) succeeded in > infecting it. Since he always booted from a clean disk (the safe > "program" disk or a trusted diskette), he had no Boot infectors > in RAM. Some of his viruses did freeze the machine but he was > able to reboot without infection and kept smiling. (lots of intermediate stuff deleted) Here we have two very good very logical postings. I agree with Fred (Waller not Cohen) and disagree with Jay's conclusions but the hinge is on a minor point: Jay's concept required a separate boot mechanism (the tiny IS) to install/update files to the program area. It would be understandable that making a system unable to update LIST or WORDSTAR files would be objectionable to users since occationally tastes change. As mentioned previously I use a special program (BYPASS) to allow updating of my ProgramDisk rather than requiring a reboot. Along with encapsulating the tinstalling application, BYPASS also checks the environment before and after the application. The hardware switch is a good idea if you are really worried (lead #6 on the 34 pin cable of an MFM/RLL drive) but I have never found it necessary. Thus the disagreement stems from implimentation rather than concept since all of them (Jay's, Fred W's, and mine) are the same. (Great minds think alike ). My real disagreement is this argument that "computers are made to run programs, viruses are programs, therefore computers cannot tell viruses from programs." This is wrong. Period. The same logic would state that "saddles fit horses, saddles also fit tigers, therefore horses cannot be distingushed from tigers." While viruses are programs they do things that programs should not do except in special (and trackable) cases: one of these is to attempt to write to executable programs, another is to go resident (at least sucessful viruses do). Both of these are detectable and flaggable. (The flagging is where many early programs failed since it was not selective. BYPASS makes it selective.) More important, it makes it difficult for a logic bomb to work - try to delete executables, it fails. Try to encrypt a disk, it fails, Try to format the disk, it fails - so even if a trojan gets in, it will likely fail. (Data is backed up isn't it - much easier than backing everything up: my executable drive (also contains clip art, help files, .mnus, etc.) is 40 Mb, the DataDisk is 20 MB and has more free space.) The point is that my ProgramDisk traps all write and format attempts just like DiskSecure traps them for the MBR, hidden sectors, and Boot Record. In my viral demonstrations at conferences I normally just turn on full protection and use a RamDisk for the demos - so far so good. Thus: both Jay and Fred W. make valuable points in this connection - pay attention to what they are saying & consider that the problems mentioned are just ones of practise not concept. Padgett ps It is interesting to see that all the principals seem to be classmates of Dr. Cohen - having gone to school when FORTRAN II and punch cards were popular, I must have missed something. 8*) ------------------------------ Date: Thu, 10 Oct 91 00:33:40 +0000 >From: act@softserver.canberra.edu.au (Andrew Turner) Subject: Re: Stoned on preformatted Verbatim Disks? (PC) ac717@cleveland.Freenet.Edu (Jeffry L. Johnson) writes: >This is at least thirdhand information, but I am curious >whether anyone else has heard this rumor: > > Some preformatted Verbatim floppy disks are infected > with the STONED virus. > >I do not know what density or size of disk. I suppose I acknowledge your anxiety but really IMHO: a. Thirdhand rumours really don't warrant your posting. The virus scene gets touchy enough without recourse to heresay three times removed. NB I have nothing whatsoever to do with Verbatim. b. Have you contacted Verbatim to check it out? Your rumourx3 may have some basis, but lets have facts! - -- Andrew Turner act@csc.canberra.edu.au Die, v: To stop sinning suddenly. -- Elbert Hubbard ------------------------------ Date: Tue, 08 Oct 91 10:52:46 -0400 >From: Kenneth R. van Wyk Subject: Bontchev paper available Thanks to Vesselin Bontchev for contributing his paper, "The Bulgarian and Soviet Virus Factories" to the archives! The paper is available by anonymous FTP on cert.sei.cmu.edu (192.88.209.5) in pub/virus-l/docs. (I will gladly e-mail the paper out to any archive maintainers who can't access it via FTP.) Two versions of the file are on-line: bulgarian.factory.tex - original document, formatted with TeX bulgarian.factory.doc - ASCII version of same A brief abstract follows: It is now well known that Bulgaria is leader in computer virus production and the USSR is following closely. This paper tries to answer the main questions: Who makes viruses there, What viruses are made, and Why this is done. It also underlines the impact of this process on the West, as well as on the national software industry. Enjoy! Ken Kenneth R. van Wyk Moderator VIRUS-L/comp.virus Technical Coordinator, Computer Emergency Response Team Software Engineering Institute Carnegie Mellon University krvw@CERT.SEI.CMU.EDU (work) ken@OLDALE.PGH.PA.US (home) (412) 268-7090 (CERT 24 hour hotline) ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 186] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253