💾 Archived View for spam.works › mirrors › textfiles › virus › fish.vir captured on 2023-06-16 at 21:02:24.
-=-=-=-=-=-=-
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