click here to test your IQ

are your IQ good?

Claim Your FREE Gift if you won!


see your IQ(computer) good enough. 100 person who pass untill level 70 will receive YOUR FREE GIFT.


please put your e-mail before you enter.

To follow the path, look to the master, follow the master, walk with the master, see through the master, become the master. ---by weiping ^-^

Friday, July 6, 2007

how to write a virus (basic)

Due to numerous requests for this type of information, I will delve myself into the dark side and release that information by which people can be arrested. Please note that this file contains no source code and no information about destructive code, but simply gives the basic ideas and principles behind writing a reproducing code resource and how it can be used to better society.

Chapter 1: Basic Principles

A computer virus, by definition, is a piece of processor-executable code that can reproduce itself within it's environment. In the Macintosh system, an object called a resource can contain executable code. Most common executable resources are of type 'CODE', along with others such as 'DRVR', 'CDEF', 'WDEF', 'INIT', and so on. These resources are loaded into memory and 'jmp'ed to to be executed (an assembly language term for jump). Note that not only these types listed above can contain code. The trick is to get the virus code loaded and called by 'accident'.

There are many places where code resources are loaded and executed. For one example, at the launch of an application, the CODE resource with ID=0 is loaded (the jump table), and then jumps to the first listing in it's table. As another example, a 'CDEF' resource is called to draw certain controls (ID=0 for buttons, checkboxes, and radio buttons; ID=16 for scroll bars, etc.). Another example: an 'INIT' resource is called at startup time if the file which contains it is in one of the special system folders. There are numerous other places within applications, and even within system software itself, where code is loaded and called. Each virus uses a trick with one of these methods to get itself called. Some of these methods are described in more detail below.

Once the virus code is executed, it's main responsibility is to duplicate itself. This in itself is a fairly easy process. Since your executable code resource is already loaded into memory, you can use a few popular toolbox calls to place it into any other file or application that would suit your needs (where it would also have the chance of being executed). After the duplication is complete, the virus may do any other task it deems necessary. One of the reasons why viruses crash is that their reproduction or startup code is not compatible with other systems and/or machines, not that their damage system actually did any damage. If you write code following the Inside Macintosh rules and code defensively, you should be able to write a clean piece of code that travels without problems. Always code defensively: it's your work out there you want to be proud of it. Read below to find some tips on doing just that.

Virus testing is a very difficult process, in that your own system is constantly infected, possibly numerous times with older versions of the virus. There are methods to the madness, so again, read on.

A few of the catches to writing a virus is being aware of the methods used by virus-protection software. If simply written, a virus could be caught very quickly and not have much effect beyond your own system. If the methods are thought out and the patches made by the protection software are understood, then a virus could at least require software companies to update their existing detection methods. Every virus to date has been able to be detected and destroyed, so don't feel bad.

Is everybody happy? Then let's go!

Chapter 2: Writing Executable Code

An executable code resource is easy to create with a good software-development application such as THINK C (or C++) or THINK Pascal or MPW. There are slight differences between the environments, but nothing major. I will be giving examples for code written in THINK C, for that is the system I use.

An executable code resource usually starts with a

 void main(void)

and within such, your executable code exists. Note, as always, that executable code cannot handle global variables (variables defined above the definition of the main code, accessible by the whole file/project). THINK C handles ways around this, and MPW uses the methods in Tech Note #256, but in most cases, you won't really need global variables, unless the code is complex enough to require separate procedures and/or object-oriented code. In any case, you can usually define your variables inside the main procedure itself. There aren't too many rules as far as writing code resources, so long as you know under which circumstances your code will be called. If you are patching a Toolbox trap, for example, you must take the same form as the patch you are trapping:

 void ModalDialogPatch(ProcPtr procFilter,int *itemHit)

If you are patching an operating system trap, you need to do some register playing, but you need to take an empty procedure form:

 void OpenPatch(void)

even though the FSOpen, PBOpen, etc. take paramBlocks. Note: they are stored in registers A0, D0, and A1 usually. Check the trap for specifics. You need to save these before you execute your code, and then restore them upon return.

If you are executing code that is to be run as a VBL or Time Manager task, always remember that you cannot use code that even thinks about using the Memory Manager (i.e. moves or purges memory). Make sure all the toolbox calls you use are not in the 'dreaded list' in the appendix of each volume of Inside Macintosh.

The type of the code resource is very dependent upon which method you wish to use to get your code executed. Read the next section for details on such execution theories.

After you're done writing the code, check it over for simple things you might have forgotten (original Quickdraw compatibility, system versions, etc.), and compile the sucker. For right now, you can throw the code resource into some sort of test file (or stagnant file, where the code will not be executed and/or reproduce). Note that you should NOT have any external resource files to compile along with it. Code resources such as this should preferably be self-contained, and not have to 'carry around the extra luggage', so to speak. There are methods to carry along bitmaps (as 'unknown data') and use them as graphics. But you should never rely on things like GetNewDialog, because that requires the existence of a DITL resource. Instead, use calls like NewDialog, where the code builds the relevant information in. It might make things harder to read and a bit harder to edit, but it's what you have to do in order to make everything self-contained.

Most of the compilers create some sort of header at the beginning of each executable code resource. This header could give away some vital information about the resource which would make it easy for a virus-detector to find. Double check it after compilation to make sure it's clean and doesn't look suspicious.

Chapter 3: Getting Your Code Executed

This technique you use here defines how your virus spreads. Some earlier viruses were more virulent than others; nVir needed an infected application to boot for it to execute; WDEF required only that a disk be inserted. There are lots of places for code to be "patched" so that your code can be executed. The trick is finding them and recovering from them gracefully. Not every method can be discussed in this note, but I will give some general examples and how to find your own 'hooks'.

One of the most popular methods amongst virii is infecting applications, since they, by definition, have executable code built right into it. If you can get your code executed along with the many other little segments in the application, the code could recover undetected. When an application starts up, the resource CODE with ID=0 is loaded into memory, and it's popularly known as the jump table. It keeps track of all of the procedures or segments in an application. If part of an application needs to call another procedure inside the application, it checks with the jump table for it's location. If it sees that the procedure is not in memory, it will load it first, then execute it. This is all taken care of by the compiler and the system software, so it's invisible to the programmer (in most cases). The system loads the jump table and immediately executes the first entry in the list when an application begins.

You can patch yourself into this list of procedures by modifying the jump table itself. You can modify the first entry of the jump table to be your code, but save the original entry so that you can call the actual application when you're done (destroying the first entry in any CODE 0 resource renders the application totally useless). So, instead of the system executing what it thinks is the application, it will run your code first, and then run the application.

Another method by which virii get executed is by utilizing a wonderful feature of the Resource Manager. As given in Inside Macintosh volume 1, the Resource Manager will look for resources in the top-most resource file that is open (the one most recently opened in most cases, unless UseResFile has been used). These searches also include searches for basic system code resources, such as window definitions, control definitions, and even international transliteration code. If you have a resource with the same type and ID as one in the system, and this resource file is open, the system will execute your resource instead of the system's. The catch again with this is that you should call the original resource as well to make your code invisible to the naked eye. This, apparently, is how the WDEF virus worked. When a disk was inserted, the desktop file was automatically opened and put in the list of resource files. Within this time that the file was open, the WDEF file which existed within was executed (the system needed to draw the window itself using the standard WDEF resource). This method requires no patching of other code and makes it very elegant. The thing that makes them easy to detect is that you find code resources in very odd places. A WDEF resource is not usually found in the desktop file.

To find other hooks for code execution, look at all the executable code inside the system. These pieces are executed at one time or another for certain calls. Things that might not seem obvious right away may make good places for patching. Lots of applications use (maybe indirectly) the International Utilities Package, for it has many good string manipulation routines. A patch there might be possible. 'ptch' resources in the system are loaded automatically at startup time to patch bits of ROM. A system could be infected there and be loaded before all other extensions. Poke around the resources and find out which ones are executable, and then find out when they are executed. You might be able to find a great patch to live off of.

Chapter 4: Reproduction

