Saturday, August 18, 2012

File Menu c PROGRAM


#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <string.h>

int main()
{
FILE *fp;
FILE *out;

char another,choice;

struct emp {
char name[40];
int age;
float bs;
};

struct emp e;
char empname[40];

int recsize;

char buffer[25];

clrscr();

fp=fopen("emp.dat","rb+");

if (fp==NULL)
{
fp=fopen("emp.dat","wb+");
if (fp==NULL)
{
printf("Cannot open the main file");
exit(1);
}
}


recsize=sizeof(e);

while(1)
{
printf("\n1. Add Records");
printf("\n2. List Records");
printf("\n3. Modify Records");
printf("\n4. Delete Records");
printf("\n5. Exit");
printf("\nEnter Your Choice");
fflush(stdin);
choice=getche();

switch(choice)
{
case '1':
fseek(fp,0,SEEK_END);
another='Y';
while(another=='y' || another=='Y')
{
printf("\nEnter name , age and basic Salary");
scanf("%s%d%f",e.name,&e.age,&e.bs);
// fprintf(fp,"%s%d%f",e.name,e.age,e.bs);
fwrite(&e,recsize,1,fp);
printf("\nAdd Another Reccord(Y/N)");
fflush(stdin);
another=getche();
}
break;
case '2':
rewind(fp);
//fseek(fp,0,SEEK_SET);

while(fread(&e,recsize,1,fp)==1)
printf("%s %d %f\n",e.name,e.age,e.bs);
break;
case '3':
another='y';
while(another=='y' || another=='Y')
{
printf("\nEnter the name of employee to modify");
scanf("%s",empname);

rewind(fp);
while(fread(&e,recsize,1,fp)==1)
{
if (strcmp(e.name,empname)==0)
{
printf("\nEnter new name, age, basic "\
"salary");
scanf("%s%d%f",e.name,&e.age,&e.bs);
fseek(fp,-recsize,SEEK_CUR);
fwrite(&e,recsize,1,fp);
break;
}
}
printf("\nModify Another record (Y/N)");
fflush(stdin);
another=getche();
}
break;
case '4':
another='Y';

while(another=='y' || another=='Y')
{
printf("\nEnter the name of employee to delete");
scanf("%s",empname);

tmpnam(buffer);
puts(buffer);
out=fopen(buffer,"wb+");
if (out==NULL)
{
printf("\nCannot open the temp file");
exit(2);
}

rewind(fp);
while(fread(&e,recsize,1,fp)==1)
{
if (strcmp(e.name,empname)!=0)
fwrite(&e,recsize,1,out);
}
fclose(fp);
fclose(out);
remove("EMP.DAT");
if (rename(buffer,"EMP.DAT") == 0)
printf("\nRenamed");
else
printf("\nCannot rename");

fp=fopen("EMP.DAT","rb+");

printf("\nDelete Another Record (Y/N)");
fflush(stdin);
another=getche();
}
break;
case '5':
fclose(fp);
exit(0);
}
}
}

Name:Avul Pakir Jainulabdeen Abdul Kalam 

Born:October 15, 1931 (1931-10-15) (age 77),Rameshwaram, Tamil Nadu, India

Religion:Islam.

Kalam's father was a devout Muslim, who owned boats which he rented out to local fishermen and was a good friend of Hindu religious leaders and the school teachers at Rameshwaram. APJ Abdul Kalam mentions in his biography that to support his studies, he started his career as a newspaper vendor. This was also told in the book, A Boy and His Dream: Three Stories from the Childhood of Abdul Kalam by Vinita Krishna. The house Kalam was born in can still be found on the Mosque street in Rameshwaram, and his brother's curio shop abuts it. This has become a point-of-call for tourists who seek out the place. Kalam grew up in an intimate relationship with nature, and he says in Wings of Fire that he never could imagine that water could be so powerful a destroying force as that he witnessed when he was thirty three. That was in 1964 when a cyclonic storm swept away the Pamban bridge and a trainload of passengers with it and also Kalam's native village, Dhanushkodi. Kalam is a scholar of Thirukkural; in most of his speeches, he quotes at least one kural. Kalam has written several inspirational books, most notably his autobiography Wings of Fire, aimed at motivating Indian youth. Another of his books, Guiding Souls: Dialogues on the Purpose of Life reveals his spiritual side. He has written poems in Tamil as well. It has been reported that there is considerable demand in South Korea for translated versions of books authored by him. Kalam has also patronised grassroots innovations. He is closely associated with the Honey Bee Network and The National innovation Foundation. The NIF is a body of Government of India and operates from Ahmadabad, Gujrat.




Wednesday, August 15, 2012

COMPUTER NETWORKS QUESTION BANK


Question Bank For Computer Networks

Part A

  1. Discuss the use of computer networks.
  2. Describe the features of LAN.
  3. What is meant by piggybacking?  What are its advantages and disadvantages?
  4. How are errors caused in transmission lines?
  5. Explain the Binary and Manchester encoding techniques with an example.
  6. What is meant by congestion? List the ways of avoiding congestion.
  7. Discuss the issues in network security.
  8. Explain multiplexing technique.
  9. Discuss the problems associated with Backward Learning.
  10. What is transport address? Who will assign it?
  11. Why is layered architecture of network preferred?
  12. What is the principal difference between circuit switching and packet switching?
  13. Explain how errors are detected using CRC.
  14. What is meant by Pipelining? Discuss the merits and demerits of using this technique.
  15. Discuss about any two methods of framing.
  16. Compare virtual circuits and datagrams.
  17. List the features of internetworking.
  18. What is modern and codec?
  19. What is flooding? What are its disadvantages?
  20. What are the primary services offered by a computer network?
  21. Mention the advantages of fiber optics.
  22. What is meant by narrow band ISDN?
  23. What is the significance of flow control?
  24. List the drawbacks of simplex protocol.
  25. Explain the use of bridges.
  26. What is meant by inter networking?
  27. List any four services of transport layer.
  28. Mention the need for domain name system.
  29. What are the components of multimedia?
  30. What are the goals for setting up networks?
  31. List the components of data communications.
  32. Mention the advantages of co-axial cables.
  33. What are satellite networks?
  34. Briefly list the problems with single channel.
  35. What is the need for routing algorithm?
  36. List the features of token bus protocol.
  37. Compare TCP and IP services.
  38. Write a note on e-mail.




Part –B


  1. With a neat diagram, explain OSI reference model.
  2. Describe the relative advantages and disadvantages of
a. Terrestrial links    b. Satellite links and    c. Optical fiber transmission.
  1. Describe the error detecting and correcting techniques employed in data communication.
  2. Discuss about collision free protocols.
  3. Discuss the function and structure of e-mail protocol.
  4. Write short notes on
 a. Packet Switching
 b. Message Switching
 c. Circuit Switching
  1. Explain the transport layer connection management.
  2. Explain the bus type topology and ring type topology networks. Compare their performance.
  3. What are the objectives of computer communication networks? What are the network components? Explain.
  4. Explain the function of TCP/IP protocol.
  5. Explain ISDN architecture and its services.
  6. Describe the sliding window protocol for data link layer.
  7. Describe the congestion control algorithms.
  8. Explain IEEE’s logical link control protocol used for LAN.
  9. Explain the traditional cryptography used for network security and privacy.
  10. Describe the structure and functions of E-mail protocol.
  11. Explain wireless communications and their suitability to computer networks.
  12. Explain the design issues of datalink layers.
  13. Discuss the method of performing protocol specification and verification.
  14. Describe the structure of network layer in the internet.
  15. Discuss the services offered by the application layer.
  16. Describe the ATM AAL layer protocols.
  17. Write short notes on the following
    1. World wide web
    2. High speed LANs.
  18. Explain the applications of computer networks.
  19. Discuss the methods used for controlling errors in datalink layer.
  20. Explain the various media used for data transmission in computer networks.
  21. Explain any two protocols used by the datalink layer.
  22. Explain the multi path routing algorithm.
  23. Discuss the features of ATM networks.
  24. Explain the design issues of transport layer.
  25. Write short notes on
    1. Channel allocation problems
    2. Simple network management protocol.




JAVA RMI notes


Java RMI

Introduction

This is a brief introduction to Java Remote Method Invocation (RMI). Java RMI is a mechanism that allows one to invoke a method on an object that exists in another address space. The other address space could be on the same machine or a different one. The RMI mechanism is basically an object-oriented RPC mechanism. CORBA is another object-oriented RPC mechanism. CORBA differs from Java RMI in a number of ways:
  1. CORBA is a language-independent standard.
  2. CORBA includes many other mechanisms in its standard (such as a standard for TP monitors) none of which are part of Java RMI.
  3. There is also no notion of an "object request broker" in Java RMI.
Java RMI has recently been evolving toward becoming more compatible with CORBA. In particular, there is now a form of RMI called RMI/IIOP ("RMI over IIOP") that uses the Internet Inter-ORB Protocol (IIOP) of CORBA as the underlying protocol for RMI communication.
This tutorial attempts to show the essence of RMI, without discussing any extraneous features. Sun has provided a Guide to RMI, but it includes a lot of material that is not relevant to RMI itself. For example, it discusses how to incorporate RMI into an Applet, how to use packages and how to place compiled classes in a different directory than the source code. All of these are interesting in themselves, but they have nothing at all to do with RMI. As a result, Sun's guide is unnecessarily confusing. Moreover, Sun's guide and examples omit a number of details that are important for RMI.
There are three processes that participate in supporting remote method invocation.
  1. The Client is the process that is invoking a method on a remote object.
  2. The Server is the process that owns the remote object. The remote object is an ordinary object in the address space of the server process.
  3. The Object Registry is a name server that relates objects with names. Objects are registered with the Object Registry. Once an object has been registered, one can use the Object Registry to obtain access to a remote object using the name of the object.
In this tutorial, we will give an example of a Client and a Server that solve the classical "Hello, world!" problem. You should try extracting the code that is presented and running it on your own computer.
There are two kinds of classes that can be used in Java RMI.
  1. A Remote class is one whose instances can be used remotely. An object of such a class can be referenced in two different ways:
    1. Within the address space where the object was constructed, the object is an ordinary object which can be used like any other object.
    2. Within other address spaces, the object can be referenced using an object handle. While there are limitations on how one can use an object handle compared to an object, for the most part one can use object handles in the same way as an ordinary object.
