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...
|
||
|