Reproduction of any code resource requires the help of the File Manager and/or the Resource Manager. The concept is not very simple, but the execution is very easy. Since the virus itself is simply one code resource (preferably not more than one), then it can be loaded, added, modified, changed, and saved just like any other resource. And the fun part of it is, you can do all this to the code you are currently executing. This is apparently dangerous (Apple warns us about self-modifying code), but we're not modifying anything about our code; simply our placement. With a few simple calls we can duplicate ourselves anywhere we wish.

When an executable code resource is called, the pointer to the resource is placed in register A0. You can use this pointer to reference yourself. A simple line of assembly can place A0 in any variable you choose. Once you have this variable, you must translate it into a handle with the RecoverHandle call. Now you have a handle to your own loaded resource, but you still cannot duplicate it. As a handle to a resource, you cannot use it to be copied into other files. You 'belong' to your owning file, and are not expected to go elsewhere. Use the DetachResource call to remove your reference to the file you came from. After this call, you are simply an executable block of memory floating around with a handle on yourself (phallic, isn't it?). All you need to have to have total freedom with a block of memory is a handle to it. You've got this free handle now. Now comes the time to find the file you have to duplicate yourself to.

The file you find depends on how your virus is designed to work. You can copy yourself into applications, into desktop files, or into the system. Again, dependent on how your executing mechanism requires it. Once you have found your file (usually with use of the File Manager), open up it's resource fork with OpenResFile or any other similar procreation of it (FSpOpenResFile, etc.). Call AddResource with the required parameters, then call WriteResource to forcefully write the resource to the file or simply close the file itself (it will automatically be saved). Your code has now copied itself into another file. Reproduction! Now just let it sit and wait for it to be called!

Chapter 5: Defensive, Clean Coding

As always, if you want your code to be run cleanly on all systems, you have to be prepared for any type of situation. Apple warns us of this all the time, so I don't have to go into too much detail, but there are a few things I would like to stress so that your code doesn't simply crash when it gets executed. You goal is then not found. Here are some tips and things to watch out for.

  1. ResError. Who knows? Maybe you've been purged. Check it after every Resource Manager call you can, taking efficiency into account, of course.
  2. Nil pointers. Who knows? Maybe a virus detector caught part of your set of resources (if you're using a set, which I highly discourage) and deleted them. Find an alternate route, or exit gracefully.
  3. Patch well. If you are going to modify something like a jump table, be sure you keep the originals somewhere for your own use so you can call the code (pass-through coding). If you don't, and you just destroy it and call the next code resource down the line, who knows what you might be calling. A bezier-curve calculation routine does nothing if the caller knows not what he's doing.
  4. File Manager. Don't depend on each hard drive being called "Macintosh HD". Don't depend on an "Applications" folder. Don't depend on anything. Read the directory and see what you find interesting. System 7's File Manager is great, but watch out for:
  5. System 6 or before. You wouldn't want your code to execute only on one system version now, would you? By known figures, only 50% of Mac users use System 7. Sad, eh? But why exclude them from the pleasures of your code?
  6. Error Check, Error Check, Error Check. The thought police are on you again. Never forget that nothing is permanent.

Chapter 6A: Virus Protection Software: How It Works

Virus protection software was a good idea. It worked for a while. Then it became a commercial product. Virex, SAM, etc. The best one out in the world today is freeware: Disinfectant. A beautifully-written piece by John Norstad. I personally am against commercially-written virus protection. However, I am not here to give praise to independent software authors. I am here to tell you how some of their mechanisms work.

Patching toolbox traps is a popular method of modifying the system's own code. Before it calls the real thing, it calls the patch (your code). Virus detectors use this method to keep an eye out for parameters passed through certain toolbox calls to check to see if they are virus-related.

One popular patch is AddResource. If a virus detector sees that the type of resource that is being added is of type 'nVir', then it'll catch you. If it sees 'WDEF' with ID=0 and the open resource file is the desktop, then it'll catch you. Since AddResource is a very dependent call used for replications, it's almost certain to work every time. Other less-popular but more efficient patches are those at the base level of the operating system, not even documented by Apple. Traps such as _vBasicIO, _VInstall, _NewHandle, _vMRdAddr, and even _ADBReInit get trapped by the Disinfectant extension. Because these are very basic calls (used by nearly anything that does input and output, in the case of _vBasicIO), it can catch nearly anything coming toward it. It's nearly foolproof. After knowing what type of virus it is, the software can delete the virus quickly and easily.

Good applications also use their own version of virus protection. At the startup of their application, the number of resources in the file is counted, and the more important executable resources in the file are checked for their size. This way, if an application has had a resource added, it will be able to alert the user and stop execution.

Chapter 6B: Virus Protection Software: How To Bypass It

Though virus protection is great in most cases, there are still 'back doors' which haven't been explored at the time of this writing. Here are some ideas for getting around the checks that most virus protection software uses.

A trap is still a trap. It is not the real code; it is a dispatcher. It stops you on the way there, but it doesn't stop you from doing what those basic calls do on your own. This does require a fair amount of assembly language and ROM copying, but it gets you around the catch of using operating system traps at all. Simply copy the code that is contained in the trap itself and use that code. To never get caught, never use traps. But we know how nearly impossible that is. However, things are gained and lost in good code writing.

A drawback of virus protection in general is that the software has to be continually updated for each new virus and identified by name in most cases. One ingenious idea (mine? I don't know) is to make the name and/or type of the virus variable. It doesn't always have to be called 'nVir' or 'WDEF' (unless the mechanism depends on the name or type). Make the type change from permutation to permutation. This makes it much more difficult to catch.

One feature of the File Manager is it's automatic updating of the modification dates. Every time a file is updated or modified in any way, the modification date is changed. You can find and modify the date with a fairly simple low-level File Manager call. This is really a frivolous precaution, but it makes it easy to find the source of a virus attack. Changing the dates to something fairly feasible (NOT Jan. 1, 1904) may bypass such checks.

The application checks can be overridden with good code-writing as well. If the virus is to add a resource to a file (as it usually has to), why not delete one in it's place? You've got to be sure that the type is the same as another type (this is where the variable types come in handy), and you may even want to vary the size of it to make it match the one it replaced (hopefully a larger size). Simply modifying a resource (like CODE 0) with the same amount of bytes will usually not be detectable. This way, the applications still counts and finds nothing unusual. However, in the process, the application is permanently damaged in some way.

Chapter 7: Testing

In testing a virus on your own system, you subject it to many continuous attacks - maybe even ones that are unintended. There are some rules to follow to be sure that you can keep track of it's location and make sure it doesn't destroy your work in the process.

  1. SysBeep debugging. I'm sure most of us a pretty familiar with this technique. It's compatible on all systems, and it's an aural identification. No visuals to set up, no extra resources. Simple SysBeep(0); is sometimes enough to know that everything's all right. When testing your duplication code to find out when it actually happens, use SysBeep after each one and then check to see where it went.
  2. Modification dates and times. If you use random selection of files to infect, it becomes rather difficult to find which one got infected. If you know when an infection happened, you can immediately check the modification dates of all files - simply by using the Find command in System 7's Finder.
  3. Text Files. This could be known as a common-file technique. For testing purposes, use a mechanism that whenever an infection takes place, the virus writes the process and the file names and such into a common file in a common folder somewhere. This way, you can check the text file afterwards and know exactly what your code has done. You need not make the mechanism too elaborate, as it will only be for use in testing.
  4. Backup, Backup, Backup. The thought police are at it again. In these cases, it's all too familiar. A trashed project is no fun.

Chapter 8: Conclusion

In short, the devices behind writing a virus are not all that complicated. There are many checks to counterattack, and part of the puzzle itself is no find new ways to get around them. Find back doors. Give the code a personality. Make it try to find the best way around a counterattack if it is able to detect one. Size is no longer a constraint in today's memory-hog world. A virus of near 50k would probably go undetected in modern-day storage, so don't feel constrained in that way. Time should be a consideration, however.

Make code that is efficient, so that users don't notice a slowdown when it is executed. All in all, your code is your work. Don't let it out of the bag until it works well and clean, and don't forget to leave no trace.

Friday, June 22, 2007

SUNSET AND A CONCLUSION

We arrived at the beach at about 6.30 in the evening. My cousin parked the car under a tree and we got out.

The smell of the sea was unmistakable. A gentle breeze blew. I step out my sandals onto the soft sand, like i was in heaven.

My cousin, two of my friends and i had come to the seaside just to watch the sun set. My cousin assured us that we would not be disappointed for he had seen it setting before and he said it was beautiful. We just had to see for our own.

We sat on the sand and gazed at the western horizon. White and grey clouds began to change colour.

First they took on orange hues. Then the shades of red and yellow could be seen. In the short time the whole western sky seem to be ablaze with splash of gold, red ,orange and yellow. I gazed at the spectacle in wonder. What a magnificent sight it was! I tired to focus on a particular part of the colourful scene but I found that the colours were constantly changing. They changed very slowly and subtly although the scene appeared very still. A streak of gold here turned yellow and a splash of red there dissolved into hues of orange. It was quite impossible to describe really this great wonder of nature in action.

Shortly the hues became darker and hits of black were visible. The sun slowly sink into the sea. However the sky remained reddish even though the sun could no longer be seen.

Suddenly, everything was dark. The sun had set and night took over. I became aware of mosquitoes attacking me. My cousin said it was time to go home.

We got into car. Indeed the sunset had been a wonderful experience. At that day, I had a conclusion that is --wonderful time is just a second, so we must appreciate it. Don't let it pass away in a meaningness way~~~~~

Thursday, June 21, 2007

JUST ONCE...

I did my best

But I guess my best wasn't good enough

'Cause here we are back where we were before

Seems nothing ever changes

We're back to being strangers

Wondering if we oughta stay

Or head on out the doorJust once can't we figure out what we keep doing wrong

Why we never last for very long

What are we doing wrong

Just once can't we find a way to finally make it right

Make the magic last for more than just one night

If we could just get to it

I know we could break through itI gave my all

But I think my all may have been too much

'Cause Lord knows we're not getting anywhere

Seems we're always blowing whatever we got going

And seems at times with all we've got

We haven't got a prayer

Just once can't we figure out what we keep doing wrong

Why the goodtimes never last for very longSeems we're always blowing

Whatever we got goingJust once can't we find a way to finally make it right

Make the magic last for more than just one night
If we could just get to itI know we could break through it
Just once I want to understandW
hy it always come back to good-bye
Why can't we get ourselves in hand
And admit to one another
That we're no good with out the other
Take the best and make it better
Find a way to stay together
Just once can't we find a way to finally make it right
Make the magic last for more than just one night
I know we can break through it
If we could just get to it
Just once
If we could get to it
Just Once...

Friday, June 15, 2007

Student Study Just To Pass Examinations. Do You Agree?

I agree fully with the above statement. I am a student and I study just to pass the examinations. It seems the same with my schoolmates. We are all only concerned with the examinations. We do not study other things that do not require us to sit for examinations.
The reason that we do not study other things is because we have no time for them. School subjects take up all our time in school and much of our time in school and much of our time of school. Everyday we have to learn so many things whether we like it or not. Lesson continues one after the other with hardly a break. Our brains switch from history to geography to mathematics to science with a speed of light. We manage most of the time, but sometimes it get so tiring to study, and many of us think to put off our study. For me, any initial interest I have in any subject is quickly killed off by the sheer amount of information I have to absorb. No one is allowed to learn his or her own pace. Everyone is force-fed a diet of information regardless whether he or she can cope with it or not (haiz…so pity the one’s who study…).
Then there is always the next examination around the corner. Since very young we have been taught this: passing with flying colors an examination is the best, just passing it is just a normal statement, but failing is very bad indeed. We are expected to pass. Our parents, teachers and all grown-ups applaud us when we pass with flying colors. If we pass they say nothing, but when we failed we are made to fell worthless. I myself have been caned by my mother because I got red marks in my report card (but in secondary I have improved better!).
No one wants to be considered worthless or be punished for failure, but that is what the world is. So we become obsessed with examinations. We study because we do not want to fail. I have heard some teachers’ say that we should study to acquire in my years in school is that if I fail I am finished. I have to pass with flying colors to prove that I am not worthless.
That is how I feel. For some of my classmates who cannot cope well with the workload, they simply give up studying in some subjects. They are already marked as failures by the teachers so they see no point in studying anymore ,but some teacher always teaches them, help them on their homework, support them but the hard work seems have no effect on them, maybe they are meant to failed. Lucky I do not fall in that category. I still study and do my homework as diligently as I can, but I do these things with only one thing in mind and that is: I have to pass my examinations with flying colors.
So the students study very hard indeed. Passing means success in the world. Failure is unspeakable. The fact remains that they study not for the sake of knowledge but only so that they can pass the next examinations. I am no different from them.

Monday, June 11, 2007

Should Homework Be Abolished?

It is very easy to answer ‘yes’ to the above question, especially when one is loaded with homework up to the neck. However I will not say that homework should be abolished. It is useful in many ways, I will say that homework should be given discreetly.
Every teacher ought to realize that other teachers are also giving homework. So if five different teachers come into the class and all of them give us homework, then we will have five different sets of homework to do!
It is already a full-time job concentrating on what each teacher tells us in class. So by the time we reach home, all we want to do is to flop into bed and take a nice nap. The nap normally is filled with dreams about unfinished homework and question. After lunch it is usually back to work trying to finish the assignments or folio projects before evening comes and we go out to play or rest for a while.
However, the homework cannot be done in one sitting. This is especially so when we get stuck in mathematics problem and can see no way through. So after homework and try to do work once again to complete the homework and try to do some studying as well. Sometimes the going gets so overwhelming that the only sane thing left to do is to quit and do some-thing else, like watching television or playing computer games(example from me ,hacking, cracking, surfing the internet.)
This year, “fortunately”, most of our teachers are very “understanding”. They realize that we are sitting for the PMR examinations. So they give us homework. Our geography teacher is the best, his name was Mr. Ooi Chong Oui. He seldom give us homework and he always ask us the time (example: “what time is it now?” say Mr. Ooi. Then a student reply: “it is only left 5 minutes Sir” then he continue: “ok you all can rest now”. What a “wonderful” teacher we thought. ) Bless him for his kindness.
Science is an entirely different matter. Our teacher believes us in grinding us with as many problems as possible. I “appreciate” the fact that practice make perfect in science. However I wish that she could take it easy a little bit so that we do not feel so tense and overworked. It is necessary to do homework in science but it is unnecessary to do excessive amounts of it. This is where the discretion of the teacher is most important. But who am I to comment on what is considered discreet or not? It is totally up to the teacher. Many of my classmates hate science because all the homework that the teacher gave. Thus many of them failed at the test (but not included me because I pro at science. Hehe….). They simply not bothered anymore with it. They just sit quietly every time they are chastised and punished by the fuming teacher for not doing her homework (example of her punishment: “do you have heart attack or asthma?” as her. “No” the student reply. “ok now pumping 10 times” continue by her. ). They show no concern at all for the result.
Doing homework is never a pleasant affair. If the volume of homework is manageable then they can be done efficiently and quickly. In this way we do learn from our labour. If the homework is overwhelming then we learn nothing expect that we are simply fed up. I believe then that we should not abolished homework completely. The best thing to do is for the teacher to seriously consider the student’s welfare before any homework is given. Homework should be aid the student to learn not do the opposite. Homework look like food, if taken in moderate quantities, it nourishes, but if taken in excessive amount, it might kill person.(but I hope there will be no homework given by the teachers again, and all the exam also should be abolished. Hahaha…)

Sunday, June 10, 2007

ENCRYPTE

In cryptography, encryption is the process of transforming information (referred to as plaintext) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key. The result of the process is encrypted information (in cryptography, referred to as ciphertext). In many contexts, the word encryption also implicitly refers to the reverse process, decryption (e.g. "software for encryption" can typically also perform decryption), to make the encrypted information readable again (i.e. to make it unencrypted).
Encryption has long been used by militaries and governments to facilitate secret communication. Encryption is now used in protecting information within many kinds of civilian systems, such as computers, networks (e.g. the Internet e-commerce), mobile telephones, and bank automatic teller machines. Encryption is also used in digital rights management to restrict the use of copyrighted material and in software copy protection to protect against reverse engineering and software piracy.
Encryption, by itself, can protect the confidentiality of messages, but other techniques are still needed to verify the integrity and authenticity of a message; for example, a message authentication code (MAC) or digital signatures. Standards and cryptographic software and hardware to perform encryption are widely available, but successfully using encryption to ensure security is a challenging problem. A single slip-up in system design or execution can allow successful attacks. Sometimes an adversary can obtain unencrypted information without directly undoing the encryption. See traffic analysis, TEMPEST.

History
Encryption has been used to protect communications since ancient times, but only organizations and individuals with extraordinary need for confidentiality had bothered to exert the effort required to implement it. Encryption, and successful attacks on it, played a vital role in World War II. Many of the encryption techniques developed then were closely guarded secrets. (Kahn) In the mid-1970s, with the introduction of the U.S. Data Encryption Standard and public key cryptography, strong encryption emerged from the preserve of secretive government agencies into the public domain.

Ciphers
In cryptography, a cipher (or cypher) is an algorithm for performing encryption and decryption — a series of well-defined steps that can be followed as a procedure. An alternative term is encipherment. In most cases, that process is varied depending on a key which changes the detailed operation of the algorithm. In non-technical usage, a "cipher" is the same thing as a "code"; however, the concepts are distinct in cryptography. In classical cryptography, ciphers were distinguished from codes. Codes operated by substituting according to a large codebook which linked a random string of characters or numbers to a word or phrase. For example, UQJHSE could be the code for "Proceed to the following coordinates".
The original information is known as plaintext, and the encrypted form as ciphertext. The ciphertext message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it.
The operation of a cipher usually depends on a piece of auxiliary information, called a key or, in traditional NSA parlance, a cryptovariable. The encrypting procedure is varied depending on the key, which changes the detailed operation of the algorithm. A key must be selected before using a cipher to encrypt a message. Without knowledge of the key, it should be difficult, if not impossible, to decrypt the resulting cipher into readable plaintext.
Most modern ciphers can be categorized in several ways:
By whether they work on blocks of symbols usually of a fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers).
By whether the same key is used for both encryption and decryption (symmetric key algorithms), or if a different key is used for each (asymmetric key algorithms). If the algorithm is symmetric, the key must be known to the recipient and to no one else. If the algorithm is an asymmetric one, the encyphering key is different from, but closely related to, the decyphering key. If one key cannot be deduced from the other, the asymmetric key algorithm has the public/private key property and one of the keys may be made public without loss of confidentiality. The Feistel cipher uses a combination of substitution and transposition techniques. Most (block ciphers) algorithms are based on this structure.

Etymology of "cipher"
"Cipher" is alternatively spelled "cypher"; similarly "ciphertext" and "cyphertext", and so forth. It also got into Middle French as cifre and Medieval Latin as cifra, from the Arabic sifr (zero).
The word "cipher" in former times meant "zero" and had the same origin (see Zero - Etymology), and later was used for any decimal digit, even any number. There are these theories about how the word "cipher" may have come to mean encoding:
Encoding often involved numbers.
Conservative Catholic opponents of the Arabic numerals equated it with any "dark secret".[citation needed]
The Roman system was very cumbersome because there was no concept of zero or (empty space). The concept of zero (which was also called "cipher"), which we all now think of as natural, was very alien in medieval Europe, so confusing and ambiguous to common Europeans that in arguments people would say "talk clearly and not so far fetched as a cipher". Cipher came to mean concealment of clear messages or encryption.
The French formed the word "chiffre" and adopted the Italian word "zero".
The English used "zero" for "0", and "cipher" from the word "ciphering" as a means of computing.
The Germans used the words "ziffer" and "chiffer".
Dr. Al-Kadi (ref-3) concluded that the Arabic word sifr, for the digit zero, developed into the European technical term for encryption.

Ciphers versus codes
In non-technical usage, a "(secret) code" is the same thing as a cipher. Within technical discussions, however, code and cipher are distinguished as two concepts. Codes work at the level of meaning — that is, words or phrases are converted into something else and this chunking generally shortens the message. Ciphers, on the other hand, work at a lower level: the level of individual letters, small groups of letters, or, in modern schemes, individual bits. Some systems used both codes and ciphers in one system, using superencipherment to increase the security.
Historically, cryptography was split into a dichotomy of codes and ciphers, and coding had its own terminology, analogous to that for ciphers: "encoding, codetext, decoding" and so on. However, codes have a variety of drawbacks, including susceptibility to cryptanalysis and the difficulty of managing a cumbersome codebook. Because of this, codes have fallen into disuse in modern cryptography, and ciphers are the dominant technique.

Types of cipher
There are a variety of different types of encryption. Algorithms used earlier in the history of cryptography are substantially different from modern methods, and modern ciphers can be classified according to how they operate and whether they use one or two keys.
Historical pen and paper ciphers used in the past are sometimes known as classical ciphers. They include simple substitution ciphers and transposition ciphers. For example GOOD DOG can be encrypted as PLLX XLP where L substitutes for O, P for G, and X for D in the message. Transposition of the letters GOOD DOG can result in DGOGDOO. These simple ciphers are easy to crack, even without plaintext-ciphertext pairs.
Simple ciphers were replaced by polyalphabetic substitution ciphers which changed the substitution alphabet for every letter. For example GOOD DOG can be encrypted as PLSX TWF where L, S, and W substitute for O. With even a small amount of known plaintext, polyalphabetic substitution ciphers and letter transposition ciphers designed for pen and paper encryption are easy to crack.
During the early twentieth century, electro-mechanical machines were invented to do encryption and decryption using a combination of transposition, polyalphabetic substitution, and "additive" substitution. In rotor machines, several rotor disks provided polyalphabetic substitution, while plug boards provided transposition. Keys were easily changed by changing the rotor disks and the plugboard wires. Although these encryption methods were more complex than previous schemes and required machines to encrypt and decrypt, other machines such as the British Bombe were invented to crack these encryption methods.
Modern encryption methods can be divided into symmetric key algorithms (Private-key cryptography) and asymmetric key algorithms (Public-key cryptography). In a symmetric key algorithm (e.g., DES and AES), the sender and receiver must have a shared key set up in advance and kept secret from all other parties; the sender uses this key for encryption, and the receiver uses the same key for decryption. In an asymmetric key algorithm (e.g., RSA), there are two separate keys: a public key is published and enables any sender to perform encryption, while a private key is kept secret by the receiver and enables only him to perform decryption.
Symmetric key ciphers can be distinguished into two types, depending on whether they work on blocks of symbols of fixed size (block ciphers), or on a continuous stream of symbols (stream ciphers).


Key size and vulnerability
In a pure mathematical attack (i.e., lacking any other information to help break a cypher), three factors above all, count:
Mathematical advances, that allow new attacks or weaknesses to be discovered and exploited.
Computational power available, i.e. the computer power which can be brought to bear on the problem.
Key size, i.e., the size of key used to encrypt a message. As the key size increases, so does the complexity of brute search to the point where it becomes infeasible to crack encryption directly.
Since the desired effect is computational difficulty, in theory one would choose an algorithm and desired difficulty level, thus decide the key length accordingly.
An example of this process can be found at keylength.com which uses multiple reports to suggest that a symmetric cypher with 128 bits, an asymmetric cypher with 3072 bit keys, and an elliptic curve cypher with 512 bits, all have similar difficulty at present.
Claude Shannon proved, using information theory considerations, that any theoretically unbreakable cipher must have keys which are at least as long as the plaintext, and used only once: one-time pad.

Tuesday, June 5, 2007

poem out of a colour words

Once bitten, twice SHY.
Twice bitten, never TRY.
Thrice bitten, go and DIE!
by wei ping

Saturday, June 2, 2007

BLACK HAT

A black-hat is a term in computing for someone who compromises the security of a system without permission from an authorized party, usually with the intent of accessing computers connected to the network. The term cracker was coined by Richard Stallman to provide an alternative to using the existing word hacker for this meaning. The somewhat similar activity of defeating copy prevention devices in software which may or may not be legal in a country's laws is actually software cracking.

Terminology
Use of the term "cracker" is mostly limited (as is "black hat") to some areas of the computer and security field and even there is considered controversial. Until the 1980s, all people with a high level of skills at computing were known as "hackers". A group that calls themselves hackers refers to "a group that consists of skilled computer enthusiasts". The other, and presently more common usage, refers to those who attempt to gain unauthorized access to computer systems. Over time, the distinction between those perceived to use such skills with social responsibility and those who used them maliciously or criminally, became perceived as an important divide. Many members of the first group attempt to convince people that intruders should be called crackers rather than hackers, but the common usage remains ingrained. The former became known as "hackers" or (within the computer security industry) as white hats, and the latter as "crackers" or "black hats". The general public tends to use the term "hackers" for both types, a source of some conflict when the word is perceived to be used incorrectly. In computer jargon the meaning of "hacker" can be much broader.
Usually, a black hat is a person who uses their knowledge of vulnerabilities and exploits for private gain, rather than revealing them either to the general public or the manufacturer for correction. Many black hats hack networks and web pages solely for financial gain. Black hats may seek to expand holes in systems; any attempts made to patch software are generally done to prevent others from also compromising a system they have already obtained secure control over. A black hat hacker may write their own 0-day exploits (private software that exploits security vulnerabilities; 0-day exploits have not been distributed to the public). In the most extreme cases, black hats may work to cause damage maliciously, and/or make threats to do so as blackmail.

Methods
Techniques for breaking into systems can involve advanced programming skills and social engineering, but more commonly will simply be the use of semi-automatic software, developed by others — often without understanding how the software itself works. Common software weaknesses exploited include buffer overflow, integer overflow, memory corruption, format string attacks, race conditions, cross-site scripting, cross-site request forgery, code injection and SQL injection bugs.

Friday, June 1, 2007

The Dead Pigeon

The Dead Pigeon
He saw a dead pigeon
in a drain
near the post office.
He saw citizens
hidding in a shady place
in a land full with blood.
Why should we suffer like this?
I want a peaceful place
for my grandchildren.
I want the damned fools
to leave our country alone.
I want watch my children to grow,
children play happily in this land,
and the earth covered with smile.
Now and always.
Peace is a dream---weiping

Thursday, May 31, 2007

COMPUTER WORMS

(the figure above show a computer worm ^^)

A computer worm is a self-replicating computer program. It uses a network to send copies of itself to other nodes (computer terminals on the network) and it may do so without any user intervention. Unlike a virus, it does not need to attach itself to an existing program. Worms always harm the network (if only by consuming bandwidth), whereas viruses always infect or corrupt files on a targeted computer.

Naming and history
The name 'WORM' comes from The Shockwave Rider, a science fiction novel published in 1975 by John Brunner. Researchers John F Shoch and Jon A Hupp of Xerox PARC chose the name in a paper published in 1982; The Worm Programs, Comm ACM, 25(3):172-180, 1982), and it has since been widely adopted.
The first implementation of a worm was by these same two researchers at Xerox PARC in 1978.Shoch and Hupp originally designed the worm to find idle processors on the network and assign them tasks, sharing the processing load, and so improving the 'CPU cycle use efficiency' across an entire network. They were self-limited so that they would spread no farther than intended.

Payloads
Many worms have been created which are only designed to spread, and don't attempt to alter the systems they pass through. However, as the Morris worm, and Mydoom showed, the network traffic and other unintended effects can often cause major disruption. A "payload" is code designed to do more than spread the worm - it might delete files on a host system (eg the ExploreZip worm), encrypt files in a cryptoviral extortion attack, or send documents via e-mail. A very common payload for worms is to install a backdoor in the infected computer to allow the creation of a "zombie" under control of the worm author - Sobig and Mydoom are examples which created zombies. Networks of such machines are often referred to as botnets and are very commonly used by spam senders for sending junk email or to cloak their website's address.Spammers are therefore thought to be a source of funding for the creation of such worms, and worm writers have been caught selling lists of IP addresses of infected machines.Others try to blackmail companies with threatened DoS attacks.
Backdoors, however they may be installed, can be exploited by other malware, including worms. Examples include Doomjuice, which spreads using the backdoor opened by Mydoom, and at least one instance of malware taking advantage of the rootkit backdoor installed by the Sony/BMG DRM software utilized by millions of music CDs prior to late 2005.

Worms with good intent
Beginning with the very first research into worms at Xerox PARC there have been attempts to create useful worms. The Nachi family of worms, for example, tried to download and install patches from Microsoft's website to fix vulnerabilities in the host system — by exploiting those same vulnerabilities. In practice, although this may have made these systems more secure, it generated considerable network traffic, rebooted the machine in the course of patching it, and, most importantly, did its work without the consent of the computer's owner or user.
Most security experts regard all worms as malware, whatever their payload or their writers' intentions.

Protecting against Dangerous computer worms
Worms mainly spread by exploiting vulnerabilities in operating systems, or by tricking users to assist them.
All vendors supply regular security updates-- "Patch Tuesday", and if these are installed to a machine then the majority of worms are unable to spread to it. If a vendor acknowledges a vulnerability but has yet to release a security update to patch it, a zero day exploit is possible. However, these are relatively rare.
Users need to be wary of opening unexpected email, and should not run attached files or programs, or visit web sites that are linked to such emails. However, as the ILOVEYOU worm showed, and as phishing attacks become more efficient, tricking users will always be possible.
Anti-virus and anti-spyware software are helpful, but must be kept up-to-date with new pattern files at least every few days.

what are your views on gambling and its effects?

Gambling is a social ill. Together with alcoholism and drug addiction, they constitute the major problems that societ) is facing now.
In our country, gambling is widespread. Legally a person can patronise the 4-digit shops, the turf clubs and the casino at Genting Highlands. Illegally a person can patronise a multitude of gambling operations run by thugs and racketeers. Be it legal or illegal, gambling is big business that does not show any sign of abating.
If we just look into one of the many 4-digit shops when it is open, we will no doubt see a crowd of peopi jostling with one another to buy their numbers. Often so numbers are sold out very quickly. There are also certain 'hoc numbers that the shops refuse to sell, for they have a habit being drawn often
Just why is it that people willingly spend their hap earned money on pieces of paper that are designed to ma money for the operators?
The reasons are complex. However one of I: friends, who buys 4-digit tickets regularly, gave me a rea on why he gambles. He told me that he started buying cert, numbers hoping to win a prize. As time went by the numb still did not come out. After a year of buying the numbers could not possibly stop. He feared that if he stopped, one his numbers might come out and he would have missed chance. He would have lost a lot of money. He figured it stupid to invest so much money only not to win any in ret because he did not buy the numbers at one particular draw
So he keeps on pumping his money on a shaky jream. Even If he wins something eventually, most likely his .vinnings cannot cover the amount he has "invested" He is a :ertain loser.
I suppose many other punters share his opinion. They :annot stop. They have staked too much already. In short, :hey are hooked
So these gamblers carry on regardless what happens -.0 them. I have heard of people who borrow money to gamble . Some of them even steal to finance their gambling needs. I -c:now a friend who gambled his college fees away on horse-
-acing. His father gave him a proper lecture and he promised
:0 repent. Alas, he never did. His father had to personally pay all the fees. Even so, this chap somehow or other would get some money from somewhere just to visit the turf club. He is Jerpetually broke. We avoid him like the plague. He is an example of a person who would do almost anything to feed ~.is gambling habit He has cried and lamented in front of me 'or a few ringgit. He has no dignity left. I do not know what to :0 with him except give him some advice. Advice is of no avail anyway.
Such is the state of hard-core gamblers. They have ost touch with reality. They are living in a world of shattered ~opes and dreams They convert their houses into all-night ,ahjong dens. They neglect their families and involve :nemselves in illegal activities They sometimes dwell in black ~agic to ask for "luck" and favours in their gambling pursuits, -,at realising they are virtually selling their souls to the devil.
-heir lives deteriorate Their relationships with friends and
'amilies become strained. They are strangers onto others and :nto themselves.
Without a strong will and some outside help, an addicted gambler has very little hope of getting out of his :redicament. Unless he changes his attitudes and lifestyle he ,'Iould probably carry on as he has always been doing. He will -at find any happiness anywhere. Gambling can give him nothing but grief

