warthman@softvax.radc.af.mil (WARTHMAN) (09/19/90)
I've been told about a recent CNN report, supposedly dealing with 2
new Macintosh viruses. The person who told me about this could not
remember the names of either, but said that one of them had "DEF" as
part of its name. He said it was *not* MDEF or WDEF. He could not
remember if it was CDEF, but said he did *not* think it was. He said
that the report indicated that there was no "cure" for one of the
viruses, and that Symantec (he mentioned this company by name) was
"feverishly" working on countermeasures to combat that virus. Has
anyone on VIRUS-L heard this CNN report? Can you fill in the blanks?
I wonder if this person misunderstood, and CNN was actually referring
to the "Whale" virus (DOS)?
Also, I've recently heard about a variant of nVIR called "prod". Does
anyone have information about this one? Will the current set of
anti-viral tools handle it, since it's supposed to be just another
clone? Will it even be tracked separately?
Thanks for whatever insight can be added.
- -- Jim Warthman Warthman@SOFTVAX.RADC.AF.MIL (Internet)
AFC JimW (America Online)padgett%tccslr.dnet@uvs1.orl.mmc.com (A. Padgett Peterson) (05/01/91)
Recently, I have received questions from two different people
concenting activities that sound suspicious yet do not match any of
the charactoristics that I am aware of. If anyone has further
information, elucidation would be appreciated.
Oddity #1: Several XT class machines exhibit the following: all Master
Boot Records (partition table) have 17 bytes written into
offset ACh-BDh (immediately before P-table). These bytes are
an executable fragment containing the following assembly code:
1E PUSH DS
07 POP ES
BB007C MOV BX,7C00
B90100 MOV CX,0001
BA8000 MOV DX,0080
000000
I am told that any attempt to replace the MBR results in an
unbootable machine and if the locations are zero'd using Norton,
the code immediately reappears.
Oddity #2: Single 386/SX20 found the an unusual MBR which appears to be
the second half of "something". The MBR will operate normally
if called with DX=0. If called with a non-zero DX and if a data area
from offset 03-15 is filled, amoung other activities, an interrupt
between 42h and 59h will be trapped (which one is found in the
data region, unfilled in the fragment I received). The code
has all of the normal error messages and appears otherwise normal
e.g. no attempt to modify 413 is made.
If any reader has seen anything like this, a reply would be appreciated.
Warmly (only 93 yesterday)
Padgett