For simplicity, an instance of a Remote class will be called a remote object.
  1. A Serializable class is one whose instances can be copied from one address space to another. An instance of a Serializable class will be called a serializable object. In other words, a serializable object is one that can be marshaled. Note that this concept has no connection to the concept of serializability in database management systems.
If a serializable object is passed as a parameter (or return value) of a remote method invocation, then the value of the object will be copied from one address space to the other. By contrast if a remote object is passed as a parameter (or return value), then the object handle will be copied from one address space to the other.
One might naturally wonder what would happen if a class were both Remote and Serializable. While this might be possible in theory, it is a poor design to mix these two notions as it makes the design difficult to understand.

Serializable Classes

We now consider how to design Remote and Serializable classes. The easier of the two is a Serializable class. A class is Serializable if it implements the java.io.Serializable interface. Subclasses of a Serializable class are also Serializable. Many of the standard classes are Serializable, so a subclass of one of these is automatically also Serializable. Normally, any data within a Serializable class should also be Serializable. Although there are ways to include non-serializable objects within a serializable objects, it is awkward to do so. See the documentation of java.io.Serializable for more information about this.
Using a serializable object in a remote method invocation is straightforward. One simply passes the object using a parameter or as the return value. The type of the parameter or return value is the Serializable class. Note that both the Client and Server programs must have access to the definition of any Serializable class that is being used. If the Client and Server programs are on different machines, then class definitions of Serializable classes may have to be downloaded from one machine to the other. Such a download could violate system security. This problem is discussed in the Security section.
The only Serializable class that will be used in the "Hello, world!" example is the String class, so no problems with security arise.

Remote Classes and Interfaces

Next consider how to define a Remote class. This is more difficult than defining a Serializable class. A Remote class has two parts: the interface and the class itself. The Remote interface must have the following properties:
  1. The interface must be public.
  2. The interface must extend the interface java.rmi.Remote.
  3. Every method in the interface must declare that it throws java.rmi.RemoteException. Other exceptions may also be thrown.
The Remote class itself has the following properties:
  1. It must implement a Remote interface.
  2. It should extend the java.rmi.server.UnicastRemoteObject class. Objects of such a class exist in the address space of the server and can be invoked remotely. While there are other ways to define a Remote class, this is the simplest way to ensure that objects of a class can be used as remote objects. See the documentation of the java.rmi.server package for more information.
  3. It can have methods that are not in its Remote interface. These can only be invoked locally.
Unlike the case of a Serializable class, it is not necessary for both the Client and the Server to have access to the definition of the Remote class. The Server requires the definition of both the Remote class and the Remote interface, but the Client only uses the Remote interface. Roughly speaking, the Remote interface represents the type of an object handle, while the Remote class represents the type of an object. If a remote object is being used remotely, its type must be declared to be the type of the Remote interface, not the type of the Remote class.
In the example program, we need a Remote class and its corresponding Remote interface. We call these Hello and HelloInterface, respectively. Here is the file HelloInterface.java:
import java.rmi.*;
/**
 * Remote Interface for the "Hello, world!" example.
 */
public interface HelloInterface extends Remote {
  /**
   * Remotely invocable method.
   * @return the message of the remote object, such as "Hello, world!".
   * @exception RemoteException if the remote invocation fails.
   */
  public String say() throws RemoteException;
}
Here is the file Hello.java:
import java.rmi.*;
import java.rmi.server.*;
/**
 * Remote Class for the "Hello, world!" example.
 */
public class Hello extends UnicastRemoteObject implements HelloInterface {
  private String message;
  /**
   * Construct a remote object
   * @param msg the message of the remote object, such as "Hello, world!".
   * @exception RemoteException if the object handle cannot be constructed.
   */
  public Hello (String msg) throws RemoteException {
    message = msg;
  }
  /**
   * Implementation of the remotely invocable method.
   * @return the message of the remote object, such as "Hello, world!".
   * @exception RemoteException if the remote invocation fails.
   */
  public String say() throws RemoteException {
    return message;
  }
}
All of the Remote interfaces and classes should be compiled using javac. Once this has been completed, the stubs and skeletons for the Remote interfaces should be compiled by using the rmic stub compiler. The stub and skeleton of the example Remote interface are compiled with the command:
  rmic Hello
The only problem one might encounter with this command is that rmic might not be able to find the files Hello.class and HelloInterface.class even though they are in the same directory where rmic is being executed. If this happens to you, then try setting the CLASSPATH environment variable to the current directory, as in the following command:
  setenv CLASSPATH .
If your CLASSPATH variable already has some directories in it, then you might want to add the current directory to the others.

Programming a Client

Having described how to define Remote and Serializable classes, we now discuss how to program the Client and Server. The Client itself is just a Java program. It need not be part of a Remote or Serializable class, although it will use Remote and Serializable classes.
A remote method invocation can return a remote object as its return value, but one must have a remote object in order to perform a remote method invocation. So to obtain a remote object one must already have one. Accordingly, there must be a separate mechanism for obtaining the first remote object. The Object Registry fulfills this requirement. It allows one to obtain a remote object using only the name of the remote object.
The name of a remote object includes the following information:
  1. The Internet name (or address) of the machine that is running the Object Registry with which the remote object is being registered. If the Object Registry is running on the same machine as the one that is making the request, then the name of the machine can be omitted.
  2. The port to which the Object Registry is listening. If the Object Registry is listening to the default port, 1099, then this does not have to be included in the name.
  3. The local name of the remote object within the Object Registry.
Here is the example Client program:
  /**
   * Client program for the "Hello, world!" example.
   * @param argv The command line arguments which are ignored.
   */
  public static void main (String[] argv) {
    try {
      HelloInterface hello = 
        (HelloInterface) Naming.lookup ("//ortles.ccs.neu.edu/Hello");
      System.out.println (hello.say());
    } catch (Exception e) {
      System.out.println ("HelloClient exception: " + e);
    }
  }
The Naming.lookup method obtains an object handle from the Object Registry running on ortles.ccs.neu.edu and listening to the default port. Note that the result of Naming.lookup must be cast to the type of the Remote interface.
The remote method invocation in the example Client is hello.say(). It returns a String which is then printed. A remote method invocation can return a String object because String is a Serializable class.
The code for the Client can be placed in any convenient class. In the example Client, it was placed in a class HelloClient that contains only the program above.

Programming a Server

The Server itself is just a Java program. It need not be a Remote or Serializable class, although it will use them. The Server does have some responsibilities:
  1. If class definitions for Serializable classes need to be downloaded from another machine, then the security policy of your program must be modified. Java provides a security manager class called RMISecurityManager for this purpose. The RMISecurityManager defines a security policy that allows the downloading of Serializable classes from another machine. The "Hello, World!" example does not need such downloads, since the only Serializable class it uses is String. As a result it isn't necessary to modify the security policy for the example program. If your program defines Serializable classes that need to be downloaded to another machine, then insert the statement System.setSecurityManager (new RMISecurityManager()); as the first statement in the main program below. If this does not work for your program, then you should consult the Security section below.
  2. At least one remote object must be registered with the Object Registry. The statement for this is: Naming.rebind (objectName, object); where object is the remote object being registered, and objectName is the String that names the remote object.
Here is the example Server:
  /**
   * Server program for the "Hello, world!" example.
   * @param argv The command line arguments which are ignored.
   */
  public static void main (String[] argv) {
    try {
      Naming.rebind ("Hello", new Hello ("Hello, world!"));
      System.out.println ("Hello Server is ready.");
    } catch (Exception e) {
      System.out.println ("Hello Server failed: " + e);
    }
  }
The rmiregistry Object Registry only accepts requests to bind and unbind objects running on the same machine, so it is never necessary to specify the name of the machine when one is registering an object.
The code for the Server can be placed in any convenient class. In the example Server, it was placed in a class HelloServer that contains only the program above.

Starting the Server

Before starting the Server, one should first start the Object Registry, and leave it running in the background. One performs this by using the command:
  rmiregistry &
It takes a second or so for the Object Registry to start running and to start listening on its socket. If one is using a script, then one should program a pause after starting the Object Registry. If one is typing at the command line, it is unlikely that one could type fast enough to get ahead of the Object Registry.
The Server should then be started; and, like the Object Registry, left running in the background. The example Server is started using the command:
  java HelloServer &
The Server will take a few seconds to start running, and to construct and register remote objects. So one should wait a few seconds before running any Clients. Printing a suitable message, as in the example Server, is helpful for determining when the Server is ready.

Running a Client

Th Client is run like any other java program. The example Client is executed using:
  java HelloClient
For this to run it is necessary for the HelloClient, HelloInterface and Hello_Stub classes be available on the client machine. In particular, the HelloClient.class, HelloInterface.class and Hello_Stub.class files must be in one of the directories specified in the CLASSPATH.
In theory, it should be possible for the client to download the necessary class files from the server without the need for these classes to be on the client machine. In practice, this is very difficult to accomplish because classes can use other classes in other packages, and these other packages are determined by the CLASSPATH which is locally defined on each machine. More sophisticated (and more complex) remote method invocation mechanisms (such as CORBA) can achieve this, but simpler mechanisms like RMI cannot (at least not yet).

Security

One of the most common problems one encounters with RMI is a failure due to security constraints. This section gives a very brief introduction to the Java security model as it relates to RMI. For a more complete treatment, one should read the documentation for the Java SecurityManager and Policy classes and their related classes. Note that this section assumes that one is using Java 1.2 or later. Some of the statements are not true for earlier versions.
A Java program may specify a security manager that determines its security policy. A program will not have any security manager unless one is specified. One sets the security policy by constructing a SecurityManager object and calling the setSecurityManager method of the System class. Certain operations require that there be a security manager. For example, RMI will download a Serializable class from another machine only if there is a security manager and the security manager permits the downloading of the class from that machine. The RMISecurityManager class defines an example of a security manager that normally permits such downloads.
However, many Java installations have instituted security policies that are more restrictive than the default. There are good reasons for instituting such policies, and one should not override them carelessly. In particular, if your Java virtual machine already has a security manager and if this security manager does not allow the setSecurityManager method to be invoked, then you will not be able to change security policies other than as allowed by the existing security manager. This is the case for applets running in a browser. In order to protect the client from potentially dangerous applets, the security manager of applets does not allow many operations, including reading and writing local files, as well as changing the security manager.
The rest of this section discusses some ways that can be used for overriding security policies that prevent RMI from functioning properly.
The SecurityManager class has a large number of methods whose name begins with check. For example, checkConnect (String host, int port). If a check method returns, then the permission was granted. For example, if a call to checkConnect returns normally, then the current security policy allows the program to establish a socket connection to the server socket at the specified host and port. If the current security policy does not allow one to connect to this host and port, then the call throws an exception. This usually causes your program to terminate with a message such as:
  java.security.AccessControlException: access denied
  (java.net.SocketPermission 127.0.0.1:1099 connect,resolve)