Shattered lives, broken homes, poor health, poverty and overwhelming problems follow the person who becomes

Hacker

Hacker is a term often applied to computer software or computer hardware programmers, designers and administrators, especially those who are perceived as experts or highly accomplished in this field. A hacker is also a term used for someone who modifies electronics such as ham radio transceivers, printers or even home sprinkler systems for better functionality or performance. The term usually bears strong connotations that may be favorable or pejorative depending on cultural context (see the hacker definition controversy).
In computer programming, a hacker is a software designer and programmer who builds programs and systems that garner the respect of one's peers. A hacker may also be a programmer who reaches a goal by employing a series of modifications to exploit or extend existing code or resources. For some, "hacker" has a negative connotation and refers to a person who gains illegal access to computers (hacks) or uses kludges to accomplish programming tasks that are ugly, inelegant, and inefficient. This derogatory form of the noun "hack" is even used among users of the positive sense of "hacker" (some argue that it should not be, due to this negative meaning; others argue that some kludges can, for all their ugliness and imperfection, still have "hack value").
In computer security, a hacker is a person who specializes in work with the security mechanisms for computer and network systems. While including those who endeavor to strengthen such mechanisms, it is more often used by the mass media and popular culture to refer to those who seek access despite these security measures.
In other technical fields, hacker is extended to mean a person who makes things work beyond perceived limits through their own technical skill, such as a hardware hacker, or reality hacker.

