sorrell@triton.unm.edu (Stan Orrell) (06/07/91)
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? The value is confirmed, in kbytes, when Norton SI is run. The machines are always booted from floppies, and are networked, but only data files are moved over the network connection. Everything seems to be OK otherwise, i.e. the usual applications work correctly and no other weird files have appeared. What is this? And, what should one do about it? Any help appreciated. Thanks, Stan.
p1@arkham.wimsey.bc.ca (Rob Slade) (06/11/91)
sorrell@triton.unm.edu (Stan Orrell) writes: > 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? A number of viral programs would fit this bill, the most obvious being the ubiquitous "Stoned". Check the boot sectors of your boot disks with your Norton utilities. ============= 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
chris@renoir.teradyne.com (Chris Maslyar) (06/13/91)
>> 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? >A number of viral programs would fit this bill, the most obvious being >the ubiquitous "Stoned". Check the boot sectors of your boot disks with >your Norton utilities. I noticed this 654336 anomaly as well. Unfortunately (fortunately?) SCAN V7.2V77 didn't find a culprit, and Norton utilities came up blank when I searched for "Stoned". I'll spare you the details of the painful steps taken to arrive at my solution to say that: Some PC/AT computers give the user an option to place 1K of BIOS into base memory subsequently reducing the size of memory to: (you guessed it) 654336 You may want to look for this option BEFORE you format your disks :) Good Luck Chris chris@attain.teradyne.com
74676.2537@CompuServe.COM (Arthur Buslik) (06/13/91)
Stan Orrell writes:
"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?"
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. (See, e.g. "The New Peter Norton Programmer's
Guide to the IBM PC & PS/2",2nd edition, 1988, page 62.) INT 15H,
AH=C0H will return ES:BX as the segment:offset of a configuration
table. The fifth byte of this configuration table gives configuration
flags. Bit 2 of this byte is set if an extended Bios data area is
allocated. Moreover, INT 15H, AH=C1H will return the segment address
of the base of the extended bios area. The word at 0040:0013H is
modified to reflect the reduced amount of memory available to
programs. This is what chkdsk returns as "bytes total memory", and
also what INT 12H returns in AX. On my COMPAQ 386/20e at work, I
obtain the following when I use DEBUG:
- -a100
1AFA:0100 mov ah,c0
1AFA:0102 int 15
1AFA:0104
- -g104
AX=0000 BX=E6F5 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=1AFA ES=F000 SS=1AFA CS=1AFA IP=0104 NV UP EI PL ZR NA PE NC
1AFA:0104 0000 ADD [BX+SI],AL DS:E6F5=6E
- -df000:e6f5 l 9
F000:E6F0 08 00 FC-01 00 74 00 00 00 .....t...
The configuration flag byte is 74H=01110100B, and since bit 2 is set, my
machine has an extended bios data area allocated.
Moreover, using DEBUG again, this time for INT 15H, AH=C1H, I obtain:
- -a100
1C6B:0100 mov ah,c1
1C6B:0102 int 15
1C6B:0104
- -g104
AX=C100 BX=0000 CX=0000 DX=0000 SP=FFEE BP=0000 SI=0000 DI=0000
DS=1C6B ES=9FC0 SS=1C6B CS=1C6B IP=0104 NV UP DI NG NZ AC PO NC
1C6B:0104 7205 JB 010B
- -d9fc0:0
9FC0:0000 01 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
etc., all following bytes being zero.
My machine has 1Kb of memory reserved, at the top of memory for an extended
bios data area. The first byte gives the number of Kb of memory reserved.
On my machine all the other bytes are zero, whenever I look at them
with DEBUG. (I don't know what they are when I don't look at them.)
For what it is worth, the machines at work which have the extended bios
data area implemented, and for which chkdsk returns 639K total memory,
all have a socket in the back for a bus mouse.
Art Buslikpadgett%tccslr.dnet@mmc.com (A. Padgett Peterson) (06/13/91)
>From: Arthur Buslik <74676.2537@CompuServe.COM> > >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. This is certainly a vialble alternative. However, if running DOS 4.0 or later, CHKDSK will "normally" detect this and return "655360" anyway. A few years ago, when we received or first Compaq 386-20e in we discovered the same thing: 1k missing from the TOM & DEBUG revealed it to be essentially zero-filled (obviously not executable). After much prodding, Compaq told us that it was a buffer area for the mouse driver and that there is a jumper on the motherboard that can be moved to restore the missing 1k. Whenever a new machine comes in, it is a good idea to take some baseline data for later reference. For me, any time Int 12 is lowered, I check the memory area in question. If executable code is found, unless known, a look is taken at other system integrity areas for a reason. If nulled or obviously data, the manufacturer is called for an explination (often a frustating & time consuming experience). Padgett Somewhere West of Orlando
frisk@rhi.hi.is (Fridrik Skulason) (06/15/91)
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
AWOODHULL@hamp.hampshire.edu (Al Woodhull) (06/18/91)
> 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
PHYS169@csc.canterbury.ac.nz (Mark Aitchison, U of Canty; Physics) (06/18/91)
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.