Prophylactic anti-viral suggestion
G.T...@edinburgh.ac.uk
here is a suggestion which may help protect against trojans and viruses --
I haven't seen it mentioned on virus-l (although I've only been reading
it since the start of the Aids scare - the first time I've been personally
affected by viruses) so if I'm repeating an old idea please forgive me.
I use a computer made in the UK called the Acorn Archimedes -- it is a
proprietary RISC cpu, but I can use it with MSDOS programs because it comes
with a pretty good MSDOS emulator: a combination of a CPU emulator, device
emulator, and operating system emulator. (The device emulator attempts to
pass low-level calls like disk i/o through to the Archimedes' disk controller,
the MSDOS emulator runs an emulated ROM but also passes some BDOS commands
through to the host filing system -- for instance, drive F: could come off
a network drive in Archimedes format, not MSDOS. [The various parts
of the emulation are all implemented in software, I should make clear...]
It occurred to me that a similar program could be run on a *genuine*
MSDOS machine in order to provide a safety wrapper around any programs
which were run on that machine. (Ie it would still be an emulator, but
it would have a head-start in performance because the emulated CPU &
the real CPU were very similar :-) )
This 'emulator' (I'll call it a 'CPU condom' from now on) would therefore
be able to guarantee that any memory access only came from emulated memory --
no program would be able to muck around with real memory. It would only allow
access to the devices which the user chose to allow (eg, clock - yes,
disk controller - no); and it would trap all higher-level BDOS/BIOS calls
in order to ask the user (say by switching to an alternate screen display
and back again) whether he/she wanted to allow any particular file to
be written to.
The CPU condom would probably not be able to allow a full 640K to
the running program - I don't know - that's for MSDOS experts to work out.
With a program like this, you would be able to run any unknown code
with complete confidence. It could be parameterized so that particular
programs being run always were allowed to write only to specific directories,
to save users having to say 'yes' or 'no' every time a file was being
written.
Unfortunately, I don't have the expertise to write this myself, (I
know very little of MSDOS or 808X's and really don't want to waste brain-cells
learning it ;-) ) but the readership of this list is sufficiently wide
that writing such a system may appeal to someone.
Over & out,
regards,
Graham Toal <gt...@ed.ac.uk>
PS If written portably, an MSDOS emulator which did solely file I/O
and screen/keyboard I/O would be usable on other systems -- especially
useful for things like unpacking self-extracting .exe files on unix
mainframes -- almost impossible otherwise. (I have countless numbers
of archive unpackers on our local Unix machine to save telephone
bandwidth when I fetch something from a server and discover I only
want 15% of the archive it came in!)