Computer Viruses

A computer virus is a computer program that can copy itself and infect a computer without permission or knowledge of the user. The original may modify the copies or the copies may modify themselves, as occurs in a metamorphic virus. A virus can only spread from one computer to another when its host is taken to the uninfected computer, for instance by a user sending it over a network or carrying it on a removable medium such as a floppy disk, CD, or USB drive. Additionally, viruses can spread to other computers by infecting files on a network file system or a file system that is accessed by another computer. Viruses are sometimes confused with computer worms and Trojan horses. A worm, however, can spread itself to other computers without needing to be transferred as part of a host. A Trojan horse is a file that appears harmless until executed. In contrast to viruses, Trojan horses do not insert their code into other computer files. Many personal computers are now connected to the Internet and to local-area networks, facilitating their spread. Today's viruses may also take advantage of network services such as the World Wide Web, e-mail, and file sharing systems to spread, blurring the line between viruses and worms. Furthermore, some sources use an alternative terminology in which a virus is any form of self-replicating malware.
The term comes from the term virus in biology. A computer virus reproduces by making (possibly modified) copies of itself in the computer's memory, storage, or over a network. This is similar to the way a biological virus works.
Some viruses are programmed to damage the computer by damaging programs, deleting files, or reformatting the hard disk. Others are not designed to do any damage, but simply replicate themselves and perhaps make their presence known by presenting text, video, or audio messages. Even these benign viruses can create problems for the computer user. They typically take up computer memory used by legitimate programs. As a result, they often cause erratic behavior and can result in system crashes. In addition, many viruses are bug-ridden, and these bugs may lead to system crashes and data loss.
There are many viruses operating in the general Internet today, and new ones are discovered every day.