The message above would occur when an RMI server or client was not allowed to connect to the RMI registry running on the same machine as the server or client.
As discussed above, one sets the security policy by passing an object of type SecurityManager to the setSecurityManager method of the System class. There are several ways to modify the security policy of a program. The simplest technique is to define a subclass of SecurityManager and to call System.setSecurityManager on an object of this subclass. In the definition of this subclass, you should override those check methods for which you want a different policy. For example, if you find that your "Hello, World!" program refuses to connect to the registry, then you should override the checkConnect methods. There are two checkConnect methods. The first was discussed above, and the second checkConnect method has a third parameter that specifies the security context of the request.
The following code illustrates how to do this:
  System.setSecurityManager (new RMISecurityManager() {
    public void checkConnect (String host, int port) {}
    public void checkConnect (String host, int port, Object context) {}
  });
The code above uses an anonymous inner class. Such a class is convenient when the class will only be used to construct an object in one place, as in this example. Of course, one could also define the subclass of RMISecurityManager in the usual way.
Defining and installing a security manager was the original technique for specifying a security policy in Java. Unfortunately, it is very difficult to design such a class so that it does not leave any security holes. For this reason, a new technique was introduced in Java 1.2, which is backward compatible with the old technique. In the default security manager, all check methods (except checkPermission) are implemented by calling the checkPermission method. The type of permission being checked is specified by the parameter of type Permission passed to the checkPermission method. For example, the checkConnect method calls checkPermission with a SocketPermission object. The default implementation of checkPermission is to call the checkPermission method of the AccessController class. This method checks whether the specified permission is implied by a list of granted permissions. The Permissions class is used for maintaining lists of granted permissions and for checking whether a particular permission has been granted.
This is the mechanism whereby the security manager checks permissions, but it does not explain how one specifies or changes the security policy. For this purpose there is yet another class, named Policy. Like SecurityManager, each program has a current security policy that can be obtained by calling Policy.getPolicy(), and one can set the current security policy using Policy.setPolicy, if one has permission to do so. The security policy is typically specified by a policy configuration file (or "policy file" for short) which is read when the program starts and any time that a request is made to refresh the security policy. The policy file defines the permissions contained in a Policy object. It is not inaccurate to think of the policy file a kind of serialization of a Policy object (except that a policy file is intended to be readable by humans as well as by machines). As an example, the following will grant all permissions of any kind to code residing in the RMI directory on the C: drive:
  grant codeBase "file:C:/RMI/-" {
    permission java.security.AllPermission;
  };
The default security manager uses a policy that is defined in a collection of policy files. For the locations of these files see the documentation of the policytool program. If one wishes to grant additional permissions, then one can specify them in a policy file and then request that they be loaded using options such as the following:
java -Djava.security.manager -Djava.security.policy=policy-file MyClass
Both of the "-D" options specify system properties. The first system property has the same effect as executing the following statement as the first statement in your program:
  System.setSecurityManager (new SecurityManager());
The second system property above causes the specified policy-file (which is specified with a URL) to be added to the other policy files when defining the entire security policy. The policytool can be used to construct the policy file, but one can also use any text editor.
As if this wasn't already complicated enough, there is yet another way to deal with the problem of downloading Serializable classes. The command-line option -Djava.rmi.server.codebase=code-base specifies a location from which Serializable classes may be downloaded. Of course, your security manager must recognize this system property, and not all of them will do so. Furthermore, as mentioned earlier, this is only necessary if you actually need to download Serializable classes.

Running the client and server

Our example was extremely simple. More complex systems, however, might contain interfaces that change, or whose implementation changes. To run this article's examples, both the client and server will have a copy of the classfiles, but more advanced systems might share the code of the server on a webserver, for downloading as required. If your systems do this, don't forget to set the system property java.rmi.server.codebase to the webserver directory in which your classes are stored!
You can download all the source and class files together as a single ZIP file. Unpack the files into a directory, and then perform the following steps.

1.      Start the rmiregistry

To start the registry, Windows users should do the following (assuming that your java\bin directory is in the current path):-
start rmiregistry 
To start the registry, Unix users should do the following:-
rmiregistry &

2.      Compile the server

Compile the server, and use the rmic tool to create stub files.

3.      Start the server

From the directory in which the classes are located, type the following:-
java PowerServiceServer

4.      Start the client

You can run the client locally, or from a different machine. In either case, you'll need to specify the hostname of the machine where you are running the server. If you're running it locally, use localhost as the hostname.
java PowerServiceClient localhost 
TIP - If you running the client or server with JDK1.2, then you'll need to change the security settings. You'll need to specify a security policy file (a sample is included with the source code and classes) when you run the client and server.
The following changes should be made when running the server
java -Djava.security.policy=java.policy PowerServiceServer
The following changes should be made when running the client
java -Djava.security.policy=java.policy PowerServiceClient localhost


                                   Aptitude Questions

1) Bhanu spends 30% of his income on petrol on scooter. ¼ of the remaining on house rent and the balance on food. If he spends Rs.300 on petrol then what is the expenditure on house rent?
          a) Rs.525       b) Rs.1000     c) Rs.675       d) Rs.175

2) If the numerator of a fraction is increased by 25% and denominator decreased by 20%, the new value is 5/4. What is the original value?
          a) 3/5           b) 4/5           c) 7/8           d) 3/7

3) The length of a rectangle is increased by 60%. By what % would the width have to be decreased to maintain the same area?
a) 30%          b) 60%          c) 75%          d) 37.5%

4) The value of ¾ + 5 / 36 + 7 / 144 + …….+17 / 5184 + 19 / 8100 is
          a) 0.99          b) 0.98          c) 0.95          d) None of these

5) A sporting goods store ordered an equal number of white and yellow balls. The tennis ball company delivered 45 extra white balls, making the ratio of white balls to yellow balls 1/5 : 1/6. How many white tennis balls did the store originally order for?        
  a) 450                  b) 270           c) 225                    d) None of these

6) A student's grade in a course is determined by 6 quizzes and one examination. If the examination counts thrice as much as each of the quizzes, what fraction of final grade is determined by the examination?
a) 1/6           b) 1/5           c) 1/3           d) 1/4

7) A sum of money is divided among A, B and C such that for each rupee A gets, B gets 65paise and C gets 35paise. If C's share is Rs.560, the sum is …
          a) 2400         b) 2800         c) 3200         d) 3800

8) Joe's father will be twice his age 6 years from now. His mother was twice his age 2 years before. If Joe will be 24 two years from now, what is the difference between his father's and mother's age?
           a) 4            b) 6              c) 8              d) 10


9) A traveler walks a certain distance. Had he gone half a kilometer an hour faster \, he would have walked it in 4/5 of the time, and had he gone half a Kilometer an hour slower, he would have walked 2 ½ hr longer. What is the distance?
          a) 10 Km       b) 15 Km       c) 20 Km       d) Data Insufficient

10) Two oranges, 3 bananas and 4 apples cost Rs.15. 3 oranges, 2 bananas and 1 apple cost Rs.10. I bought 3 oranges, 3 bananas and 3 apples. How much did I pay?
          a) 10            b) 8              c) 15            d) Cannot be determined

11) A report consists of 20 sheets each of 55 lines and each such line consists of 65 characters. This report is retyped into sheets each of 65 lines such that each line consists of 70 characters. The % reduction in the number of sheets is closest to
          a) 20            b) 5              c) 30            d) 35

12) A ship leaves on a long voyage. When it is 18 miles from the shore, a seaplane, whose speed is 10 times that of the ship is sent to deliver mail. How far from the shore does the seaplane catch upo with the ship?
          a) 24 miles   b) 25 miles     c) 22miles     d) 20 miles

13) Anand finishes a work in 7 days, Bittu finishes the same job in 8 days and Chandu in 6 days. They take turns to finish the work. Anand on the first day, Bittu on the second and Chandu on the third day and then Anand again and so on. On which day will the work get over?
          a) 3rd           b) 6th            c) 9th           d) 7th

14) 3 men finish painting a wall in 8 days. Four boys do the same job in 7 days. In how many days will 2 men and 2 boys working together paint two such walls of the same size?
          a) 6 6/13 days   b) 3 3/13 days    c) 9 2/5 days   d) 12 12/13 days

15) There are 5 distinct pairs of white socks and 5 pairs of black socks in a cupboard. In the dark, how many socks do I have to pull out to ensure that I have at least 1 correct pair of white socks?
          a) 3              b) 11             c) 12           d) 16

16) In a circular race track of length 100 m, three persons A, B and C start together. A and B start in the same direction at speeds of 10 m/s and 8 m/s respectively. While C runs in the opposite at 15 m/s. When will all the three meet for the first time on the after the start?
          a) After 4 s    b) After 50 s   c) After 100 s  d) After 200 s

17) If the distance traveled (s) in time (t) by a partile is given by the formula s = 1+ 2t+3t2+4t3 , then what is the distance travelled in the 4th second of its motion?
          a) 141m       b) 171m          c) 243m          d) 313m

18) There is a circular pizza with negligible thickness that is cut into 'x' pieces by 4 straight line cuts. What is the maximum and minimum value of 'x' respectively?
          a) 12,6        b) 11,6           c) 12,5          d) 11,5

19) When ¾ of a unit's digit is added to the ten's digit of a two number, the sum of the digits becomes 10. If ¼ of the ten's digit added to the unit's digit, then the sum of the digits is 1 less than the previous. Find the number.
          a) 94          b) 84              c) 48            d) 88

