Hacker 2/HACKER2.mdf/virus/virusl2/virusl2.13

Text File | 1995-01-03 | 8KB | 177 lines

VIRUS-L Digest              Friday, 13 Jan 1989         Volume 2 : Issue 13

Today's Topics:
Re: cbug (PC)
encrypting code.
nVIR in European beta of MS Word 4 (confirmation) (Mac)
How a worm/virus can trap ctl-alt-del (PC)

---------------------------------------------------------------------------

Date:         Thu, 12 Jan 89 09:21:57 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      Re: cbug (PC)

The 1.1.80 date on the cbug is the default date on a pc without its
time/date stamp set.  If you never set them that is what they come up
as.

------------------------------

Date:         Thu, 12 Jan 89 09:23:45 EST
From:         "Homer W. Smith" <[e-mail]>
Subject:      encrypting code.

     I have read an interesting article in a magazine called Reality
Hackers.  It is very drug and counter culture oriented, trying to give
these things respectability, but it had a good article on viruses.
(What the hell does CYBER mean anyhow!)

     One of the things it said that might be done to protect programs
from viruses is to make the operating system store all programs in a
scrambled state (encryption).  Then just before running them, decrypt
them.

     When and if a virus attaches to an encrypted program, it will get
scrambled when the program is decrypted and cause a crash.

     Seems like a very very good idea.  How say you all?

------------------------------

Date:     Thu, 12 Jan 89 11:35 EST
From:     JEFF WASILKO--MEMBER OF PRINTER'S DEVILS-LOCAL #47
          <[e-mail]>
Subject:  nVIR in European beta of MS Word 4 (confirmation) (Mac)

The following is being forwarded from the Mac-User distribution list
in Europe.  It is a confirmation (although by the same person who
reported it initially).

- ----------------------cut here--------------------------------
Date: Thu, 12 Jan 89 11:04:49 GMT
From: [e-mail]
Subject: Confirmation of nVIR infection
Sender: EARN Macintosh Users List <[e-mail]>

I received confirmation from Text 100 (Microsoft's publicity people in
the UK) that Microsoft's own machine has been infected by nVIR!  Would
anyone who has received a beta copy of WORD 4 (Version 4b10) please
check that they have not infected their systems? it appears that not
all copies were infected for some reason... so don't panic until you
know for sure!  Meanwhile if anyone has Vaccine ine their System
folder and a program either hangs up on loading, or causes the machine
to do a full 'BOMB' with dialog box then suspect nVIR immediately!
Vaccine does not give it's standard report for an attempted infection
by nVIR, but don't ignore what it is doing its best to report!  David
Riddle Editor "Wheels for the Mind (UK)" King's College London

- --------------------------------end of forwarded message---------------------
-

forwarded by:

Jeff Wasilko
BITNET:     jjw7384@ritvax
INTERNET:   [e-mail]
UUCP:       {psuvax1, mcvax}!ritvax.bitnet!JJW7384
Disclaimer: Nobody ever cares what I say...

------------------------------

Date:     Thu, 12 Jan 89 23:56 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  How a worm/virus can trap ctl-alt-del (PC)

>Date:        11 January 89, 20:00:17 +0100 (MEZ)
>From:        Otto Stolz         [phone]     RZOTTO   at DKNKURZ1
>> When a user presses ctl-alt-del, the keyboard code in BIOS [...]
>> redirects interrupt vectors to their default values, then boots. A
>> worm sitting in memory (not a _virus_) would have to duplicate all the
>> machine-specific stuff for various possible machines
>
>What if ... the worm... simply hooks Int 9?

Intercepting ctl-alt-del without intercepting INT 9 would be rather hard :)

Here's another technical explanation:

When a key is hit or released (on an IBM PC or compatible), the
hardware sends an INT 9 to the CPU (I will skip the IRQs, since it's
not relevant). The CPU saves its current instruction pointer on stack
and loads the new one from [4*9]. (Normally, this points to a routine
in ROM BIOS; in some version of DOS intercept this for `stack
management', also many TSRs intercept this interrupt to look for hot
keys; eventually, the control passes to ROM BIOS, or its equivalent
from KEYBxx). The BIOS routine INs a certain port to obtain a 'scan
code' of the key that triggered the interrupt (the scan code has
nothing to do with the ASCII code). If the high bit is set, it's a
break, else it's a make; thus, no more than 128 distinct scan codes
are possible.

The code then analyses what `kind' of key this was. Lots of logic is
involved here. For example, shift-like keys, like shift, ctrl, alt
don't put anything into the keyboard buffer, but set/reset certain
bits; caps/num/scroll lock toggle other bits; for other keys, like 'A'
or '8', these bits are examined to see if one should queue, e.g. upper
or lower case 'a', or '8' or '*'.  Everything is done in the software,
and this approach is highly felxible. One can redefine all the keys,
or replace the entire keyboard code with ease. The location of these
bits (set and reset by the software, I should emphasise) is pretty
standard in all BIOSes. When Ins, Del, or a function key scan code is
encountered, the BIOS queues a special code which the application
program interprets as it wishes. However, there's a special check on
Del key: if the 2 bits for Ctrl and Alt are on (indicating those keys
are pressed), the control is passed (via a jump, so this cannot be
hooked) to the reset code. Now, it's trivial to write code to trap
ctl-alt-del and e.g. to inhibit warm boot. I was tempted to write it
and post it, but it's not worth the trouble, I guess.

>Then it could fake the warm boot by resetting the interrupt vectors
>in a non-standard way that allowed itself to survive in memory and then
>jumping to the booting code.  The machine-specific stuff would only be
>the default values of the interrupt vectors (may be, even they are rather
>standard, or can be derived from the memory contents -- I don't know).

Here's where Otto is dead wrong.  The default interrupt vector values
are, surprisingly, pretty standard across most BIOSes; what you see is
some code, a jump around a 'standard' entry point, and a jump from
there to the relevant routine kilobytes away.

However, I encourage Otto to get hold of (any) Technical Reference
Manual with a BIOS listing and to see what `machine-specific code in
reset' is, or to re-read my previous posting about the boot sequence.

Certainly, if you are planning to affect a very specific
model/manufacturer (and this makes sense in a college micro lab, with
tens of identical machines), you can copy the machine-specific stuff
from the BIOS and reset the interrupt vectors (modulo the ones you
want, like 13 and 9 then) to their default BIOS values. I guess the
only way around it is to 1) avoid machines without a reset button, 2)
cold boot if you use a machine after someone (what I do, if I have
to).

>Or it could infect the disk/diskette to be booted from, and then rely
>on BIOS to be installed again;  the machine specific stuff would be nil,
>and if it was a boot-sector virus, all required subroutines would already
>be part of it.

This is certainly very feasible, except that a disk access immediately
after ctl-alt-del is pressed would look very suspicious. In fact,
Brain should have had this feature. Of course, write-protecting the
disk you boot from would prevent the infection, as usual.

(I hope I am not too hard on Otto---I do not wish to offend him, but I
do wish to express my strong disapproval of people who represent their
fantasies, conjectures and assumptions as facts. This is not a flame.)

- -Dimitri

------------------------------

End of VIRUS-L Digest
*********************


Downloaded From P-80 International Information Systems 304-744-2253