History
A program called "Elk Cloner" is credited with being the first computer virus to appear "in the wild" — that is, outside the single computer or lab where it was created. Written in 1982 by Richard Skrenta, it attached itself to the Apple DOS 3.3 operating system and spread by floppy disk. This virus was originally a joke, created by the high school student and put onto a game. The disk could only be used 49 times.The game was set to play, but release the virus on the 50th time of starting the game. Only this time, instead of playing the game, it would change to a blank screen that read a poem about the virus named Elk Cloner. The poem that showed up on the screen is as follows: It will get on all your disks. It will infiltrate your chips. Yes it's Cloner! It will stick to you like glue. It will modify RAM too. Send in the Cloner! The computer would then be infected.
The first PC virus was a boot sector virus called (c)Brain, created in 1986 by two brothers, Basit and Amjad Farooq Alvi, operating out of Lahore, Pakistan. The brothers reportedly created the virus to deter pirated copies of software they had written. However, analysts have claimed that the Ashar virus, a variant of Brain, possibly predated it based on code within the virus.
Before computer networks became widespread, most viruses spread on removable media, particularly floppy disks. In the early days of the personal computer, many users regularly exchanged information and programs on floppies. Some viruses spread by infecting programs stored on these disks, while others installed themselves into the disk boot sector, ensuring that they would be run when the user booted the computer from the disk.
Traditional computer viruses emerged in the 1980s, driven by the spread of personal computers and the resultant increase in BBS and modem use, and software sharing. Bulletin board driven software sharing contributed directly to the spread of Trojan horse programs, and viruses were written to infect popularly traded software. Shareware and bootleg software were equally common vectors for viruses on BBS's. Within the "pirate scene" of hobbyists trading illicit copies of retail software, traders in a hurry to obtain the latest applications and games were easy targets for viruses.
Since the mid-1990s, macro viruses have become common. Most of these viruses are written in the scripting languages for Microsoft programs such as Word and Excel. These viruses spread in Microsoft Office by infecting documents and spreadsheets. Since Word and Excel were also available for Mac OS, most of these viruses were able to spread on Macintosh computers as well. Most of these viruses did not have the ability to send infected e-mail. Those viruses which did spread through e-mail took advantage of the Microsoft Outlook COM interface.
Macro viruses pose unique problems for detection software. For example, some versions of Microsoft Word allowed macros to replicate themselves with additional blank lines. The virus behaved identically but would be misidentified as a new virus. In another example, if two macro viruses simultaneously infect a document, the combination of the two, if also self-replicating, can appear as a "mating" of the two and would likely be detected as a virus unique from the "parents".[1]
A virus may also send a web address link as an instant message to all the contacts on an infected machine. If the recipient, thinking the link is from a friend (a trusted source) follows the link to the website, the virus hosted at the site may be able to infect this new computer and continue propagating.
The newest species of the virus family is the cross-site scripting virus. The virus emerged from research and was academically demonstrated in 2005[citation needed]. This virus utilizes cross-site scripting vulnerabilities to propagate. Since 2005 there have been multiple instances of the cross-site scripting viruses in the wild, most notable sites affected have been MySpace and Yahoo.