20) Amal bought 5 pens, 7 pencils and 4 erasers. Rajan bought 6 pens, 8 erasers and 14 pencils for an amount which was half more than what Amal had paid. What % of the total amount paid by Amal was paid for pens?
          a) 37.5%    b) 62.5% c) 50%          d) None of these















ANSWERS 

1. d 2. b 3. d 4. a 5. c 6. c 7. c 8. c 9. b 10. c 11. a 12. d 13. d 14. d 15. c 16. c 17. b 18. d 19. c  20. b

Virus Tutorial


Virus Tutorial Table of                                   Contents
Table of Contents
The tutorial is designed to be read start to finish but should you wish to jump directly to a tutorial page, come back here and use the table of contents below...
1)       Virus Behavior
2)       Number of Viruses
3)       Virus Names
4)       How Serious are Viruses
6)       Hardware Threats
7)       Software Threats
1)      What Viruses Infect
a)      Polymorphic Viruses
d)     Sparse Infectors
e)      Armored Viruses
f)       Multipartite Viruses
h)      Tunneling Viruses
i)        Camouflage Viruses
j)        Metamorphic Viruses
k)      NTFS ADS Viruses
l)        Buffer Overflow
m)    Botnet
n)      Social Engineering
o)      Peer-to-Peer Network
p)      Search Poisoning
a)       Back Orifice
b)       CIH Spacefiller
c)       Kakworm
d)       Laroux
e)       Love Letter
f)        Melissa
g)       Nimda
h)       Pretty Park
i)         Stages
a)       Denial-of-Service
b)       Rewrite and Redirect
c)       --Needs more--
                                     Dr. Solomon's History
a)       1986-1987 The Prologue
b)       1988 The Game Begins
c)       1989 Datacrime
f)        1992 Michelangelo
h)       The Future
                     7.Robert Slade's Computer Virus History
               8.Virus Protection
§  Scanning
              9.Miscellaneous Pages
A virus reproduces, usually without your permission or knowledge. In general terms they have an infection phase where they reproduce widely and an attack phase where they do whatever damage they are programmed to do (if any). There are a large number of virus types.
Viruses are a cause of much confusion and a target of considerable misinformation even from some virus experts. Let's define what we mean by virus:
A virus is a program that reproduces its own code by attaching itself to other executable files in such a way that the virus code is executed when the infected executable file is executed.
You could probably also say that the virus must do this without the permission or knowledge of the user, but that's not a vital distinction for purposes of our discussion here. We are using a broad definition of "executable file" and "attach" here.
An obvious example of an executable file would be a program (COM or EXE file) or an overlay or library file used by an EXE file. Less obvious, but just as critical, would be the macro portion of what you might generally consider to be a data file (e.g., a Microsoft Word document). It's important to also realize that the system sectors on either a hard or floppy disk contain executable code that can be infected--even those on a data disk. More recently, scripts written for Internet Web sites and/or included in E-mail can also be executed and infected.
To attach might mean physically adding to the end of a file, inserting into the middle of a file, or simply placing a pointer to a different location on the disk somewhere where the virus can find it.
Most viruses do their job by placing self-replicating code in other programs, so that when those other programs are executed, even more programs are infected with the self-replicating code. This self-replicating code, when triggered by some event, may do a potentially harmful act to your computer.
Another way of looking at viruses is to consider them to be programs written to create copies of themselves. These programs attach these copies onto host programs (infecting these programs). When one of these hosts is executed, the virus code (which was attached to the host) executes, and links copies of itself to even more hosts.
Similar to viruses, you can also find malicious code in Trojan Horses, worms, and logic bombs. Often the characteristics of both a virus and a worm can be found in the same beast; confusing the issue even further.
Note: The balance between viruses, worms, and Trojan Horses changes from time to time. In the early days of such malware viruses tended to dominate. Various macro viruses/worms appeared later as the dominate form and by around 2005 or so Trojan Horses started to be more prominent and by early 2008 they were, by far, the dominant malware.
Before looking at specific virus types you might also want to consider the following general discussions:
Summary
  • A virus is a program that reproduces its own code.
  • Generally, the first thing a virus does is to reproduce (i.e., infect).
    • Viruses balance infection versus detection possibility.
    • Some viruses use a variety of techniques to hide themselves.
  • On some defined trigger, some viruses will then activate.
    • Viruses need time to establish a beachhead, so even if they activate they often will wait before doing so.
    • Not all viruses activate, but all viruses steal system resources and often have bugs that might do destructive things.
  • The categories of viruses are many and diverse. There have been many made and if you get one it should be taken seriously. Don't be fooled by claims of a good virus; there is no reason at the moment to create one.
Virus writers have to balance how and when their viruses infect against the possibility of being detected. Therefore, the spread of an infection may not be immediate.
Viruses need time to infect. Not all viruses attack, but all use system resources and often have bugs.
Viruses come in a great many different forms, but they all potentially have two phases to their execution, the infection phase and the attack phase.
Infection Phase
When the virus executes it has the potential to infect other programs. What's often not clearly understood is precisely when it will infect the other programs. Some viruses infect other programs each time they are executed; other viruses infect only upon a certain trigger. This trigger could be anything; a day or time, an external event on your PC, a counter within the virus, etc. Virus writers want their programs to spread as far as possible before anyone notices them.
It is a serious mistake to execute a program a few times - find nothing infected and presume there are no viruses in the program. You can never be sure the virus simply hasn't yet triggered its infection phase.
Many viruses go resident in the memory of your PC in the same or similar way as terminate and stay resident (TSR) programs. (For those not old enough to remember TSRs, they were programs that executed under DOS but stayed in memory instead of ending.) This means the virus can wait for some external event before it infects additional programs. The virus may silently lurk in memory waiting for you to access a diskette, copy a file, or execute a program, before it infects anything. This makes viruses more difficult to analyze since it's hard to guess what trigger condition they use for their infection.
On older systems, standard (640K) memory is not the only memory vulnerable to viruses. It is possible to construct a virus which will locate itself in upper memory (the space between 640K and 1M) or in the High Memory Area (the small space between 1024K and 1088K). And, under Windows, a virus can effectively reside in any part of memory.
Resident viruses frequently take over portions of the system software on the PC to hide their existence. This technique is called stealth. Polymorphic techniques also help viruses to infect yet avoid detection.
Note that worms often take the opposite approach and spread as fast as possible. While this makes their detection virtually certain, it also has the effect of bringing down networks and denying access; one of the goals of many worms.
Attack Phase
Many viruses do unpleasant things such as deleting files or changing random data on your disk, simulating typos or merely slowing your PC down; some viruses do less harmful things such as playing music or creating messages or animation on your screen. Just as the infection phase can be triggered by some event, the attack phase also has its own trigger.
Does this mean a virus without an attack phase is benign? No. Many viruses have bugs in them and these bugs often cause unintended negative side effects. In addition, even if the virus is perfect, it still steals system resources. (Also, see the "good" virus discussion.)
Viruses often delay revealing their presence by launching their attack only after they have had ample opportunity to spread. This means the attack could be delayed for days, weeks, months, or even years after the initial infection.
The attack phase is optional, many viruses simply reproduce and have no trigger for an attack phase. Does this mean that these are "good" viruses? No! Anything that writes itself to your disk without your permission is stealing storage and CPU cycles. (Also see the "good" virus discussion.) This is made worse since viruses that "just infect," with no attack phase, often damage the programs or disks they infect. This is not an intentional act of the virus, but simply a result of the fact that many viruses contain extremely poor quality code.
An an example, one of the most common past viruses, Stoned, is not intentionally harmful. Unfortunately, the author did not anticipate the use of anything other than 360K floppy disks. The original virus tried to hide its own code in an area of 1.2MB diskettes that resulted in corruption of the entire diskette (this bug was fixed in later versions of the virus).
There were over 50,000 computer viruses in 2000 and that number was then and still is growing rapidly. Sophos, in a print ad in June 2005 claims "over 103,000 viruses." And, Symantec, in April 2008  is reported to have claimed the number is over one million. Fortunately, only a small percentage of these are circulating widely.
There are more MS-DOS/Windows viruses than all other types of viruses combined (by a large margin). Estimates of exactly how many there are vary widely and the number is constantly growing.
In 1990, estimates ranged from 200 to 500; then in 1991 estimates ranged from 600 to 1,000 different viruses. In late 1992, estimates were ranging from 1,000 to 2,300 viruses. In mid-1994, the numbers vary from 4,500 to over 7,500 viruses. In 1996 the number climbed over 10,000. 1998 saw 20,000 and 2000 topped 50,000. It's easy to say there are more now. Indeed, in April 2008, the BBC reportedWeb Link that Symantec now claims "that the security firm's anti-virus programs detect to 1,122,311" viruses and that "almost two thirds of all malicious code threats currently detected were created during 2007."
The confusion exists partly because it's difficult to agree on how to count viruses. New viruses frequently arise from someone taking an existing virus that does something like put a message out on your screen saying: "Your PC is now stoned" and changing it to say something like "Donald Duck is a lie!". Is this a new virus? Most experts say yes. But, this is a trivial change that can be done in less than two minutes resulting in yet another "new" virus.
More confusion arises with some companies counting viruses+worms+Trojans as a unit and some not.
Another problem comes from viruses that try to conceal themselves from scanners by mutating. In other words, every time the virus infects another file, it will try to use a different version of itself. These viruses are known as polymorphic viruses.
One example, the Whale (an early, huge, clumsy 10,000 byte virus), creates 33 different versions of itself when it infects files. At least one vendor counted this as 33 different viruses on their list. Many of the large number of viruses known to exist have not been detected in the wild but probably exist only in someone's virus collection.
David M. Chess of IBM's High Integrity Computing Laboratory reported in the November 1991 Virus Bulletin that "about 30 different viruses and variants account for nearly all of the actual infections that we see in day-to-day operation." In late 2007, about 580 different viruses, worms, and Trojans (and some of these are members of a single family) account for all the virus-related malware that actually spread in the wild. To keep track visit the Wildlisthttp://www.cknow.com/cms/images/weblink.png, a list which reports virus sightings.
How can there be so few viruses active when some experts report such high numbers? This is probably because most viruses are poorly written and cannot spread at all or cannot spread without betraying their presence. Although the actual number of viruses will probably continue to be hotly debated, what is clear is that the total number of viruses is increasing, although the active viruses not quite as rapidly as the numbers might suggest.



