171 lines
9.2 KiB
Plaintext
171 lines
9.2 KiB
Plaintext
|
This was originally posted in the International Virus Echo, but
|
|||
|
some parties here may find of interest.
|
|||
|
|
|||
|
Date: 06-30-90 (03:11) Number: 1344 The DATAMAX BBS
|
|||
|
To: ALL Refer#: NONE
|
|||
|
From: MARK TAYLOR Read: YES
|
|||
|
Subj: REPOSTED MESSAGE Conf: (39) fVIRUS
|
|||
|
------------------------------------------------------------------------
|
|||
|
(This message was originally addressed to "Merry Hughes", an alias
|
|||
|
used by the sysop of the Excalibur BBS. The author, Frank Breault,
|
|||
|
tried to post it there on June 28. Since he is not a caller of this
|
|||
|
BBS, he asked me to repost it for him here because it contains
|
|||
|
important information which everyone should be made aware of. Frank
|
|||
|
is offering to substantiate his statements in writing in a docu-
|
|||
|
mented, scientific way, and to provide samples, copies of work logs,
|
|||
|
decrypted virus images and transcripts of debugger sessions to
|
|||
|
anyone who is *NOT CONNECTED* in any way with the so-called
|
|||
|
"researchers" of the McAfee company. A sworn, notarized affidavit
|
|||
|
to that effect will be required prior to release of code data or
|
|||
|
samples. Leave me a message if you are interested and I'll try to
|
|||
|
make arrangements. I make no claim of any knowledge of these
|
|||
|
matters but think that people should be allowed to express the
|
|||
|
results of their work, especially when they are trying to warn the
|
|||
|
public about a serious possible danger in a selfless, noncommercial
|
|||
|
manner). ------Message starts:
|
|||
|
|
|||
|
"Well, Merry, most of those who have looked at this unusual virus
|
|||
|
still don't know everything about it. Even after being fully
|
|||
|
decrypted, the code remains hard to disassemble. But I am certain
|
|||
|
that it doesn't contain any reboot routine and I am *quite certain*
|
|||
|
that it does not occupy variable memory size. I have some idea of
|
|||
|
how you came to believe that it uses variable memory allocation but,
|
|||
|
not knowing exactly what you saw, I can't explain your belief. I
|
|||
|
think perhaps you were misled by a trick it plays as it loads into
|
|||
|
RAM. Anyway, Dave Chess of IBM stated that he has disassembled
|
|||
|
about half of it. Rick Engle of Wang Labs seems to have decrypted it
|
|||
|
almost completely. The difficulty in disassembling stems from its
|
|||
|
intentionally-misleading code.
|
|||
|
|
|||
|
Regarding the reboot, perhaps the protection program you were using
|
|||
|
caused it, not the virus itself (Incidentally, both version 1.07 and
|
|||
|
v1.10 of the F-DLOCK program you mentioned are quite useless
|
|||
|
against the FISH 6: it goes right by them).
|
|||
|
|
|||
|
Every day, I am finding new and intriguing aspects of the FISH 6.
|
|||
|
You have no doubt noticed that the virus changes its appearance on
|
|||
|
disk each day of the year. All copies are encrypted, but copies
|
|||
|
produced the same day are all encrypted similarly. This indicates
|
|||
|
that the date holds the encryption key and indeed, that turns out to
|
|||
|
be so: the virus looks at the date and adds the number of the month
|
|||
|
+ the day of the month to derive `n', the number it uses as key for
|
|||
|
its disk XORing routine. The encryption routine used on disk and the
|
|||
|
one used in memory are not the same, however.
|
|||
|
|
|||
|
I now have a fully-decrypted copy of the FISH 6. The string you
|
|||
|
mentioned is shown:
|
|||
|
|
|||
|
|
|||
|
(Quotation marks are mine). The entire string is displayed onscreen
|
|||
|
if any infected file is executed twice when the system date is 1991.
|
|||
|
any sense out of them yet (with my luck, it's probably my birthdate
|
|||
|
- or yours!).
|
|||
|
|
|||
|
Once fully decrypted, the virus code is seen to contain the
|
|||
|
following strings, scattered all over its body:
|
|||
|
|
|||
|
FISH, SHAD, TROUT, FIN, MUSKY, SOLE, PIKE, MACKEREL,
|
|||
|
TUNA, CARP, COD, BASS, SHARK.
|
|||
|
|
|||
|
While in RAM, however, they appear only partially decrypted at any
|
|||
|
one instant, but this appearance also changes constantly. Although
|
|||
|
obviously fish names, they are probably not true text strings as
|
|||
|
such, but portions of executable code. Did someone take the time to
|
|||
|
compose this:
|
|||
|
T = 54h = PUSH SP
|
|||
|
U = 55h = PUSH BP
|
|||
|
N = 4Eh = DEC SI
|
|||
|
A = 41h = INC CX
|
|||
|
and then incorporate it into self-encrypting code in some meaningful
|
|||
|
manner..? Are they just decoration..? Encryption keys..?
|
|||
|
|
|||
|
The RAM image, responsible for the viral activity once the virus is
|
|||
|
loaded into memory, is itself also encrypted, but not in the same
|
|||
|
manner as on disk. Its appearance seems to change from one moment
|
|||
|
to the next. The virus does this every time Int 21 is called. Such
|
|||
|
mutations in RAM do not involve the entire 3584 bytes, but only many
|
|||
|
short portions of the code, each 4-5 bytes long, at any given time.
|
|||
|
After enough such changes have taken place, the entire body of the
|
|||
|
virus in RAM would have been completely altered (except the de-
|
|||
|
cryption routine itself). The size of the memory image, however,
|
|||
|
remains definitely constant and *does not change*, as you stated.
|
|||
|
You can be assured of that.
|
|||
|
|
|||
|
The string "FISH FI..." is found, as you yourself stated, Merry, at
|
|||
|
the end of infected disk files. This, however, is not "later removed
|
|||
|
from the file by the virus itself", as you said. The "FISH FI..."
|
|||
|
string is permanent. However, if you try to use it as a signature
|
|||
|
for the virus, it isn't always useful. Perhaps this action of the
|
|||
|
virus is what gave you the impression that the string gets removed;
|
|||
|
it doesn't, but neither can you read it if the virus is in RAM. The
|
|||
|
string, together with the rest of the virus code, appears to vanish.
|
|||
|
|
|||
|
Like the 4096, the virus disinfects files "on the fly" as these are
|
|||
|
loaded into RAM, so they show the original size, date and CRC. The
|
|||
|
FISH 6 seems to use an improved technique to do this, however, and
|
|||
|
this probably allows it to "disinfect" even files that are being
|
|||
|
opened for Read (as when being scanned for search strings).
|
|||
|
|
|||
|
The method used by the FISH 6 to determine which file to "clean up"
|
|||
|
(as it's being opened or loaded into RAM) is different from the one
|
|||
|
it uses to determine whether a file is already infected (for
|
|||
|
purposes of avoiding multiple reinfection). Like the 4096, the FISH
|
|||
|
marks infected files by altering a special byte in the file date
|
|||
|
entry. (The presence of this "autodisinfection marker" is of limited
|
|||
|
diagnostic value; several viruses use it). In the case of the FISH
|
|||
|
6, files bearing this mark are automatically "disinfected" on the
|
|||
|
fly when opened. The virus does not use this modified date entry to
|
|||
|
determine which files to infect, in the way Zero Bug, Vienna and
|
|||
|
other viruses do. If this byte is altered, the virus stops "auto-
|
|||
|
disinfecting" them, but the files remain infected and infectious;
|
|||
|
FISH 6 knows this and does not reinfect them a second time. It uses
|
|||
|
another method to determine which files it has already infected. I
|
|||
|
believe this may be related to certain operations performed at the
|
|||
|
very beginning of the virus code.
|
|||
|
|
|||
|
NOTE: If an infected file is manually re-dated, it will no longer
|
|||
|
be disinfected "on the fly" by the FISH 6. Thus, files whose
|
|||
|
"autodisinfection byte" has been deleted *can be* identified,
|
|||
|
if infected, using string scanners, even if FISH 6 is active
|
|||
|
in RAM. This offers a means, albeit inelegant, to prepare a
|
|||
|
suspected file for scanning without the virus being able to
|
|||
|
hide itself. If a file is so prepared (redated), then SCANV
|
|||
|
and F-PROT and other string searchers will again be able to
|
|||
|
detect it - but they may still spread the infection in any
|
|||
|
case, if FISH 6 is in RAM.
|
|||
|
|
|||
|
WARNING:
|
|||
|
-------
|
|||
|
This virus would seem to encrypt itself in more than one way or, at
|
|||
|
least, change in some unusual manner. I have in my possession
|
|||
|
copies of what seems to be the FISH 6 virus, but which do not bear
|
|||
|
the scanning string used by SCANV 64 and F-PROT 1.10 and are
|
|||
|
*NOT
|
|||
|
DETECTED BY EITHER SCANNER* on disk. Yet, they are active
|
|||
|
and give
|
|||
|
rise to infections which appear similar to the FISH 6. In this
|
|||
|
sense, I have also received confirmed reports about the existence of
|
|||
|
a "Mother Fish", larger in size and having the capability of
|
|||
|
changing the character of the FISH 6 into a different virus. I don't
|
|||
|
yet have this "Mother Fish" but wonder if perhaps these strange FISH
|
|||
|
copies might have been produced by it, and if the virus which we all
|
|||
|
call the "FISH 6" is really not a virus, in the usual sense, but
|
|||
|
rather just the end product of a more complex, much more
|
|||
|
sophisticated and dangerous viral *system*. If this is so (and it
|
|||
|
appears that it may be so), then analyzing the FISH 6 as a simple
|
|||
|
entity might be a serious mistake.
|
|||
|
---------Message ends.
|
|||
|
|
|||
|
Personally, I think it's very regrettable that the people in the
|
|||
|
McAfee company are endangering the public by witholding information
|
|||
|
just because it does not agree with the results they previously
|
|||
|
published in error. How long does everybody have to live under false
|
|||
|
assumptions just to allow "Merry Hughes" to save face? When Frank
|
|||
|
Breault made a mistake earlier, he admitted it and corrected it
|
|||
|
immediately (12 hours later). Why is it that the person who calls
|
|||
|
herself (falsely) "Merry Hughes" (and who has made many, many
|
|||
|
errors describing viruses!) cannot have the decency to admit
|
|||
|
*his/her* mistakes? Why does he/she hide behind an alias???
|
|||
|
Really, there is no REQUIREMENT that he/she be infallible,
|
|||
|
just plainly honest would do...
|
|||
|
|