home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!ukma!usenet.ins.cwru.edu!cert!netnews.upenn.edu!netnews.cc.lehigh.edu!news
- From: padgett@tccslr.dnet.mmc.com (A. Padgett Peterson)
- Newsgroups: comp.virus
- Subject: Is this a Virus (PC)
- Message-ID: <0012.9211121928.AA09892@barnabas.cert.org>
- Date: 10 Nov 92 22:31:05 GMT
- Sender: virus-l@lehigh.edu
- Lines: 33
- Approved: news@netnews.cc.lehigh.edu
-
- To: UVS1::"rknazik@x102a.harris-atd.com"
- (personal mail to this address bounced)
-
- (user reported 654360 bytes by DOS 5.0 MEM and CHKDSK)
-
- a) See the FAQ 8*) it has an entry for this point.
-
- b) The following process is what I use for "something" that cannot be
- identified:
-
- Well, first I assume you meant 654336 not 654360 "total bytes memory"
- or I'd be looking for a bad chip.
-
- Next, I would cold boot from a clean write protected floppy with MEM
- or CHKDSK on it and see if you get the same thing. If not I would be
- concerned.
-
- Then I would use DEBUG to look at the missing memory "D 9fc0:0 L 400"
- should dump the whole k. (D 9fc0:0 with 7 sucessive "D"s will do the
- same thing slower) If almost all zeros, it is probably a buffer. If
- 1/4 or more full of code, then I would be concerned, paticularly if
- there were "interesting" ASCII strings. If all FFs then the chip is
- not responding to that address range (really odd).
-
- If really suspicious I would boot from floppy, capture the MBR, then
- run FDISK /MBR and see if that took care of it. If not, try capturing
- the DBR and run SYS. If this fixes the problem, send the captured file
- to a researcher.
-
- Write if this doesn't take care of it.
-
- warmly,
- Padgett
-