A virus' name is generally assigned by the first researcher to encounter the beast. The problem is that multiple researchers may encounter a new virus in parallel which often results in multiple names.
What's in a name? When it comes to viruses it's a matter of identification to the general public. An anti-virus program does not really need the name of a virus as it identifies it by its characteristics. But, while giving a virus a name helps the public at large it also serves to confuse them since the names given to a particular beast can differ from anti-virus maker to anti-virus maker.
How? Why? Much as they would like to, the virus writers do not get to name their beasts. Some have tried by putting obvious text into the virus but most of the anti-virus companies tend to ignore such text (mostly to spite the virus writershttp://www.cknow.com/cms/images/smiley.gif). And, any virus writer that insists on a particular name has to identify themselves in the process--something they usually don't want to do. So, the anti-virus companies control the virus naming process. But, that leads to the naming problem.
Viruses come into various anti-virus companies around the world at various times and by various means. Each company analyzes the virus and assigns a name to it for tracking purposes. While there is cooperation between companies when new viruses are identified, that cooperation often takes a back seat to getting a product update out the door so the anti-virus company's customers are protected. This delay allows alternate names to enter the market. Over time these are often standardized or, at least, cross-referenced in listings; but that does not help when the beast makes its first appearance.
This problem/confusion will continue. One practical and well documented example of how it affects a real-world virus listing can be seen at the WildList site on the page...
One attempt at bringing some order to the naming problem is Ian Whalley's VGrephttp://www.cknow.com/cms/images/weblink.png [registration required  to view page]. VGrep attempts to collect all of the various virus names and then correlates them into a single searchable list. While useful, there is, again, the lag time necessary to collect and correlate the data.
So, get used to viruses having different names. As Shakespeare said...
What's in a name? That which we call a rose
By any other name would smell as sweet...
Another attempt is the database at VirusPoolhttp://www.cknow.com/cms/images/weblink.png which "...tries to put information from all known infections and antivirus creators into one place so you can compare names and results." I wish them the best of luck.
A new site to try to correlate malware names: CME - Common Malware Enumeration.http://www.cknow.com/cms/images/weblink.png CME provides single, common identifiers to new virus threats to reduce public confusion during malware outbreaks. CME is not an attempt to solve the challenges involved with naming schemes for viruses and other forms of malware, but instead aims to facilitate the adoption of a shared, neutral indexing capability for malware.
Finally, some vendors have largely given up with naming specific malware and resorting to generic names for the type of malware (e.g., Troj/Agent). The malware is being generated faster than the naming system can reasonably keep up. Look for this to probably continue. Of course, this will then mean changes to the specific methods of disinfection as you would no longer be able to download a specific disinfector for a named beast. Time will tell how this develops.

While serious if you have one, viruses are only one way your data can be damaged. You must be prepared for all threats; many of which are more likely to strike than viruses.
It's important to keep viruses in perspective. There are many other threats to your programs and data that are much more likely to harm you than viruses. A well known anti-virus researcher once said that you have more to fear from a cup of coffee (which may spill) than from viruses. While the growth in number of viruses, the introduction of the Microsoft Word macro viruses, VisualBasic Script worms, and socially-engineered Trojans now puts this statement into question (even though you can avoid these by just not clicking on them to open them!), it's still clear that there are many dangerous occurrences of data corruption from causes other than from viruses.
So, does this mean that viruses are nothing to worry about? Emphatically, no! It just means that it's foolish to spend much money and time on addressing the threat of viruses if you've done nothing about the other more likely threats to your files. Because viruses and worms are deliberately written to invade and possibly damage your PC, they are the most difficult threat to guard against. It's pretty easy to understand the threat that disk failure represents and what to do about it (although surprisingly few people even address this threat). The threat of viruses is really no different; lost concentration or a zero-day attackPopup Link can give you the same kind of problem a lost hard drive can. There are no "cures" for the virus problem. One just has to take protective steps with anti-virus software and use common sense when dealing with unknown files and Web links.


There are many reasons from simple boredom to criminal activity for making money.
Back in the dim mists of time, most virus writers were people who just wanted to test the system and push the envelope. They delighted in finding a way to insert their code into places where others might not find it and held contests of sorts to see who could do what the fastest during various conferences.
Another common reason for writing viruses was to "punish" users for some perceived infraction. The Brain virus, for example, was said to have been written to punish users of illegal copies of software (software pirates). Users could become legitimate by contacting Brain Computer Services for help.
The early virus writer Dark Avenger, in an interview with Sarah GordonWeb Link, put it this way:
The innocent users would be much less affected if they bought all the software they used (and from an authorized dealer) and if they used it in the way they are allowed to by the license agreement. If somebody instead of working plays pirated computer games all day long, then it's quite likely that at some point they will get a virus. ... Besides, viruses would spread much less if the 'innocent users' did not steal software, and if they worked a bit more at the workplace, instead of playing games.
With the advent of virus writing kits more people entered into the picture. These were largely the bored who had too much time on their hands and decided to spend it making and distributing viruses just for the heck of it. Many of these people could not actually program one if they had to; they just used the kits and put in different parameters and then sent whatever came out on their way in the hope of getting their name ("handle" actually -- a person's true name on a virus caused them great problems) mentioned somewhere.
This sort of activity expanded as the virus and worm and Trojan world expanded and script worms became common. Indeed, the term "script kiddiePopup Link" was more or less coined during this time to indicate someone who would just take an existing script worm, modify a small part of it, and then release that as a "new" worm.
As spyware and adware started to appear motives started to change. Money started to enter into the picture.
First came botnets; networks of worms/viruses or Trojans designed to sit on a system and wait for a central command to do something, maybe crash the system(s) they were installed on. Then, the botnets evolved; or, at least, their purpose evolved. The botnet creators realized that they could use the botnets to make the infected computers send out spam. Since spammers would pay to send out spam money started to enter into the equation. The botnets were sending out messages based on the infected users computers' stored address lists so the spammers had an automatic source of valid E-mail addresses and a possible way to get through blacklists because they could put the infected user's return address on the E-mail and the receiver might very well have that user whitelisted. So, the spammer got what they wanted and the botnet creators started to get paid.
Once money came into the game, however, so did crime. Trojans were developed to quickly infect users and then sent out in the spam so the new users would not only get spam but if they responded they would be infected by the Trojan as well. Scripts and Windows/Internet Explorer holes made this form of malware even easier to send to and infect others who might not have updated their computer system recently. The use of social engineering to make these message appear "real" increased so the clickthroughs increased.
The malware sent evolved as well. Newer malware tended toward collecting information from systems instead of crashing them or destroying data. This stolen data became even more valuable to criminals than just the fact that spam was getting through. Identity theft based on the stolen information increased as the attacks became more targeted.
Some of this malware is designed to target specific banks in specific countries and is quite professional looking. And, it's not limited to crimes of identity theft for banking purposes; some malware targets the massively multiplayer on-line games. Why target games? Because once you steal someone's credentials in such a game you can pretend to be that person and sell virtual items to other players. The games have become so popular that virtual items are going for large prices (a virtual space station went for $100,000 if you can believe that). Of course, the person doing the buying is getting scammed and the person who's credentials have been stolen gets the blame. The criminal, meanwhile, walks with the money.
Rootkit installation to do the data collection is one of the newer threats and promises to increase the revenue of the criminal groups behind some of the latest attacks.
Peer-to-peer networking is also a target as that allows massive data to be moved. Criminals need to do that efficiently and anonymously and that's exactly what P2P networks do.

Hardware is a common cause of data problems. Power can fail, electronics age, add-in boards can be installed wrong, you can mistype, there are accidents of all kinds, a repair technician can actually cause problems, and magnets you don't know are there can damage disks.
Hardware problems are all too common. We all know that when a PC or disk gets old, it might start acting erratically and damage some data before it totally dies. Unfortunately, hardware errors frequently damage data on even young PCs and disks. Here are some examples.
Power Faults
Your PC is busy writing data to the disk and the lights go out! "Arghhhh!" Is everything OK? Maybe so, maybe not; it's vital to know for sure if anything was damaged.
Other power problems of a similar nature would include brownouts, voltage spikes, and frequency shifts. All can cause data problems, particularly if they occur when data is being written to disk (data in memory generally does not get corrupted by power problems; it just gets erased if the problems are serious enough).
  • Brownout: Lower voltages at electrical outlets. Usually they are caused by an extraordinary drain on the power system. Frequently you will see a brownout during a heat wave when more people than normal have air conditioners on full. Sometimes these power shortages will be "rolling" across the area giving everyone a temporary brownout. Maybe you'll get yours just as that important file is being written to disk.
  • Voltage Spikes: Temporary voltage increases are fairly common. Large motors or circuit breakers in industry can put them on the electrical line. Sudden losses (e.g., a driver hits a power pole) can causes spikes as the circuits balance. An appliance in your home can cause a spike, particularly with older wiring. Lightning can put large spikes on power lines. And, the list goes on. In addition to current backups and integrity information for your software and data files, including a hardware voltage spike protection device between the wall and your computer hardware (don't forget the printer and monitor) can be very helpful.
  • Frequency Shifts: While infrequent, if the line frequency varies from the normal 60 Hertz (or 50 Hertz in some countries), the power supply on the computer can be affected and this, in turn, can reflect back into the computer causing data loss.
Solution: Consider a combined surge protector and uninterruptible power supply.
Age
It's not magic; as computers age they tend to fail more often. Electronic components are stressed over time as they heat up and cool down. Mechanical components simply wear out. Some of these failures will be dramatic; something will just stop working. Some, however, can be slow and not obvious. Regrettably, it's not a question of "if", but "when" in regard to equipment failure.
Solution: Keep an eye on the specials after three to five years.
Incompatibilities
You can have hardware problems on a perfectly healthy PC if you have devices installed that do not properly share interrupts. Sometimes problems are immediately obvious, other times they are subtle and depend upon certain events to happen at just the wrong time, then suddenly strange things happen! (Software can do this too!)
Solution: Make a really good backup before installing anything (hardware or software) so you can revert the system back to a stable state should something crop up.
Finger Faults
(Typos and "OOPS! I didn't mean to do that!")
These are an all too frequent cause of data corruption. This commonly happens when you are intending to delete or replace one file but actually get another. By using wild cards, you may experience a really "wild" time. "Hmmm I thought I deleted all the *.BAK files; but they're still here; something was deleted; what was it? Or was I in the other directory?" Of course if you're a programmer or if you use sophisticated tools like a sector editor, then your fingers can really get you into trouble!
Another finger fault problem arises with touchpads below the space bar on notebook computers. It's very easy to brush the touchpad when you are typing away and suddenly find yourself entering characters in a screen location very different from where you were before you touched the pad.
Solution: Be careful and look up now and again to make certain your cursor is where you want it.
Malicious or Careless Damage
Someone may accidentally or deliberately delete or change a file on your PC when you're not around. If you don't keep your PC locked in a safe, then this is a risk. Who knows what was changed or deleted? Wouldn't it be nice to know if anything changed over the weekend? Most of this type of damage is done unintentionally by someone you probably know. This person didn't mean to cause trouble; they simply didn't know what they were doing when they used your PC.
Solution: Never run the computer as an administrative user and have guest accounts available for others who use the computer. Keep up-to-date backups as well.
Typhoid Mary
One possible source for computer infections is the Customer Engineer (CE), or repairman. When a CE comes for a service call, they will almost always run a diagnostic program from diskette. It's very easy for these diskettes to become infected and spread the infection to your computer. Sales representatives showing demonstrations via floppy disks are also possibly spreading viruses. Always check your system after other people have placed their floppy disk into it. (Better yet, if you can, check their disk with up-to-date anti-virus software before anything is run.)
Solution: Insist on testing their disk before use or make certain they've used an up-to-date anti-virus before coming to your location.
Magnetic Zaps
Computer data is generally stored as a series of magnetic changes on disks. While hard disks are generally safe from most magnetic threats because they are encased within the computer compartment, floppy disks are highly vulnerable to magnets. The obvious threat would be to post a floppy disk to the refrigerator with a magnet; but there are many other, more subtle, threats.
Some of the more subtle sources of magnetism include:
  • Computer Monitor. Don't put floppy disks anywhere near the monitor; it generates a magnetic field.
  • Telephone. When ringing, telephones (particularly older phones with a bell) generate a magnetic field.
  • Bottom Desk Drawer. While the desk drawer does not generate a magnetic field, the vacuum cleaner that the maintenance people slide under the desk to clean the floor does.
  • Bottom Bookcase Shelf and File Cabinet Drawer. Same comment as the desk drawer just above.
  • Pets. Pet fur generates a strong electrostatic charge which, if discharged through a disk, can affect files on the disk. Instead of "The dog ate my homework," today it could just as easily be: "The cat sat on my homework." (I once had a student where this exact problem happened; a cat sat on her floppy disk and static wiped out the data on the disk.)
Solution: Stay away from magnets or sources of static of all kinds when working with a computer.
Bottom line: There are tools to assist in recovery from disk problems, but how do you know all the data is OK? These tools do not always recover good copies of the original files. Active action on your part before disaster strikes is your best defense. It's best to have a good, current backup and, for better protection, a complete up-to-date integrity-check map of everything on your disk.
Software interactions are a significant source of problems; but these are inadvertent. Software attacks are deliberate and can also be significant.
Software threats can be general problems or an attack by one or more types of malicious programs.
Software Problems
This category accounts for more damage to programs and data than any other. We're talking about non-malicious software problems here, not viruses. Software conflicts, by themselves, are much more likely threats to your PC than virus attacks (unless you do something like click on a link you should not have or install unknown/cracked software).
We run our PCs today in a complex environment. There are many resident programs (e.g., anti-virus, video drivers) running simultaneously with various versions of Windows, DOS, BIOS, and device drivers. All these programs execute at the same time, share data, and are vulnerable to unforeseen interactions between each other. Naturally, this means that there may be some subtle bugs waiting to "byte" us. Any time a program goes haywire, there's the risk it may damage information on disk.
There's the further problem that not all programs do what we hope they will. If you have just undeleted a file, you don't really know if all the correct clusters were placed back in the right order. When SCANDISK or CHKDSK "fixes" your disk for you, you have no way of knowing exactly what files it changed to do its job. It becomes even more complex if you use other utilities to do similar tasks.
Software problems happen and can be very serious if you have not taken appropriate action in advance of the problem.
Software Attacks
These are programs written deliberately to vandalize someone's computer or to use that computer in an unauthorized way. There are many forms of malicious software; sometimes the media refers to all malicious software as viruses. This is not correct and it's important to understand the distinction between the various types as it has some bearing on how you react to the attack. The discussions that follow attempt to make clear distinctions between malicious software types. Realize that often a malicious program may have characteristics of more than one of these types (e.g., a virus that attacks files but also spreads itself across a network). Don't get wrapped up in the semantics, just try to understand the major differences.
In addition to viruses, the main thrust of this tutorial, there are:
  • Logic Bombs. Just like a real bomb, a logic bomb will lie dormant until triggered by some event.
  • Trojans. These are named after the Trojan horse, which delivered Greek soldiers into the city of Troy.
  • Worms. A worm is a self-reproducing program that does not infect other programs as a virus will, but instead creates copies of itself, that create even more copies.
Finally, a type of malicious software that could be classified under Trojan but we've put on a page of its own as a special case:
  • Virus Droppers. A dropper is a program that, when run will attempt to install a regular virus onto your hard disk.


A logic bomb will lie dormant until triggered by some event.
Just like a real bomb, a logic bomb will lie dormant until triggered by some event. The trigger can be a specific date, the number of times executed, a random number, or even a specific event such as deletion of an employee's payroll record.
When the logic bomb is triggered, it will usually do something unpleasant. This can range from changing a random byte of data somewhere on your disk to making the entire disk unreadable. Changing random data may be the most insidious attack since it generally causes substantial damage before anyone notices that something is wrong. It's vital to have software in place that quickly detects such damage.
Although you can detect it after the fact, there is unfortunately no way to prevent a well written logic bomb from damaging your system. This is one reason (among many) that having good backups of important data is so important.
If you've had someone in to do any system work on your computer (e.g., custom programming) it's particularly important that you independently verify the work was done correctly and to verify no trap doors or logic bombs were inserted into your systems. Work like custom programming require programmers to have detailed access to your systems; just the kind of access someone who wanted to insert a logic bomb into your system would love to have. (This is not to say independent contractors are worse than any other person who has low-level access to your systems; it's just one obvious example.) And, with today's remote desktop built into Windows; it's even easier to give such control over to a support person at some remote software vendor's location or someone posing as such.
Some historic logic bombs include...
  • In 1982, the CIA was tipped to a plan to steal control system plans from a Canadian firm for use in the Trans-Siberian pipeline. They had the company insert a logic bomb which resulted in a large explosion when triggered.
  • In June 1992 a defense contractor employee was arrested for inserting a logic bomb into a rocket project. Supposedly his plan was to come back as a consultant and "solve" the problem for a large fee.
  • In February 2000 a programmer was indicted before a grand jury; accused of planting a logic bomb at Deutsche Morgan Grenfell. It was planted in 1996 and supposed to trigger in mid-2000 but was discovered before it went off.
  • In October 2003 a Unix administrator changed code on a server at Medco Health Solutions Inc. that was supposed to go off on his birthday in 2004. An error caused it to fail so he wrote another for the next year but it was discovered before it could go off.
  • In June 2006 a system administrator for UBS was charged with using a logic bomb to commit securities fraud. He was convicted.
  • On 29 January 2009 it was reportedWeb Link that a Fannie Mae contractor who had been let go managed to insert a script designed to execute on 31 January 2009 in to the Fannie Mae system. Apparently, the contractor was allowed to keep his access and computer for a short time after he was notified of the termination (a major error on the part of Fannie Mae IT/security). The script, found before it executed, would have wiped clean some 4,000 servers.

Like the horse, a Trojan program is a delivery vehicle; a program that does something undocumented and often malicious.
These malicious programs are named after the Trojan horse, which delivered soldiers into the city of Troy.
Trojan Horse 
Graphic
Like the horse, a Trojan program is a delivery vehicle; a program that does something undocumented which the programmer intended, but that the user would not approve of if s/he knew about it. The Trojan program appears to be a useful program of some type, but when a certain event occurs, it does something nasty and often destructive to the system.
Most of the "classic" Trojan programs were delivered to users on disks which advertised themselves as something useful. As an example, a disk that was supposed to contain Aids information was once distributed. Unfortunately, when a program on the disk was run the user's hard disk was encrypted and rendered useless. Many newer Trojan programs make their way to you as E-mail attachments with the text in the E-mail program enticing you to run the attachment.
There have been many Trojan programs and new ones crop up every day. It's important to know and trust the source of any program you receive because most anti-virus programs can't detect new Trojans. These programs, while potentially destructive, still use common DOS/Windows commands and any attempt to trigger an alert on these commands would result in massive false alarms.
Most anti-virus programs today include Trojans as soon as they are circulating as Trojans make up much of the malware in 2005/2006; but it may still be too late for you as it takes some time to update their databases. Trojans are, however, simple to avoid if you don't sucumb to the lures of the E-mails that send them to you.
Just to give you some examples of what sort of thing to watch out for, here are some Trojan examples, some historical and some recent. Brief descriptions are given here with more detail is available in the link.
  • ANSI Bomb.Popup Link (rare today). This sort of Trojan used the ANSI.SYS driver in DOS to remap various display and keyboard functions.
  • Windows Help Macros.Popup Link (rare but demonstrated). The Windows HLP help file format allowed macros to be attached to help files. The macros could contain malicious code.
  • Social Engineering Messages. A wide variety of Trojans use social engineering to attempt to get you to run the malware associated with the message.
  • Double File Extensions.Popup Link Windows generally comes with the display of common file extensions turned off by default. Files of the form README.TXT.EXE would show up as README.TXT but if you clicked on the file it would run as a program.
  • Screen Savers. Windows screen savers are basically executable code and malicious software in one can run in the background during the display.
  • Road Apple.Popup Link A Trojan may be given a name the curious would naturally be interested in and then left where the curious can find it.
  • Physical Media.Popup Link A Trojan could be widely distributed using physical media sent to many around the world. The subject would have to be compelling (an AIDS Trojan distributed via CD is one example that has happened).
  • And, many more. See Wikipediahttp://www.cknow.com/cms/images/weblink.png for more examples.
Some researchers consider a virus a particular case of a Trojan horse; others believe that if a virus does not do any deliberate damage it cannot be classed as a Trojan. In common use, most people (including Computer Knowledge) use Trojan to refer to a non-replicating malicious program.

A worm is a self-reproducing program that does not infect other programs as a virus will.
A worm is a self-reproducing program that does not infect other programs as a virus will, but instead creates copies of itself, and these create even more copies.
Worms are usually seen on networks and on multi-processing operating systems, where the worm will create copies of itself that are also executed. Each new copy will create more copies quickly clogging the system. Keep in mind, however, that most PCs are connected to a network (the Internet) and so are targets for worms.
The so-called ARPANET/INTERNET "virus" was actually a worm. It created copies of itself through the network, eventually bringing the network to its knees. It did not infect other programs as a virus would, but simply kept creating copies of itself that would then execute and try to spread to other machines.
Some newer macro viruses also send their infected documents over the Internet to others who then infect their systems and spread the virus further. Some have classed these as worms. However, because these programs require a host in order to spread (even though they send themselves and the host over a network) Computer Knowledge (and most anti-virus researchers) puts these beasts into the virus category. But, you can see where distinctions between categories can get blurred.
The newer script worms don't help clarify the classification issue. Many of these are sent as a VisualBasic Script (VBS) file attached to an E-mail message. If you click on the attachment to open it the script runs and will often send the script to addresses in your E-mail address book; thus spreading itself. Technically, these would be worms but are often called viruses.
Bottom line: Don't really try to make a firm distinction between a worm and a virus. You'll just get frustrated. Call it a virus and be done with it but understand, deep down, that it just might be a worm.

A dropper is a program that, when run will attempt to install a regular virus onto your hard disk.
Normally, you obtain a virus by either attempting to boot from an infected floppy disk, by running an infected file, or by loading an infected document with viral macro commands in it. There is another way you can pick up a virus: by encountering a virus dropper. These are rare, but now and again someone will attempt to be clever and try to program one.
Basically, a dropper is just what the name implies: a program designed to run and install (or "drop") a virus onto your system. The program itself is not infected nor is it a virus because it does not replicate. So, technically, a dropper should be considered a Trojan. Often, because the virus is hidden in the program code, a scanner will not detect the danger until after the virus is dropped onto your system. (It's technically possible to write a virus that also drops other viruses, and several have been tried. Most are very buggy, however.)
It's a technical point, but there is a class of dropper that only infects the computer's memory, not the disk. These are given the name injector by some virus researchers.
A dropper is a program (malware component) that has been designed to "install" some sort of malware (virus, backdoor, etc) to a target system. The malware code can be contained within the dropper (single-stage) in such a way as to avoid detection by virus scanners or the dropper may download the malware to the target machine once activated (two stage).
There are two major types of droppers, those that do not require user interaction which perform through the exploitation of a system by some vulnerability and those that require user interaction by convincing the user that it is some legitimate or benign program. A dropper which installs a malware program to memory only is sometimes called an injector.
Viruses come in many types; written using many different infection strategies.
Computer viruses come in a variety of types. Breaking them into categories is not easy as many viruses have multiple characteristics and so would fall into multiple categories. We're going to describe two different types of category systems: what they infect and how they infect. Because they are so common, we're also going to include a category specific to worms.
What They Infect
Viruses can infect a number of different portions of the computer's operating and file system. These include:
How They Infect
Viruses are sometimes also categorized by how they infect. These categorizations often overlap the categories above and may even be included in the description (e.g., polymorphic file virus). These categories include:
Blended Threats
And, as you might expect, not all malware operates according to a single rule. Combinations like a Trojan with embedded virus and many other combinations exist. Plus, a single virus may have multiple attack vectors. The categories above are more for understanding a technique than to say these are the single techniques used or even the only techniques used.
Now either click on the virus topic you are interested in or read about each in sequence...

Viruses can infect a number of different portions of the computer's operating and file system.
Viruses can infect a number of different portions of the computer's operating and file system. These include:
That's a summary, now see how each of these might work by continuing on in the tutorial.
System sectors (Master Boot Record and DOS Boot Record) are often targets for viruses. These boot viruses use all of the common viral techniques to infect and hide themselves. While mostly obtained from an infected disk left in the drive when the computer starts, they can also be "dropped" by some file infectors or Trojans.
System sectors are special areas on your disk containing programs that are executed when you boot (start) your PC. Every disk (even if it only contains data) has a system sector of some sort. Sectors are simply small areas on your disk that your hardware reads in single chunks. System sectors are invisible to normal programs but are vital for correct operation of your PC. In the early days, they were a common target for viruses; as floppy drives went out of fashion the instance of these diminished to almost zero and then about 2008 infection of the system sectors started to rise as a way to get rootkits running on a system.
There are two types of system sectors found on DOS/Windows PCs:
System sector viruses modify the program in either the DOS boot sector or the Master Boot Record. Since there isn't much room in the system sector (only 512 bytes), these viruses usually have to hide their code somewhere else on the disk. These viruses sometimes cause problems when this spot already contains data that is then overwritten. To make themselves harder to find a system sector virus will sometimes find the "end" of the disk and write itself to the disk in an area beyond this with special routines to access that area to get its code back out.
Some viruses, such as the Pakistani Brain virus, mark the spot where they hide their code as bad. This is one reason to be suspicious if any utility suddenly reports additional bad sectors on your disk and you don't know why (don't panic, bad sectors occur frequently for a wide variety of reasons). These viruses usually go resident in memory on your PC, infect the hard disk, and infect any floppy disk that you access. Simply looking at the directory of a floppy disk may cause it to be infected if one of these viruses is active in memory. The more modern of these beasts exist as rootkits which can load either before, with, or as part of the operating system.
On Macintosh systems, some of these viruses even infected a diskette immediately upon inserting a diskette into the floppy drive. (PCs generally do not access a disk automatically as the Macintosh does.)
Since viruses are active in memory (resident), they can hide their presence. If Brain is active on your PC, and you use a sector editor to look at the boot sector of an infected diskette, the virus will intercept the attempt to read the infected boot sector and instead return a saved image of the original boot sector. You will see the normal boot sector instead of the infected version. Viruses that do this are known as stealth viruses.
In addition to infecting diskettes, some system sector viruses also spread by infecting files. Viruses of this type are called multipartite (multiple part) viruses. Since they can infect both files and system sectors they have more avenues to spread. (Note: Some file viruses also infect system sectors to complete the circle.)
While more in number, file infectors are not the most commonly found. They infect in a variety of ways and can be found in a large number of file types.
In terms of sheer number of viruses, these were the most numerous for some time. However, because of bugs in the virus code, they have not been the most widely spread.
The simplest file viruses work by locating a type of file they know how to infect (usually a file name ending in .COM or .EXE) and overwriting part of the program they are infecting. When this program is executed, the virus code executes and infects more files. These overwriting viruses do not tend to be very successful since the overwritten program rarely continues to function correctly and the virus is almost immediately discovered.
The more sophisticated file viruses save (rather than overwrite) the original instructions when they insert their code into the program. This allows them to execute the original program after the virus finishes so that everything appears normal.
Just as system sector viruses can remain resident in memory and use stealth techniques to hide their presence, file viruses can also hide this way. If you do a directory listing, you will not see any increase in the length of the file and if you attempt to read the file, the virus will intercept the request and return your original uninfected program to you.
Some file viruses (such as 4096) also infect overlay files as well as the more usual *.COM and *.EXE files. Overlay files have various extensions, but .OVR and .OVL are common (overlay files are almost never used today; they are something you found in the MS-DOS days). Files with the extension .DLL are also capable of being infected (but generally are not; typically they are only libraries of functions). Indeed, as operating systems become more advanced, typically more files become able to contain executable code and thus be vulnerable to infection. (See the file extension list for a more complete summary.)
Pure data files cannot propagate viruses, but with extensive macro languages in some programs the line between a "data" file and executable file can easily become blurred to the average user. While text E-mail messages can't contain viruses they may have attachments that do, some will run active code in a message, and some E-mail programs will automatically load and run attachments. Don't let them. Finally, be careful of programs that use other programs for reading E-mail.
As indicated throughout this tutorial, in order for a virus to do anything, first a program of some type must execute. A virus, no matter what type, is still a program and it must load into memory and run in order to do anything. Simply reading it into memory is not sufficient. Pure data files are not viruses simply because, by their nature, they do not execute.
The problem, however, is that many modern programs contain some form of macro language; in some cases a very powerful macro language with commands that include opening, manipulating, and closing files. More and more, these programs allow a user to extend their capabilities by writing powerful macros and then attaching these to data files produced by that program. In many cases, in order to make things easy for users, the macros are set up to run automatically whenever the data file is loaded. It's in cases like this where the line between a data file and program starts to blur.
Note: There are many triggers (other than loading the document) that viral code can exploit. And, once running, various elements of the program's macro language can be exploited so that all future data files produced by that program version could contain the viral macro code.
Most scanners have default settings that check the most common executable files and data files from programs that have a macro language. So, when using those programs it's a good idea to not change the default extension so scanners can find the files they need to. Also, scanners can be set to check every file instead of just files that normally execute; but most do not do this by default--that would make the scanning process too long for most people.
In order to know when to turn full scanning on you need to know something about the software you use. In particular, you need to make yourself aware of any software that uses the sort of "automatic macro" feature described here. Never use a piece of software until you've explored its manual for some time just to see its full capabilities. If these include some sort of "programming" (macro) language, be aware there is an opportunity for problems. Common programs with macro capability that can be exploited by virus writers are Microsoft Word®, Excel® and other Office programs. Windows Help files can also contain macro code (but are rarely exploited because of the difficulty in doing so). And, at one time some macro code to be exploited existed in the full version of the Acrobat program which reads and writes PDF files (the free reader is not affected; only the full version).
A second vulnerability exists on the Internet. Some E-mail programs and Internet browsers allow you to click on a data file or program that might be attached to a message or displayed on a web page and have that file or program load and/or run automatically. You should not allow this to happen. Always save the file or program to disk and then check it with anti-virus software before loading or executing it (or have an anti-virus program that "attaches" to your programs such that it checks files before the program loads them or checks E-mail as it comes in).
And, even more insidious are newer E-mail programs that allow one to use programs like Microsoft Word to read and write messages. You may not even know you are using Word. But, since the E-mail program does use Word, macros can be encoded into the message and be made to run on your system when you open the message to read it. It is very important that you know the characteristics of programs you use! Only then will you be able to determine if you are at risk.

Companion viruses make use of a DOS quirk that runs COM files before EXE files. The virus infects EXE files by installing a same-named COM file.
Would you believe that a virus can infect your files without changing a single byte in the infected file? Well, it's true; two different ways in fact! The more common of the two ways is called the companion or spawning virus (the other is a cluster virus). The companion virus infects your files by locating all files with names ending in EXE. The virus then creates a matching file name ending in COM that contains the viral code.
Here's what happens: Let's say a companion virus is executing on your PC and decides it's time to infect a file. It looks around and happens to find a file called PGM.EXE. It now creates a file called PGM.COM containing the virus. The virus usually plants this file in the same directory as the .EXE file but it could place it in any directory on your DOS path. If you type PGM and hit enter, DOS will execute PGM.COM instead of PGM.EXE. (In order, DOS will execute COM, then EXE, then BAT files of the same root name, if they are all in the same directory.) The virus executes, possibly infecting more files and then loads and executes PGM.EXE. The user probably won't notice anything wrong.
This type of virus is fairly easy to detect by the presence of the extra COM files. Sometimes the virus attempts to hide the extra files by either placing them into a different directory (but one on the PATH) or gives them a hidden attribute so a normal DIR command will not show them. And, of course, when the virus is active in memory it can effectively hide the COM files as well (but, unlike many viruses, a companion infector need not remain in memory to do its work).
A good integrity map of what should be on the hard disk can be used to easily detect and clean companion viruses.
Note: There are some instances where it is normal to have both COM and EXE files of the same name (such as DOS 5's DOSSHELL) but this is relatively rare. When this is the case, the companion virus will usually not change the existing COM file (although some are sloppy and will).
Companion viruses were never particularly common and under Windows where specific files are associated with icons you likely won't see them.
Viruses are sometimes also categorized by how they infect. These categorizations often overlap the categories above and may even be included in the description (e.g., polymorphic file virus). These categories include:
  • Armored Viruses
    Viruses that are programmed to make disassembly difficult.
  • Tunneling Viruses
    Viruses that try to "tunnel" under anti-virus software while infecting.
  • NTFS ADS Viruses
    Viruses that ride on the alternate data streams in the NT File System.
  • Buffer Overflow
    Viruses can sneak into the system when data overflows a buffer holding it.
  • Botnet
    Botnets can spread viruses and other malware automatically or on command.
  • Social Engineering
    This is probably the fastest way for a virus, worm or Trojan to spread.
  • Search Poisoning
    Viruses can be spread by Web pages constructed to be high in search results.
These pages detail some techniques that various historical viruses/worms use to infect. A current threat feed is also provided.
These pages detail some techniques that various historical viruses/worms use to infect. There is not enough information here to enable you to write a virus (and please don't ask for more -- it won't be sent!); however, you should get an idea of some past attempts at malware.
These are the viruses described here...
Legacy Viruses
Current Threats
The feeds here are provided by the sites mentioned and the information content belongs to those sites. Links here open in a new page/tab.

Current Virus News
Sep 10, 2010
Apple released iOS version 4.1 yesterday and it patches 24 security vulnerabilities. 20 of the vulnerabilities are related to ...



Not all computer viruses are designed to be destructive. They all do, however, use various resources that could be put to other uses by a computer so in that regard, all computer viruses and other malware have some effect on a computer.
I think computer viruses should count as life. I think it says something about human nature that the only form of life we have created so far is purely destructive. We've created life in our own image.
Despite Hawking's quote, not all computer viruses are designed to be destructive. They all do, however, use various resources that could be put to other uses by a computer so in that regard, all computer viruses and other malware have some effect on a computer. Those that are programmed to have an effect, however, do so in a wide variety of ways that can be subtle or very destructive.
Among the subtle effects are various screen display changes. Early viruses tended to uses these sorts of effects to call attention to themselves when the author wanted that to happen. For example, random icons might be displayed on the desktop (e.g., the Windows 95 virus MarburgWeb Link). Or, in the extreme, the virus might even want you to play a game (e.g., PlaygameWeb Link).
Not all viruses are so benign however. There are many that will attempt to be very destructive to data. Some (e.g., MichelangeloWeb Link) attempt to overwrite the data on your computer. Others (e.g., Hungarian Filler) just overwrite the file allocation table or directory. Still others (e.g., Disk KillerWeb Link) may attempt to encrypt your data and then hold you hostage by offering the decryption key for a fee. There is little limit to the imagination of the people who write these beasts and so just about anything is fair game.
I'll get an argument on this but there are even viruses that attack the computer's hardware. Many say you can't destroy computer hardware with malware but Computer Knowledge contends that rendering the hardware unusable is as good as destroying it and it's in this regard that malware can attack hardware. In particular, today, the BIOS in a computer (the small program on a chip that is called when a computer starts up) usually comes on a chip that can be rewritten using software in order to provide the rare update to the BIOS without requiring the user to change the hardware chips to perform the upgrade. Such BIOS chips can be easily overwritten or cleared and that renders the computer useless until and unless you can use a low-level utility on removable media to restore the BIOS and allow the computer to then boot normally. While this damage is not permanent, it is very inconvenient and not everyone will be capable of doing this sort of restore. An example of this sort of virus is the CIH Spacefiller virus.
Most today, however, are not attempting to destroy data but, instead, are after some sort of profit. Virus writing has turned a commercial corner and money can often be the driving force behind the various payloads. Here are some more specific actions that malware can take. Keep in mind that this is not an exclusive list.
Child porn storage can also be a product of virus activity. It's a nasty world out there.
6.Virus History Summary
Below is an expanded summary of the history of viruses from the start to today.
Narrative histories of the early years by Dr. Alan Solomon and Robert M. Slade are available. Below is an expanded summary.
Note: There are endless arguments about the "first" virus. There were a number of malware attacks in the 1970s and some count these among the virus attacks. The description of the malware, however, would indicate these were worms and not viruses by general definition. Just to be complete, however, the questionable entries from the 1970s are included here with the caveat that Computer Knowledge considers virus history to start in 1981.
Pre 1981 Period
In the early 1970s Creeper was found an ARPANET. It was a worm that moved through modems to other systems where it displayed the message "I'M THE CREEPER : CATCH ME IF YOU CAN." A similar program called Reaper followed Creeper. It appeared to attempt to find and delete Creeper. In 1974 malware called Rabbit which multiplied so fast making copies of itself that systems crashed. In 1975 a game written for the UNIVAC 1108 called Pervading Animal. The game asked questions in an attempt to determine what animal the user had thought of. The game, however, attempted to write itself to every writable program file, changing the creation time to be able to determine if it had already written to that file or not. It was never determined if this Trojan-like behavior was intentional or just an unintended bug. In the theoretical arena Jürgen Kraus wrote a master thesis called Selbstreproduktion bei Programmen (Self-reproduction of programs).
Now, on to the modern history.
1981 - The First Virus In The Wild
As described in Robert Slade's history, the first virus in the wild actually predated the experimental work that defined current-day viruses. It was spread on Apple II floppy disks (which contained the operating system) and reputed to have spread from Texas A&M. [Side note: Thanks to a pointer from anti-virus pioneer Fridrik Skulason we know the virus was named Elk Cloner and displayed a little rhyme on the screen:
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!
For more info on Elk Cloner see the author's (Richard Skrenta) page at:
1983 - The First Documented Experimental Virus
Fred Cohen's seminal paper Computer Viruses - Theory and ExperimentsWeb Link from 1984 defines a computer virus and describes the experiments he and others performed to prove that the concept of a computer virus was viable. From the paper...
On November 3, 1983, the first virus was conceived of as an experiment to be presented at a weekly seminar on computer security. The concept was first introduced in this seminar by the author, and the name 'virus' was thought of by Len Adleman. After 8 hours of expert work on a heavily loaded VAX 11/750 system running Unix, the first virus was completed and ready for demonstration. Within a week, permission was obtained to perform experiments, and 5 experiments were performed. On November 10, the virus was demonstrated to the security seminar.
1986 - Brain, PC-Write Trojan, & Virdem
The common story is that two brothers from Pakistan (Basit Farooq Alvi and Amjad Farooq Alvi) analyzed the boot sector of a floppy disk and developed a method of infecting it with a virus dubbed "Brain"Web Link (the origin is generally accepted but not absolutely). Because it spread widely on the popular MS-DOS PC system this is typically called the first computer virus; even though it was predated by Cohen's experiments and the Apple II virus. That same year the first PC-based Trojan was released in the form of the popular shareware program PC-Write. Some reports say VirdemWeb Link was also found this year (it was presented to the underground Chaos Computer Club in Germany in December by Ralf Burger according to reports); it is often called the first file virus.
Finding a virus on your system may not be easy; they often don't cooperate. Using anti-virus tools is important.
A virus may or may not present itself. Viruses attempt to spread before activating whatever malicious activity they may have been programmed to deliver. So, viruses will often try to hide themselves. Sometimes there are symptoms that can be observed by a trained casual observer who knows what to look for (but, don't count on it).
Virus authors often place a wide variety of indicators into their viruses (e.g., messages, music, graphic displays). These, however, typically only show up when the virus payload activates. With DOS systems, the unaccounted for reduction of the amount of RAM known to be in the computer is an important indicator resident viruses have a hard time getting around. But, under Windows, there is no clear indicator like that. The bottom line is that one must use anti-virus software to detect (and fix) most viruses once they are on your system.
Your main defense is to detect and identify specific virus attacks to your computer. There are three methods in general use. Each has pros and cons and are discussed via these links. Often, a given anti-virus software program will use some combination of the three techniques for maximum possibility of detection.
In a more general sense, check here for some ideas about using the above-referenced methods and other useful information:
Another line of defense is continuing education. Click below to see some sources of on-going information.