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 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: Mon, 17 Jun 91 13:07:00 +0300 From: Y. Radai 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 RADAI@HUJIVMS.BITNET RADAI@VMS.HUJI.AC.IL ------------------------------ Date: Mon, 17 Jun 91 08:25:00 -0800 From: RBRIGGS%NHQVAX.SPAN@STAR.STANFORD.EDU (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 Rbriggs@nhqvax.hq.nasa.gov (202)453-1767 ------------------------------ Date: 07 Jun 91 14:33:23 +0000 From: hermann@uran.informatik.uni-bonn.de (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. hermann@holmium.informatik.uni-bonn.de ------------------------------ Date: Mon, 17 Jun 91 11:52:37 -0400 From: padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) Subject: Master Boot Record (PC) >From: frisk@rhi.hi.is (Fridrik Skulason) >padgett%tccslr.dnet@mmc.com (A. Padgett Peterson) writes: >>From: dwe29248@uxa.cso.uiuc.edu (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 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 awoodhull@hampvms.bitnet ------------------------------ Date: Mon, 17 Jun 91 13:05:00 -0400 From: Al Woodhull 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 awoodhull@hampvms.bitnet ------------------------------ Date: Mon, 17 Jun 91 20:38:41 +0000 From: bdh@gsbsun.uchicago.edu (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: vail@tegra.com (Johnathan Vail) Subject: Re: Scanning infected files (PC) ACDFINN@vm.uoguelph.ca (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 | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: 17 Jun 91 21:13:08 +0000 From: vail@tegra.com (Johnathan Vail) Subject: Re: Virus-writers frisk@rhi.hi.is (Fridrik Skulason) writes: padgett%tccslr.dnet@mmc.com (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 | n1dxg@tegra.com |Tegra| (508) 663-7435 | N1DXG@448.625-(WorldNet) ----- jv@n1dxg.ampr.org {...sun!sunne ..uunet}!tegra!vail ------------------------------ Date: Tue, 18 Jun 91 00:53:45 +0000 From: n8243274@henson.cc.wwu.edu (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" Subject: Re: Is there a 1024 virus? (PC) frisk@rhi.hi.is (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" Subject: Re: DOS 5 Fdisk, etc (PC) BARNOLD@YKTVMH.BITNET 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: p1@arkham.wimsey.bc.ca (Rob Slade) Subject: Possible PC Virus (PC) 7340P@NAVPGS.BITNET (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 p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | 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: p1@arkham.wimsey.bc.ca (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 p1@arkham.wimsey.bc.ca | "If you do buy a Institute for Robert_Slade@mtsg.sfu.ca | 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: treeves@magnus.acs.ohio-state.edu (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 | treeves@magnus.ACS.OHIO-STATE.EDU | ------------------------------ End of VIRUS-L Digest [Volume 4 Issue 104] ****************************************** Downloaded From P-80 International Information Systems 304-744-2253