levin@bbn.com (Joel B Levin) (01/19/89)
Here is a brief overview of the recently seen INIT 29 virus. I have
disassembled it and this represents a summary of what I have discovered.
* PLEASE NOTE: Where I describe what this virus does or does not do, keep in
* mind the phrase "AS FAR AS I KNOW." I have looked at all the code in the
* virus, but I'll not guarantee that I have seen everything that there is to
* see in it.
First, the good news: it appears to have almost no harmful side effects
(files destroyed, beeping, and the like). If it can't do something it
generally does nothing. All its code is devoted to the task of propagating
itself.
So the bad news: it is very good at propagating; I would agree with those
who term INIT 29 virulent.
INIT 29 is a single 712 byte resource which installs itself into
non-applications as (you guessed it) INIT 29, and into applications as a
CODE resource. There are no ancillary resources such as those used by nVIR
(and Hpat), so it is somewhat less noticeable using ResEdit, say.
The INIT works by patching a trap, OpenResFile. (If it detects that another
copy of itself has already patched OpenResFile, it does nothing.)
The patch to OpenResFile is a tail patch; i.e., it calls the routine at the
address previously dispatched to by OpenResFile, then does its dirty work on
the resource file just opened. This, basically, is to copy itself into that
resource file if it was not previously infected. If the file has no CODE
resources, it copies itself in as INIT 29. If the file does have CODE
resources, it writes itself into the file as a new CODE resource with the
previously lowest unused resource number. It patches the jump table in CODE
0 so that it is called before the application proper is started.
When an infected application runs, it examines the system file for INIT 29.
If the system is infected, it just starts the application proper; if not, it
first adds itself as INIT 29 to the system file.
The only overtly destructive thing this virus does is to remove and replace
any legitimate INIT 29 which may have been present in the file before the
infection attempt.
Because it patches the trap that it does, any resource file which is opened
once this INIT has run at boot time will become infected: your Desktop file
will have a copy of the INIT; all your INIT files may have it; your EDIT
text files will have it. Just examining a resource fork with ResEdit is
sufficient to add it, either as the INIT, or patching in the new CODE.
The VirusDetective DA can detect it; Apple's Virus Rx 1.4a1 appears to flag
it (though it doesn't say why it thinks a file is bad). Other virus
programs may or may not catch it, and I don't know if any can repair it.
Removing the INIT 29 resource should be safe; however, DO NOT try to repair
applications by removing the offending CODE resource, as there will still be
a patched jump table entry pointing to that resource. I do not know at this
time if Vaccine, RWatcher, or any of the other infection attempt detectors
will catch this.
= =
UUCP: {backbone}!bbn!levin POTS: (617) 873-3463
INTERNET: levin@bbn.comshane@chablis.cc.umich.edu (Shane Looker) (01/20/89)
In article <34734@bbn.COM> levin@BBN.COM (Joel B Levin) writes:
:Here is a brief overview of the recently seen INIT 29 virus. I have
:disassembled it and this represents a summary of what I have discovered.
:
:* PLEASE NOTE: Where I describe what this virus does or does not do, keep in
:* mind the phrase "AS FAR AS I KNOW." I have looked at all the code in the
:* virus, but I'll not guarantee that I have seen everything that there is to
:* see in it.
:
:So the bad news: it is very good at propagating; I would agree with those
:who term INIT 29 virulent.
:
:
:The INIT works by patching a trap, OpenResFile. (If it detects that another
:copy of itself has already patched OpenResFile, it does nothing.)
:
:The patch to OpenResFile is a tail patch; i.e., it calls the routine at the
:address previously dispatched to by OpenResFile, then does its dirty work on
:the resource file just opened. This, basically, is to copy itself into that
:resource file if it was not previously infected. If the file has no CODE
:resources, it copies itself in as INIT 29. If the file does have CODE
:resources, it writes itself into the file as a new CODE resource with the
:previously lowest unused resource number. It patches the jump table in CODE
:0 so that it is called before the application proper is started.
:
:
:Because it patches the trap that it does, any resource file which is opened
:once this INIT has run at boot time will become infected: your Desktop file
:will have a copy of the INIT; all your INIT files may have it; your EDIT
:text files will have it. Just examining a resource fork with ResEdit is
:sufficient to add it, either as the INIT, or patching in the new CODE.
:
:The VirusDetective DA can detect it; Apple's Virus Rx 1.4a1 appears to flag
:it (though it doesn't say why it thinks a file is bad). Other virus
:programs may or may not catch it, and I don't know if any can repair it.
:Removing the INIT 29 resource should be safe; however, DO NOT try to repair
:applications by removing the offending CODE resource, as there will still be
:a patched jump table entry pointing to that resource. I do not know at this
:time if Vaccine, RWatcher, or any of the other infection attempt detectors
:will catch this.
:= =
:UUCP: {backbone}!bbn!levin POTS: (617) 873-3463
:INTERNET: levin@bbn.com
I have a question and potential warning about this. If INIT29 does indeed
patch OpenResFile, the VirusDetective (and others) will cause this to spread
like wildfire. They use OpenResFile to look at each file. Be very careful
if you think you have this. I don't have any suggested workaround, but though
I should bring this up.
Shane Looker | Looker@um.cc.umich.edu
America works less, when you say "Union Yes!"levin@bbn.com (Joel B Levin) (01/20/89)
In article <876@mailrus.cc.umich.edu> shane@chablis.cc.umich.edu (Shane Looker) writes: [quotes my description of INIT 29] |I have a question and potential warning about this. If INIT29 does indeed |patch OpenResFile, the VirusDetective (and others) will cause this to spread |like wildfire. They use OpenResFile to look at each file. Be very careful |if you think you have this. I don't have any suggested workaround, but though |I should bring this up. You should always do your virus checking and repairs after booting up from a known clean system floppy which is kept write protected. If the INIT does not execute at boot up time, OpenResFile does not get patched and VirusDetective et al will not spread it. Note however that running an infected application in this state will attempt an infection of the current System file; if this were to succeed the next reboot from that system would result in a patched trap. An open write protect tab will prevent infection of a floppy disk. /JBL -- UUCP: {backbone}!bbn!levin POTS: (617) 873-3463 INTERNET: levin@bbn.com
kent@lloyd.camex.uucp (Kent Borg) (01/22/89)
In article <34817@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >An open write protect tab will prevent infection of a floppy disk. Is that strictly true? Is the write-protect a hardware interlock, or could it be circumvented by circumventing the file manager and twiddling the disk directly? Kent Borg kent@lloyd.uucp or hscfvax!lloyd!kent