Etymology
The word virus is derived from and used in the same sense as the biological equivalent. The term "virus" is often used in common parlance to describe all kinds of malware (malicious software), including those that are more properly classified as worms or Trojans. Most popular anti-virus software packages defend against all of these types of attack. In some technical communities, the term "virus" is also extended to include the authors of malware, in an insulting sense. The English plural of "virus" is "viruses". Some people use "virii" or "viri" as a plural, but this is rare. For a discussion about whether "viri" and "virii" are correct alternatives of "viruses", see plural of virus.
The term "virus" was first used in an academic publication by Fred Cohen in his 1984 paper Experiments with Computer Viruses, where he credits Len Adleman with coining it. However, a 1972 science fiction novel by David Gerrold, When H.A.R.L.I.E. Was One, includes a description of a fictional computer program called "VIRUS" that worked just like a virus (and was countered by a program called "VACCINE"). The term "computer virus" with current usage also appears in the comic book Uncanny X-Men #158, written by Chris Claremont and published in 1982. Therefore, although Cohen's use of "virus" may, perhaps, have been the first "academic" use, the term had been used earlier.

Why people create computer viruses
Unlike biological viruses (see Virus), computer viruses do not simply evolve by themselves. Computer viruses do not come into existence spontaneously, nor are they likely to be created by bugs in regular programs. They are deliberately created by programmers, or by people who use virus creation software. Computer viruses can only do what the programmers have programmed them to do.
Virus writers can have various reasons for creating and spreading malware. Viruses have been written as research projects, pranks, vandalism, to attack the products of specific companies, to distribute political messages, and financial gain from identity theft, spyware, and cryptoviral extortion. Some virus writers consider their creations to be works of art, and see virus writing as a creative hobby. Additionally, many virus writers oppose deliberately destructive payload routines. Many writers consider the systems they attack an intellectual challenge or a logical problem to be solved; this multiplies when a cat-and-mouse game is anticipated against anti-virus software. Some viruses were intended as "good viruses". They spread improvements to the programs they infect, or delete other viruses. These viruses are, however, quite rare, and they still consume system resources, may accidentally damage systems they infect, and, on occasion, have become infected and acted as vectors for malicious viruses. A poorly written "good virus" can also inadvertently become a harmful virus in and of itself (for example, such a 'good virus' may misidentify its target file and delete an innocent system file by mistake). Moreover, they normally operate without asking for the permission of the computer owner. Since self-replicating code causes many complications, it is questionable if a well-intentioned virus can ever solve a problem in a way that is superior to a regular program that does not replicate itself. In short, no single answer is likely to cover the broad demographic of virus writers.
Releasing computer viruses (as well as worms) is a crime in most jurisdictions.
See also the BBC News article.[2]

Replication strategies
In order to replicate itself, a virus must be permitted to execute code and write to memory. For this reason, many viruses attach themselves to executable files that may be part of legitimate programs. If a user tries to start an infected program, the virus' code may be executed first. Viruses can be divided into two types, on the basis of their behavior when they are executed. Nonresident viruses immediately search for other hosts that can be infected, infect these targets, and finally transfer control to the application program they infected. Resident viruses do not search for hosts when they are started. Instead, a resident virus loads itself into memory on execution and transfers control to the host program. The virus stays active in the background and infects new hosts when those files are accessed by other programs or the operating system itself.

Nonresident viruses
Nonresident viruses can be thought of as consisting of a finder module and a replication module. The finder module is responsible for finding new files to infect. For each new executable file the finder module encounters, it calls the replication module to infect that file.
For simple viruses the replicator's tasks are to:
Open the new file
Check if the executable file has already been infected (if it is, return to the finder module)
Append the virus code to the executable file
Save the executable's starting point
Change the executable's starting point so that it points to the start location of the newly copied virus code
Save the old start location to the virus in a way so that the virus branches to that location right after its execution
Save the changes to the executable file
Close the infected file
Return to the finder so that it can find new files for the replicator to infect

Resident viruses
Resident viruses contain a replication module that is similar to the one that is employed by nonresident viruses. However, this module is not called by a finder module. Instead, the virus loads the replication module into memory when it is executed and ensures that this module is executed each time the operating system is called to perform a certain operation. For example, the replication module can be called each time the operating system executes a file. In this case, the virus infects every suitable program that is executed on the computer.
Resident viruses are sometimes subdivided into a category of fast infectors and a category of slow infectors. Fast infectors are designed to infect as many files as possible. For instance, a fast infector can infect every potential host file that is accessed. This poses a special problem to anti-virus software, since a virus scanner will access every potential host file on a computer when it performs a system-wide scan. If the virus scanner fails to notice that such a virus is present in memory, the virus can "piggy-back" on the virus scanner and in this way infect all files that are scanned. Fast infectors rely on their fast infection rate to spread. The disadvantage of this method is that infecting many files may make detection more likely, because the virus may slow down a computer or perform many suspicious actions that can be noticed by anti-virus software. Slow infectors, on the other hand, are designed to infect hosts infrequently. For instance, some slow infectors only infect files when they are copied. Slow infectors are designed to avoid detection by limiting their actions: they are less likely to slow down a computer noticeably, and will at most infrequently trigger anti-virus software that detects suspicious behavior by programs. The slow infector approach does not seem very successful, however.

Vectors and hosts
Viruses have targeted various types of transmission media or hosts. This list is not exhaustive:
Binary executable files (such as COM files and EXE files in MS-DOS, Portable Executable files in Microsoft Windows, and ELF files in Linux)
Volume Boot Records of floppy disks and hard disk partitions
The master boot record (MBR) of a hard disk
General-purpose script files (such as batch files in MS-DOS and Microsoft Windows, VBScript files, and shell script files on Unix-like platforms).
Application-specific script files (such as Telix-scripts)
Documents that can contain macros (such as Microsoft Word documents, Microsoft Excel spreadsheets, AmiPro documents, and Microsoft Access database files)
Cross-site scripting vulnerabilities in web applications

Inhospitable vectors
It is difficult, but not impossible, for viruses to tag along in source files, seeing that computer languages are built also for human eyes and experienced operators. It is very probably impossible for viruses to tag along in data files like MP3s, MPGs, OGGs, JPGs, GIFs, PNGs, MNGs, PDFs, and DVI files (this is not an exhaustive list of generally trusted file types). Even if a virus were to 'infect' such a file, it would be inoperative, since there would be no way for the viral code to be executed. A caveat must be mentioned from PDFs, that like HTML, may link to malicious code. Further, an exploitable buffer overflow in a program which reads the data files could be used to trigger the execution of code hidden within the data file, but this attack is substantially mitigated in computer architectures with an execute disable bit.
It is worth noting that some virus authors have written an .EXE extension on the end of .PNG (for example), hoping that users would stop at the trusted file type without noticing that the computer would start with the final type of file. See Trojan horse (computing).

Methods to avoid detection
in order to avoid detection by users, some viruses employ different kinds of deception. Some old viruses, especially on the MS-DOS platform, make sure that the "last modified" date of a host file stays the same when the file is infected by the virus. This approach does not fool anti-virus software, however, especially that which maintains and dates Cyclic Redundancy Codes on file changes.
Some viruses can infect files without increasing their sizes or damaging the files. They accomplish this by overwriting unused areas of executable files. These are called cavity viruses. For example the CIH virus, or Chernobyl Virus, infects Portable Executable files. Because those files had many empty gaps, the virus, which was 1 KB in length, did not add to the size of the file.
Some viruses try to avoid detection by killing the tasks associated with antivirus software before it can detect them.
As computers and operating systems grow larger and more complex, old hiding techniques need to be updated or replaced. Defending your computer against viruses may demand that your file system migrate towards detailed and explicit permission for every kind of file access.

Avoiding bait files and other undesirable hosts
A virus needs to infect hosts in order to spread further. In some cases, it might be a bad idea to infect a host program. For example, many anti-virus programs perform an integrity check of their own code. Infecting such programs will therefore increase the likelihood that the virus is detected. For this reason, some viruses are programmed not to infect programs that are known to be part of anti-virus software. Another type of host that viruses sometimes avoid is bait files. Bait files (or goat files) are files that are specially created by anti-virus software, or by anti-virus professionals themselves, to be infected by a virus. These files can be created for various reasons, all of which are related to the detection of the virus:
Anti-virus professionals can use bait files to take a sample of a virus (i.e. a copy of a program file that is infected by the virus). It is more practical to store and exchange a small, infected bait file, than to exchange a large application program that has been infected by the virus.
Anti-virus professionals can use bait files to study the behavior of a virus and evaluate detection methods. This is especially useful when the virus is polymorphic. In this case, the virus can be made to infect a large number of bait files. The infected files can be used to test whether a virus scanner detects all versions of the virus.
Some anti-virus software employs bait files that are accessed regularly. When these files are modified, the anti-virus software warns the user that a virus is probably active on the system.
Since bait files are used to detect the virus, or to make detection possible, a virus can benefit from not infecting them. Viruses typically do this by avoiding suspicious programs, such as small program files or programs that contain certain patterns of 'garbage instructions'.
A related strategy to make baiting difficult is sparse infection. Sometimes, sparse infectors do not infect a host file that would be a suitable candidate for infection in other circumstances. For example, a virus can decide on a random basis whether to infect a file or not, or a virus can only infect host files on particular days of the week!

Stealth
Some viruses try to trick anti-virus software by intercepting its requests to the operating system. A virus can hide itself by intercepting the anti-virus software’s request to read the file and passing the request to the virus, instead of the OS. The virus can then return an uninfected version of the file to the anti-virus software, so that it seems that the file is "clean". Modern anti-virus software employs various techniques to counter stealth mechanisms of viruses. The only completely reliable method to avoid stealth is to boot from a medium that is known to be clean.

Self-modification
Most modern antivirus programs try to find virus-patterns inside ordinary programs by scanning them for so-called virus signatures. A signature is a characteristic byte-pattern that is part of a certain virus or family of viruses. If a virus scanner finds such a pattern in a file, it notifies the user that the file is infected. The user can then delete, or (in some cases) "clean" or "heal" the infected file. Some viruses employ techniques that make detection by means of signatures difficult but probably not impossible. These viruses modify their code on each infection. That is, each infected file contains a different variant of the virus.

Encryption with a variable key
A more advanced method is the use of simple encryption to encipher the virus. In this case, the virus consists of a small decrypting module and an encrypted copy of the virus code. If the virus is encrypted with a different key for each infected file, the only part of the virus that remains constant is the decrypting module, which would (for example) be appended to the end. In this case, a virus scanner cannot directly detect the virus using signatures, but it can still detect the decrypting module, which still makes indirect detection of the virus possible. Since these would be symmetric keys, stored on the infected host, it is in fact entirely possible to decrypt the final virus, but that probably isn't required, since self-modifying code is such a rarity that it may be reason for virus scanners to at least flag the file as suspicious.
An old, but compact, encryption involved XORing each byte in a virus with a constant, such that a XOR b = c, and c XOR b = a, so that the exclusive or operation had only to be repeated for decryption. It is suspicious code that modifies itself, so the code to do this may be part of the signature in many virus definitions.


Polymorphic code
Polymorphic code was the first technique that posed a serious threat to virus scanners. Just like regular encrypted viruses, a polymorphic virus infects files with an encrypted copy of itself, which is decoded by a decryption module. In the case of polymorphic viruses however, this decryption module is also modified on each infection. A well-written polymorphic virus therefore has no parts that stay the same on each infection, making it very difficult to detect directly using signatures. Anti-virus software can detect it by decrypting the viruses using an emulator, or by statistical pattern analysis of the encrypted virus body. To enable polymorphic code, the virus has to have a polymorphic engine (also called mutating engine or mutation engine) somewhere in its encrypted body. See Polymorphic code for technical detail on how such engines operate.
Some viruses employ polymorphic code in a way that constrains the mutation rate of the virus significantly. For example, a virus can be programmed to mutate only slightly over time, or it can be programmed to refrain from mutating when it infects a file on a computer that already contains copies of the virus. The advantage of using such slow polymorphic code is that it makes it more difficult for anti-virus professionals to obtain representative samples of the virus, because bait files that are infected in one run will typically contain identical or similar samples of the virus. This will make it more likely that the detection by the virus scanner will be unreliable, and that some instances of the virus may be able to avoid detection.

Metamorphic code
To avoid being detected by emulation, some viruses rewrite themselves completely each time they are to infect new executables. Viruses that use this technique are said to be metamorphic. To enable metamorphism, a metamorphic engine is needed. A metamorphic virus is usually very large and complex. For example, W32/Simile consisted of over 14000 lines of Assembly language code, 90% of it part of the metamorphic engine.



The vulnerability of operating systems to viruses
Another analogy to biological viruses: just as genetic diversity in a population decreases the chance of a single disease wiping out a population, the diversity of software systems on a network similarly limits the destructive potential of viruses.
This became a particular concern in the 1990s, when Microsoft gained market dominance in desktop operating systems and office suites. The users of Microsoft software (especially networking software such as Microsoft Outlook and Internet Explorer) are especially vulnerable to the spread of viruses. Microsoft software is targeted by virus writers due to their desktop dominance, and is often criticized for including many errors and holes for virus writers to exploit. Integrated applications, applications with scripting languages with access to the file system (for example Visual Basic Script (VBS), and applications with networking features) are also particularly vulnerable.
Although Windows is by far the most popular operating system for virus writers, some viruses also exist on other platforms. Any operating system that allows third-party programs to run can theoretically run viruses. Some operating systems are less secure than others. Unix-based OS's (and NTFS-aware applications on Windows NT based platforms) only allow their users to run executables within their protected space in their own directories.
As of 2006, there are relatively few security exploits[3] targeting Mac OS X (with a Unix-based file system); the known vulnerabilities fall under the classifications of worms and Trojans. The number of viruses for the older Apple operating systems, known as Mac OS Classic, varies greatly from source to source, with Apple stating that there are only four known viruses, and independent sources stating there are as many as 63 viruses. It is safe to say that Macs are less likely to be exploited due to their secure Unix base, and because a Mac-specific virus could only infect a small proportion of computers (making the effort less desirable). Virus vulnerability between Macs and Windows is a chief selling point Apple Computers use to get users to switch away from Microsoft (Get a Mac). Ironically if a change in the user base away from PCs and towards Macs was to occur then the Mac OS X platform would become a much more desirable target to virus writers. As there are currently few anti virus solutions available on the OS X platform, there is the possibility that this would become a considerable problem for Mac users very quickly, Apple literally becoming a victim of their own success.[4]
Windows and Unix have similar scripting abilities, but while Unix natively blocks normal users from having access to make changes to the operating system environment, Windows does not. In 1997, when a virus for Linux was released – known as "Bliss" – leading antivirus vendors issued warnings that Unix-like systems could fall prey to viruses just like Windows.[5] The Bliss virus may be considered characteristic of viruses – as opposed to worms – on Unix systems. Bliss requires that the user run it explicitly (making it a trojan), and it can only infect programs that the user has the access to modify. Unlike Windows users, most Unix users do not log in as an administrator user except to install or configure software; as a result, even if a user ran the virus, it could not harm their operating system. The Bliss virus never became widespread, and remains chiefly a research curiosity. Its creator later posted the source code to Usenet, allowing researchers to see how it worked.[6]

The role of software development
Because software is often designed with security features to prevent unauthorized use of system resources, many viruses must exploit software bugs in a system or application to spread. Software development strategies that produce large numbers of bugs will generally also produce potential exploits.

Anti-virus software and other preventive countermeasures
There are two common methods that an anti-virus software application uses to detect viruses. The first, and by far the most common method of virus detection is using a list of virus signature definitions. The disadvantage of this detection method is that users are only protected from viruses that pre-date their last virus definition update. The second method is to use a heuristic algorithm to find viruses based on common behaviors. This method has the ability to detect viruses that anti-virus security firms’ have yet to create a signature for.
Many users install anti-virus software that can detect and eliminate known viruses after the computer downloads or runs the executable. They work by examining the content heuristics of the computer's memory (its RAM, and boot sectors) and the files stored on fixed or removable drives (hard drives, floppy drives), and comparing those files against a database of known virus "signatures". Some anti-virus programs are able to scan opened files in addition to sent and received emails 'on the fly' in a similar manner. This practice is known as "on-access scanning." Anti-virus software does not change the underlying capability of host software to transmit viruses. Users must update their software regularly to patch security holes. Anti-virus software also needs to be regularly updated in order to gain knowledge about the latest threats.
One may also prevent the damage done by viruses by making regular backups of data (and the Operating Systems) on different media, that are either kept unconnected to the system (most of the time), read-only or not accessible for other reasons, such as using different file systems. This way, if data is lost through a virus, one can start again using the backup (which should preferably be recent). If a backup session on optical media like CD and DVD is closed, it becomes read-only and can no longer be affected by a virus. Likewise, an Operating System on a bootable can be used to start the computer if the installed Operating Systems become unusable. Another method is to use different Operating Systems on different file systems. A virus is not likely to affect both. Data backups can also be put on different file systems. For example, Linux requires specific software to write to NTFS partitions, so if one does not install such software and uses a separate installation of MS Windows to make the backups on an NTFS partition (and preferably only for that reason), the backup should remain safe from any Linux viruses. Likewise, MS Windows can not read file systems like ext3, so if one normally uses MS Windows, the backups can be made on an ext3 partition using a Linux installation.

Recovery methods
Once a computer has been compromised by a virus, it is usually unsafe to continue using the same computer without completely reinstalling the operating system. However, there are a number of recovery options that exist after a computer has a virus. These actions depend on severity of the type of virus.

Virus removal
One possibility on Windows XP is a tool known as System Restore, which restores the registry and critical system files to a previous checkpoint. Often a virus will cause a system to hang, and a subsequent hard reboot will render a system restore point from the same day corrupt. Restore points from previous days should work provided the virus is not designed to corrupt the restore files. Some viruses, however, disable system restore and other important tools such as Task Manager and Command Prompt. Examples of viruses that do this would be CiaDoor.
Administrators have the option to disable such tools from limited users for various reasons. The virus modifies the registry to do the same, except, when the Administrator is controlling the computer, it blocks all users from accessing the tools. When an infected tool activates it gives the message "Task Manager has been disabled by your administrator.", even if the user trying to open the program is the administrator.

Operating system reinstallation
As a last ditch effort, if a virus is on your system and anti-viral software can't clean it, then reinstalling the operating system may be required. To do this properly, the hard drive is completely erased (partition deleted and formatted) and the operating system is installed from media known not to be infected. Important files should first be backed up, if possible, and separately scanned for infection before erasing the original hard drive and reinstalling the operating system.