CHAPTER-

INTRODUCTION
In todays world, use of information systems has become mandatory for businesses to perform the day to day functions efficiently. Use of Desktop PCs, Laptops, network connectivity including Internet, email is as essential as telephone at workplace. The employees and networked information systems are most valuable assets for any organization. The misuse of Information Systems by employees however poses serious challenges to organizations including loss of productivity, loss of revenue, legal liabilities and other workplace issues. Organizations need effective countermeasures to enforce its appropriate usage policies and minimize its losses & increase productivity. This project addresses some of the issues related to Information System misuse, resulting threats and countermeasures. The shift of corporate computing focus from centralized to decentralized, distributed, network computing coupled with drop in hardware prices has empowered the desktop computers with fast processors, more memory, high capacity disks and peripherals. Significant amount of organizations intellectual property now resides on employees computers. With highly user friendly operating systems such as Microsoft Windows, employees can now easily install software on their office computers from compact disc, listen to music, watch videos, play games, store personal data, execute applications that may be inappropriate for business. The paradigm shift to powerful networked desktops necessitates organizations to enforce policy based controls such as defining organizational standard configurations for these workstations that are restrictive enough to curb risk while non-restrictive enough to support vital business functions. Few years back, web browser was the only tool available to access internet. Today employees can use new breed of applications such as real-time streaming media players, instant messaging clients and peer-to-peer networks over the internet. The use of applications like peer-to-peer can have a very little, if any business justification. Chat, Online Purchase, interactive games, gambling, pornography, surfing non business related sites such as sports, entertainment, web based personal email and even searching another job etc. are major contributors to losses organizations suffer due to misuse of corporate desktops. In addition to being potential productivity drainer, corporate desktops can relay

Page 1

company confidential information through instant messaging or emails rapidly over the Internet exposing organizations to legal liabilities.

1.1 PROBLEM STATEMENT

The constraints of gateway firewalls, antivirus softwares is limited to external intrusion control such as spyware, malware, viruses etc. But, todays computing threats employ sophisticated techniques to bypass perimeter security. Thus, there is a requirement of an application to have philosophical strategic control mechanism of inline security which causes security loopholes. The main problem statement focus of the project work is getting a wholesome inputoutput activities logging information of a PC without the PC user knowing about the existence of such softwares as well as without imparting the overhead to the existence computer system and an integrated universal message reporting system with trusted handheld device.

1.2 AIM OF PROJECT

The project work aims to design and develop a client-server application for inputoutput logging with integration to SMTP and POP3 and further collaboration with GSM modem to have a control mechanism with SMS.

1.3 OBJECTIVE OF PROJECT

The following are the objectives of the project: Establishing communication session between multiple clients with a server by socket programming. Running client application in visible as well as sneakiness mode. Recording the keyboards strokes, mouse click coordinates, URL visited, and capturing screenshots at defined intervals. Having control of enability / disability of client software functionalities. Importing client side logger files to the server machine Getting client side logger files as an email attachment. Having a control mechanism on a client PC with SMS send from handheld devices.

Page 2

1.4 MOTIVATION
The motivation is to achieve a control system by adopting an existing intelligency of a wireless device such as mobile phone to interface forensic software and extending the product life to have complete personal information management assistance, control system, complete PC activity monitoring application. The academic project exposes following technologies. .NET framework and C# programming language Win32 API Socket programming Thread programming Windows Hook Technology AT-Commands and HyperTerminal Programming for SMS Remoting Technology

1.5 EXISTING SYSTEM AND ITS LIMITATIONS

In the various work towards forensic of PC input-output activity as well as use of mobile phone with PC which has been studied while conducting survey of existing systems, it has been found that the usability and extensibility are limited to certain extent either functional view point or because of technical constraint. Following are few such existing systems 1.5.1 Existing System Mobile witch Bluetooth Remote Control is a free of charge program that can be used to control ones computer from distance. The main purpose of the software is to turn mobile phone into a universal PC remote control. MOBILedit! is the solution for user if the user wants to control their cell phone from the PC via Bluetooth, infrared, or cable. is the solution for user if the user wants to control MOBILEedit! is like a remote administration software for the mobile,

Page 3

1.5.2 Limitation Since it uses Bluetooth, although it does function as a remote it has certain range limitations. This application usability is limited to get administrative control from PC to mobile phone rather than getting control of PC from mobile phone. Apart from above two case studies, there are various softwares which do the activity of key logging, controlling PC from mobile phone. But none of the existing application provides a complete framework of inline client-server based PC input-output activities recording mechanism and remote messaging system along with collaboration of mobile phone as a remote control device.

1.6 PROPOSED SYSTEM

The proposed system is a complete framework of a client-server application with personal information management assistance aiming to develop a dynamic computer monitoring software, which is a piece of undetectable software that runs on a computer, and implicitly records computer usage by capturing all I/O activity, including key events, websites visited, documents read, chat conversations, etc and finally provides features of message mechanism by email and two way controlling and communication mechanism with mobile phone. The proposed framework can be classified into two functional components: Client-Server surveillance: This component aims to implement two way clientserver software for key logger, mouse logger, URL logger, snapshot image recorder, file transfer from client to server machine, control mechanism from server to client machine and email messaging mechanism. Personal Information Management Assistance for mobile: This component aims to implement push of SMS to GSM server to control respective connected clients PC as well as to get accessibility of client files to email.

1.7 THEORETICAL OUTLINE

The project includes many challenging as well as complex aspects of programming. As the I/O logging involves various different types of information to be recorded, more or less each type posed a new challenge and a new technique to solve it. For example the thread programming has been used to achieve URL Logging, and the client/server listening functions, as well as socket programming has been implemented to achieve their communication. Page 4

The following new technologies and subjects encountered in the process of development are as follows: .Net platform and C# The .NET Framework is an integral Windows component that supports building and running desktop applications and Web services. It provides a managed execution environment, simplified development and deployment, and support for a wide variety of programming languages. Two key components are the common language runtime (CLR), which manages memory, code execution, and other system services, and the .NET Framework class library, which is a collection of reusable types you can use to develop your applications. Windows Forms and controls With the design and modification of the user interface of Windows Forms applications, there is a need to add, align, and position controls. Controls are objects that are contained within form objects. Each type of control has its own set of properties, methods, and events that make it suitable for a particular purpose. It can manipulate controls in the designer and write code to add controls dynamically at run time. Low level win32 API programming Win32 is the core API of Microsoft Windows CE. If the operating system supports a feature, it must by definition be supported in Win32. For certain kinds of operating system extensions, again, the only choice is Win32. If the user wants something that will be portable to a wide range of Windows CE platforms, such as a device driver, using Win32 makes a lot of sense. Win32 and the .NET Compact Framework are each portable in their own way. Even some display-based devices do not support enough of the required Win32 API to support the .NET Compact Framework. Windows messages The system passes input to a window procedure in the form of messages. Messages are generated by both the system and applications. The system generates a message at each input event. Windows hook technology In the Microsoft Windows operating system, a hook is a mechanism by which a function can intercept events (messages, mouse actions, keystrokes) before they reach an application. The function can act on events and, in some cases, modify or discard

Page 5

them. Functions that receive events are called filter functions and are classified according to the type of event they intercept. Event driven programming Before the advent of Microsoft Windows, many programs had a strictly procedural design. The user ran the program, it did its work while the user waited, and when it was done, the command prompt returned and it could run another program. With Windows, a new programming paradigm became dominant: event-driven programming. As the user interacts with an application, events occur. For example, clicking a command button raises a button's Click event. Sections of code called event handlers react to events. One can think of events as signals from one part of their application to another. It's up to the user as the developer to write code to respond to events. Events with no handler are simply discarded by Windows. Network programming The Microsoft .NET Framework provides a layered, extensible, and managed implementation of Internet services that can be quickly and easily integrated into your applications. The applications can build on pluggable protocols to automatically take advantage of new Internet protocols, or they can use a managed implementation of the Windows socket interface to work with the network on the socket level. Thread Programming Threading enables C# program to perform concurrent processing so one can do more than one operation at a time. For example, one can use threading to monitor input from the user, perform background tasks, and handle simultaneous streams of input. The System Threading namespace provides classes and interfaces that support multithreaded programming and enable to easily perform tasks such as creating and starting new threads, synchronizing multiple threads, suspending threads, and aborting threads. Serial communication in win32 Serial communications in Microsoft Win32 is significantly different from serial communications in 16-bit Microsoft Windows. Those familiar with 16-bit serial communications functions will have to relearn many parts of the system to program serial communications properly. AT-Commands AT commands are instructions used to control a modem. AT is the abbreviation of Attention. Every command line starts with "AT" or "at". That's why modem commands are called AT commands. Page 6

CHAPTER-

LITERATURE SURVEY
A hook is a point in the system message-handling mechanism where an application can install a subroutine to monitor the message traffic in the system and process certain types of messages before they reach the target window procedure.

2.1 SURVEY FOR BASIC CONCEPTS OF HOOKS TECHNOLOGY

Windows hooks can be considered one of the most powerful features of Window. With the Hook, you can trap events that will occur, either in your own process or in other processes. 2.1.1 Windows Hook With the Hook, you can trap events that will occur, either in your own process or in other processes. By "hooking", you tell Windows about a function (filter function, also called hook procedure), that will be called every time an event you're interested in occurs. The system supports many different types of hooks; each type provides access to a different aspect of its message-handling mechanism. For example, an application can use the WH_MOUSE Hook to monitor the message traffic for mouse messages. The system maintains a separate hook chain for each type of hook. A hook chain is a list of pointers to special, application-defined callback functions called hook procedures. When a message occurs that is associated with a particular type of hook, the system passes the message to each hook procedure referenced in the hook chain, one after the other. A fundamental aspect of hooks is their scope. Normally, hooks may have either system or thread scope. A few, however, can only have system scope. When a hook works at the thread level, it can only trap events generated within that thread. For example, a keyboard hook gets invoked only for the keystrokes directed to the thread's input queue. Similarly, a system wide mouse hook gets called whenever the user moves the mouse, regardless of the particular thread that handles the event. A system-scoped hook is called to handle the event for all the currently running threads. 2.1.2 Mechanism to set a windows hook The SetWindowsHookEx function installs an application-defined hook procedure into a hook chain. You would install a hook procedure to monitor the system for certain Page 7

types of events. These events are associated either with a specific thread or with all threads in the same desktop as the calling thread. The UnhookWindowsHookEx function removes a hook procedure installed in a hook chain by the SetWindowsHookEx function. The handle to the hook to be removed. This parameter is a hook handle that is returned by the call to SetWindowsHookEx that installed the hook. At the end of the handle function of the hook, you must call the CallNextHookEx Function. The CallNextHookEx function passes the hook information to the next hook procedure in the current hook chain (if there is none, then the message returns to the system handling). A hook procedure can call this function either before or after processing the hook information. If you dont call this function, you block the message from going on to the system. (for example, this way you can prevent keystrokes from having any effect) LRESULT CallNextHookEx ( HHOOK hhk, int nCode, WPARAM wParam, LPARAM lParam ); Handle to the current hook nCode Specifies the hook code passed to the current hook procedure. The next hook procedure uses this code to determine how to process the hook information. wParam Specifies the wParam value passed to the current hook procedure. The meaning of this parameter depends on the type of hook associated with the current hook chain. lParam Specifies the lParam value passed to the current hook procedure. The meaning of this parameter depends on the type of hook associated with the current hook chain. These 3 functions are the main function of setting a hook by your application. An example of how it is done in C#, as well as example of the handle function and how exactly to use these 3 functions can be seen next.

Page 8

2.1.3 Hooks in .Net, the win32API class The .NET Framework provides no built-in facilities or infrastructure to handle hooks. But, setting up hooks in .NET-centric apps is as easy as calling the underlying API functionsthat is, SetWindowsHookEx to install a hook and UnhookWindowsHookEx to uninstall. To issue calls to Win32 API functions from within .NET applications, you must first import the desired API declarations into some sort of managed class.

2.1.4 Win32 API The Microsoft Windows application programming interface (API) provides services used by all Windows-based applications. You can provide your application with a graphical user interface; access system resources such as memory and devices; display graphics and formatted text; incorporate audio, video, networking, or security. The Windows API can be used in all Windows-based applications. The same functions are generally supported on 32-bit and 64-bit Windows.

2.1.5 Advancement with handhelds Handheld devices are getting more powerful. Todays PDAs often run at 400 MHz, which is as fast as the PCs of just 4 years ago. In fact, the speed of the processors for handhelds, and the size of their memories, is following the well-known Moores law for computers; doubling about every year and a half. Therefore, almost any application that could be imagined running on a PC will find adequate performance on a handheld device. Processors in mobile phones are also getting faster. Phone manufacturers are adding more functions and capabilities to phones, and most mobile phones today are capable of browsing the Internet and running a Java virtual machine. Manufacturers are pushing towards so-called Smart phones for which a variety of applications can be operating systems and user interfaces, though such devices usually have a larger formfactor than conventional mobile phones. Other devices run operating systems specially designed for mobile phones, such as Symbian. Newer phones also include cameras, voice recognition, touch screens, and other technologies.

2.1.6 Advances with communication technology In the original vision for ubiquitous computing (Weiser, 1993), all the devices would be in continuous communication with each other. The original Xerox PARCTabs (Want et al., 1995) used a custom infrared (IR) network to stay connected to the rest of the computers in the environment. However, the first generation of commercial PDAs did Page 9

not have any communication abilities. For example, Sharp organizers often had tiny keyboards and a number of handheld functions, but did not communicate with PCs at all. Meanwhile, laptops were starting to get access to wireless technologies such as 802.11, which first appeared around 1994, but did not become widespread until around 2000. The most popular version is 802.11b, which is now also called Wi-Fi. Initially, getting Wi-Fi required using a PC card (also called PCMCIA) for a laptop. Now, it is possible to get Wi-Fi access on many different kinds of PDAs. A problem with Wi-Fi, however, continues to be its high power usage. Using Wi-Fi communication on a current iPaq 5455 drains the battery in less than an hour. Other radio technologies have addressed the power problem. In addition to research systems (Shih et al., 2002), the BlueTooth radio network technology was designed from the beginning to have low power usage. BlueTooth includes techniques for devices to find each other (also called Device Discovery), which is important for the scenarios we are investigating, but which is not an area we are currently investigating. Unfortunately, the device discovery and set-up time for BlueTooth can take 530 s, which means that BlueTooth is more appropriate for environments where new devices only appear rarely. Another wireless technology is the mobile phone network. The mobile network is increasingly able to carry data, and therefore is relevant to handhelds interfacing with other technology. Currently, in the USA, it is easy to get data rates at 19.2 kHz, with some phone companies offering about 100 kHz with specialized interface cards. In unfortunately, most mobile networks today are optimized for bandwidth, and can take up to 30 s or even longer to transmit a message. If a number has to be dialed first and a connection made, then sending a message can take over a minute. Therefore, todays mobile technology (at least in the USA) does not seem appropriate for the kinds of applications described here. However, we expect that mobile phone data communication with low-latency and zero connect time will be available in the coming years.

2.2 LITERATURE SURVEY OF THE PREVIOUS RESEARCH WORK

i. Work Summary: The aim of the project is to realize a house that can be remotely controlled with web-based facilities, giving the possibility of interacting with several key actuators. Namely the Home Automation (HA) system will accept local commands as well as remote commands to manage different types of situations Page 10

(e.g.: close windows and doors and switch on the heating if the temperature is low, switch on/off appliances, etc). Mobile devices can provide some improvements to the performance of HA systems. Indeed, they allow people to be connected independently of time and space constraints. In this report the problem of implementing a WAP access and related interfaces for HA systems remote control, is addressed. [1] ii. Work-Summary: This research paper provides an overview of the capabilities that we are developing as part of the Pebbles research project for wireless handheld devices such as mobile phones and palm-size computers like Palm Organizers and PocketPCs. Instead of just being used as a phone or organizer, handheld devices can also be used as remote controls for computers and household and office appliances. [2] iii. Work Summary: Virtual reality tools for robot teleoperation via the Internet have been developed. Two systems for WWW-based control of the PUMA and CRS robot manipulators have been developed using these tools. Experiments with these systems on robot control from a long distance (England-Russia, France-Russia) with a low-speed Internet connection revealed that only real-time 3D virtual environments should be used for efficient robot control. TV images produce intrinsic delays and should only be used, from time to time, for checking that the system operates normally, or that some particular event (grasping or dropping the object) has really occurred. System realization with open technologies Java, Java3D and 3-tier client/server architecture provided system portability among the different computer platforms and types of robots. [3] iv. Work Summary: PdaDriver is a Personal Digital Assistant (PDA) system for vehicle teleoperation. It is designed to be easy-to-deploy, to minimize the need for training, and to enable effective remote driving through multiple control modes. This paper presents the motivation for PdaDriver, its current design, and recent outdoor tests with a mobile robot. [4] v. Work Summary: Describes an easy to use handheld remote control device for controlling all the home appliances. The user interface is designed as simple as possible without losing the usability issues. This kind of controlling system is very robust and Page 11

adaptive. It is possible to configure the system in very different environments. And because the most of the calculations can be done in a powerful computer the controlling device itself can be kept very simple and cheap especially when it is manufactured in a large scale. The user interface in this prototype has been kept very simple and easy to use. [5] vi. Work Summary: This paper proposes a Home Network System (HNS) architecture integrated with Wireless Application Protocol and Short Message Service to support the connectivity between home and Internet/Global System for Mobile

Communication (GSM) networks. The HNS architecture includes an HNS gateway and three home network subsystems, i.e., home appliance, security and messaging subsystems. The main objective of the integrated system is to remotely monitor and control the devices in the HNS via laptop computer or a GSM mobile terminal. [6]

Page 12

CHAPTER-

SYSTEM ANALYSIS REQUIREMENT SPECIFICATION

A Software Requirements Specification (SRS) is a complete description of the behavior of the system to be developed. It includes functional requirements, non functional (or supplementary) requirement which imposes constraints on the design or implements performance engineering requirements, quality standards or design constraints.

3.1 OVERALL DESCRIPTION OF SOFTWARE REQUIREMENT

The overall description imposes constraints on the design or implements performance engineering requirements, quality standards or design constraints. 3.1.1 Product perspective: The project should be able to provide a server and client module for the purpose of I/O logging and accessibility i.e. it should be able to record the key, mouse, URL, logging, capture screenshot image and get access of files by file transfer from client machine to server machine, by email and control client machine through SMS server by mobile phone. It should be compatible with the windows operating systems. Recorded key, mouse, URL, logging, capture screenshot image obtained. 3.1.2 Product Functions: The following are the product functions of the project: 1. The client module should be installed at n number of client machines to be monitored. 2. The server module should be installed at the machine which is connected to serial port GSM modem. 3. At the start up execution of the server module, the control should go to the notify icon. 4. All the connected client IP address should be displayed at server GUI and at selection of the client IP, the client could be disconnected, the client surveillance could be enabled or disabled.

Page 13

5. At the server module, all the logger file of the client machine either can be transferred to the hard-disk of the server machine or can be emailed to the intended recipient. 6. Each SMS instructions given by mobile phone should be displayed at the server module and in FIFO, the execution of command to control respective client machine should happen. 7. The client module should be capable of running in visible as well as in invisible mode. 8. At client module, the respective path of logger filed can be set. 9. At client module, interval of snapshot image recording should be set. 3.1.3 User characteristics: A user can set all the priviledge of the client machines, a mobile phone authorization from which the message will be acceptable, authenticated email ID so that the user can access all the I/O of a particular PC at anytime and at anywhere, in terms either from desktop or a control from a mobile phone. 3.1.4 General Constraint: The server capacity is designed to handle eight concurrent clients connectivity. More is the number of users more will be the network traffic and hence the server comes in a down state. The client firewall or protection system as well as single GSM modem usage constraint the application for small scale usability. The application doesnt record any browsing conducted from Mozilla or other browsers, it only supports Microsoft internet explorer. 3.1.5 Assumptions and Dependencies The application should work with concurrent client connectivity even at when the network traffic is high. The server should have a power backup, internet connectivity as well as a proper signal to the GSM modem. The server should have a power backup, internet connectivity as well as a proper signal to the GSM modem The application should be compatible with most of the windows operating systems i.e. previous and latest ones.

3.2 SPECIFIC REQUIREMENTS

Specific Requirement includes the essential required interfaces, constraints, designs, attributes etc. 3.2.1 User Interfaces Page 14

The external users are the authorized administrator of the organization. The administrator can have priviledge to set up client side module and their setting to view the logger files and to control the client PC through administrators mobile phone. 3.2.2 Hardware Interfaces The external hardware interface GSM Modem is connected to server side machine to get control and accessibility to clients machines. Accessing the UMS is the personal computers of the teachers and the students. The client side PCs may be laptops with wireless LAN or general LAN. The server side PC should have serial port to connect GSM modem. 3.2.3 Software Interfaces The Operating Systems can be any version of Windows, which supports TCP/IP protocols and having Dot net framework. 3.2.4 Communication Interfaces The communication interface is a local area network through hub / switch / network routers.

3.3 PERFORMANCE REQUIREMENTS

The PCs used must be at least Pentium 4 machines so that they can give optimum performance of the product. The HyperTerminal should be configured for default setting at server machine.

3.4 DESIGN CONSTRAINTS

The constraints at the designing time are that the needs of the change of IP address of the client machine, email ID, password, and mobile number of the administrator may keep on changing, so the design of the project is made easily updateable. The basic constraint of the project work is that it will only be functional if the PC is turned on. This limitation cannot be mitigated as there is no such system to turn on the PC remotely by activating the power services which definitely requires additional electrical and electronic equipments using certain wireless features. Moreover as the project work requires GSM modem for operation, so serial and parallel port existence in PC or laptop is mandatory which cannot be resolved by any application developer.

3.5 ATTRIBUTES
The following are the attributes of the project:

Page 15

The client should be equipped with Dot net framework and policy based firewall of corporate network.

The client component should not be visible as desktop icon, startup menu, C drive-program files, add/remove programs in control panel as well as windows console, and task manager.

All log files should be easily be updated. It should facilitate administrator with updating his/her email ID and mobile number and getting clients logger file either to servers hard drive or to specified email ID.

The client component should be made visible by a predefined key and providing pre-defined password.

The software is such that as the time goes by the need of the university management, students and teachers may keep on changing thus it is made to change from time to time.

3.6 FUNCTIONAL REQUIREMENT

The project aims at keeping a track of user by monitoring the listed actions Key logger Mouse logger URL logger Snapshot image recorder, File transfer from client to server machine, Control mechanism from server to client machine and Email messaging mechanism

3.7 NON-FUNCTIONAL REQUIREMENT

A Mobile Controlled System using GSM Toolkit for remote access.

Page 16

CHAPTER-

PROPOSED SYSTEM
4.1 ARCHITECTURE OF PROPOSED SYSTEM
4.1.1 Architecture Diagram

Figure 4.1: Event driven architecture for system monitoring.

Page 17

SMTP Configurational Manager Security Engineer User-1 Unauthorized IM

Remote Server

Remoting Techonology

User-2 Management Server POP

Unauthorized E-Mails

Key event tracking

Desktop Snapshots

User-3 Illegal Home Wireless laptops

Microsoft Unified

Track URL

Network Pointing Device Tracking User-4 Browsing insecure websites

Security Engineer

Figure 4.2: An overall architecture

4.1.2 List of Components User Metadata System Metadata Subject Monitor User Process Verb Monitor Object Monitor Alarm Fusion Alarm Verification

Decision Support 4.2 BRIEF INTRODUCTION TO THE ARCHITECTURE

In todays computing environment, unauthorized accesses and misuse of critical data can be catastrophic to personal users, businesses, emergency services, and even national defence and security. To protect computers from the ever-increasing threat of intrusion, I propose an event-driven architecture that provides fine grained intrusion detection and decision support capability. Within this architecture, an incoming event is scrutinized by the Subject-Verb-Object multipoint monitors. Deviations from normal behavior detected Page 18

Communication

by SVO monitors will trigger different alarms, which are sent to subsequent fusion and verification modules to reduce the false positive rate. This architectural pattern may be applied by the design and implementation of applications and systems which transmit events among loosely coupled software components and services. An event-driven system typically consists of event emitters (or agents) and event consumers (or sinks). Sinks have the responsibility of applying a reaction as soon as an event is presented.When a new event comes in, it is intercepted by the IDS that runs in the background and sent into a multistage monitor. The monitor investigates the subject, verb and object by comparing them respectively to the normal behavior stored in the user database. The user metadata database contains information that tells the IDS at what time which processes will normally take what kind of actions on what objects. A new event will trigger an alarm if it involves objects defined in the critical Event Set, and if any element of the SVO triple deviates from normal behaviors. For instance, in our sample setting, all *.doc files in D:\EmployeeFiles directory are protected. Now if a process tries to modify a *.doc file in that directory, an Object alarm will be triggered first. The same event may also trigger Subject Commonality alarm if that process has never been observed before inside the current time window. In this case, the event violates multiple security rules and triggers multiple alarms, which are to be fused and verified subsequently. The SVO based architecture has the following advantages. First, it doesnt require a priori knowledge of intrusions as needed in signature based or system call traces based approaches.Second, intrusion can be detected at the earliest time possible because the IDS does not need to wait until the operation has successfully been executed or damage has been caused. Third, an event is investigated at fine grain level so that more appropriate and effective reactions can be taken according to the nature of the intrusion. Figure 1 shows all the essential components of the proposed architecture. These include the SVO based anomaly detection engine, alarm fusion module, verification module, threat evaluation module and decision support module. These modules address such problems as how to determine if an event is abnormal, how to deal with an alarm, what reactions should be taken when a threat is confirmed. 4.2.1 Anomaly Detection based on user profiling Intrusion detection techniques of IDSs can be categorized into two classes: signaturebased and anomaly-based. Signature-based IDSs compare current events with known attacks and look for similarities, such as comparing a sequence of system calls to known attack patterns. This method has the major limitation of not being able detect novel Page 19

attacks. To overcome this, our proposed architecture uses an anomaly-based detection approach, which models normal behaviors and attempts to identify abnormal activities on the computer. The precondition for such anomaly detection IDS to work is to create a range of normal behaviors. In our system, this normal base is established through an extensive user profiling process whose purpose is to build an in-depth knowledge of how the user uses this computer. The following information is derived: during normal usage of the computer, what processes take what kind of actions on what hardware resources or software objects? 4.2 .2 Alarm Fusion Once an abnormal event happens, it is very likely to trigger multiple alarms at Subject, Verb and Object checkpoints. In order to minimize redundant alarms and condense alarms that stem from the same event into one integral alarm, an alarm fusion module is needed. In the proposed architecture, a multi-level alarm fusion algorithm is used. The first one is a source preprocessing level, which synchronizes the information flow from different sensors to reduce data redundancy for further processes. The second level is alarm normalization, which transforms different alarms into a consistent set of scale. The third level is spatial alarm fusion, which fuses alarms from different anomaly detection monitors. The fourth level is temporal alarm fusion, which analyzes alarms within a certain time window and gives more useful intrusion information. 4.2.3 Alarm Verification The task of this module is to verify the correctness of fused alarms in an effort to reduce false alarms. The verification module works by checking the normality of an event that has triggered an alarm. This includes checking the frequency of similar operations that have been performed before, as well as identifying the security level of the objects that the process is trying to access. 4.2.4 Impact Evaluation A successful attack on a computer usually results in considerable impact on some aspects of its normal operation. Such impact includes disruption of critical services, undermined computation capability, and increased network latency due to excessive outbound traffic and hardware resource exhaustion. To evaluate the impact of an attack, it is necessary to carry out a detailed comparison of system characteristics before and after an alarm is triggered. This is made possible by our real-time system performance Page 20

monitoring tool, which collects system run-time performance data and saves them into a system metadata database.

4.3 DECISION SUPPORT AND AFTERMATH MITIGATION

One of the major contributions of the proposed architecture is its capability to provide insightful information on current attacks and more precise counteraction with regard to the Subject, Verb or the Object. Depending on which elements of the SVO triple pose threats to the protected system, the decision support engine can automatically perform any one or a combination of the following three categories of actions: Ban current user Terminate operation Quarantine objects

Page 21

CHAPTER-

SYSTEM DESIGN
The system design includes the High Level Design and Detail Design of the system. Which leads to the entire design structure of the project?

5.1 HIGH LEVEL DESIGN

The purpose of the design phase is to plan a solution of the problem specified by the requirement document. This phase is the first step in moving from the problem domain to the solution domain. The design of the system is perhaps the most critical factor affecting the quality of the software. Here we build the System Block Diagram that will be helpful to understand the behavior of the system. Here we divide problem into modules. Data flow Diagrams show flow of data between/among modules. This chapter presents the following: Design Considerations: - This section describes many issues, which need to be addressed or resolved before attempting to device a complete design solution. Assumptions and Dependencies: - Describe any assumptions or dependencies regarding the software and its use. General Constraints Development Methods Architectural Strategies System Architecture: - This section describes the DFDs, which are the root part for any design. 5.1.1 Design Considerations In .NET, programs are not compiled into executable files, they are compiled into Microsoft Intermediate Language (MSIL) files, which the CLR then executes. The MSIL (often shortened to IL) files C# produces are identical to the IL files that other .NET languages produce; the platform is language-agnostic. The another design consideration of this project work is that it is purely a framework defined by Microsoft technologies, which has the potential to keep the application in display as well as in the stealth mode. The project work is designed in such a way to be in functional with the offline as well as data transaction in the internet. The design phase of the project was very crucial one as it took maximum time of the development. The development strategy was built in Microsoft platform which is one of Page 22

the most powerful tools to create such types of research work and also a reason for speedy project development in less time. The C#.Net is deployed for the development of the project work. The system of the project is designed to receive the SMS from the

registered cellular device of the registered used only. The control message definition is designed using C#.Net in the PC. So based on the user sends message accordingly, the PC verifies the type of the message and acts accordingly. 5.1.2 Assumptions and Dependencies The general assumption of this particular project work has to be explained with proper understanding of the functional aspect of this research work. The application is assumed to be used by the administrator to keep a vigilant eye over the network as well as activity of the user in the particular PC. Certain situation is being considered for the project to be in working condition: The system is a windows application which is installed only in the users PC. The user has to register their cellular device with the PC that they will be using for controlling it remotely. The user needs to know the configurational setting of Microsoft Outlook Express application for smooth setting alteration if required. Proper network media The server considered should support the service of communication between the user PC and their cellular phone. 5.1.3 General Constraint Powered by the Microsoft Technology, the project is designed with an utmost security and caution to make sure that user never comes to cross-check about the installation process of this application. It should not be displayed either in desktop icon, or in startup menu, or in program files, or in add-remove programs or in console menu. The display option is totally assumed to controlled by the inserting the combination of user defined keys by the administrator. So, to design such features socket programming, windows hook technology and event-driven programming is deployed which may be considered as one of the major general constraint of this project work. 5.1.4 Development Methods The development method used in this software design is the modular/functional development method. In this, the system is broken down into different modules, with a certain amount of dependency among them. The input-output data that flows from onePage 23

module to another will show the dependency. Data flow diagrams have been used in the modular design of the system. Structure charts have been used to show the hierarchy of the function calls in the system. Data Flow Diagram and structure charts are mentioned. The development method used in this software design is the modular/functional development method. In this, the system is broken down into different modules, with a certain amount of dependency among them. The input-output data that flows from onemodule to another will show the dependency. Data flow diagrams have been used in the modular design of the system. Structure charts have been used to show the hierarchy of the function calls in the system. Data Flow Diagram and structure charts are mentioned.

5.2 SYSTEM ARCHITECTURE

The architecture design of this project work is very complex and this is increased at the time of coding process for the development of enabling and disabling features of the application. There are two scenarios in which the applications stops firstly, if in stealth mode, the program stops monitoring as soon as the owner enters the correct password combination (that appears after typing the secret keys combination), If in visible mode, selecting the tray icon and the stop button stops the application. As mentioned earlier, in both cases the setting window appears on screen (and on top). And secondly, if windows restarts or shuts down, in the next start-up the application is disabled. The folder of the log files will be saved on disk and will be hidden from the computer user (password protected/invisible). Further more, access to the folder during system activity (monitoring in progress) will be forbidden (not to cause a conflict with the system). After the monitoring stops access is available (via direct access or the clear-logs button in the interface). The log-statistics will be updated the next time the interface window re-appears (i.e. erasing some logs, wont change the statistics window mentioned). - Only one logs-folder will be at any time on the computer (so that if we start a new session, the option of defining a - new logs folder will ask for deleting the old one if there is such. Maintenance: the folder holding the Log-files should be rather small (the owner should maintain it) so that it won't oversize the disk/partition substantially. Portability: any windows SP2 OS or newer. Performance: The system activity will not degrade performance of the applications running on the machine.

Page 24

We have developed the system using the top-down approach. In this method, the entire system is visualized as a whole. The entire system is broken down into several modules. The modules are further are further divided into sub module in the next level. The architecture of the model is purely software specific and is designed through Microsoft Platform IDE and with specific C#.Net 2005. The development strategy starts with designing the interface of the GUI for the user and options for entry based on User Cellular Number, User E-Mail ID, and locations should be prioritized.

Clients

URL Visited Windows Hook technology Key Events

Security Engineer

Event-Driven Programming Mouse Events

GUI snapshot Captured

GUI recording Desktop Recording Remoting Server Name

Server IP Address

Figure 5.1: Client Server Architecture

Page 25

Figure 5.2: Mobile Communication

SMTP

Configurational Mgr Remote Server

User-1 Unauthorized IM Snapshots Track URL

Deploying Microsoft PIMA

User-2

Unauthorized E-Mails

Security Engineer

Keystroke Tracker Pointing Device Tracker

POP

User-3

Illegal Home Wireless laptops

Network A: For Remote Shut-Down B: writing the contents of RAM to non-volatile storage systems C: E-Mail File manager Security Engineer

Figure 5.3: Overall System Architecture

5.3 DATA FLOW DIAGRAM

Data-flow models are an intuitive way showing how data is processed by a system. At the analysis level, they should be used to model the way in which data is processed in Page 26

the existing system. The notation used in these models represents functional processing, data stores and data movements between functions. Dataflow models are used to show how data flows through a sequence of processing steps. The data is transformed at each step before moving on to the next stage. These processing steps or transformation are program functions where dataflow diagrams are used to document a software design. With a dataflow diagram, users are able to visualize how the system will operate, what the system will accomplish and how the system will be implemented. Old system dataflow diagrams can be drawn up and compared with the new systems dataflow diagrams to draw comparisons to implement a more efficient system. There are several common modeling rules to be followed while creating DFDs are as follows: All processes must have at least one data flow in and one data flow out. All processes should modify the incoming data, producing new forms of outgoing data. Each data store must be involved with at least one data flow. Each external entity must be involved with at least one data flow. A data flow must be attached to at least one process.

PC input output

Main Application

Recorded input / output log in email

Figure 5.4: Level Zero Data Flow Diagram (Client-Server)

SMS Commands

Main Application

Command Execution

Figure 5.5: Level Zero Data Flow Diagram (Mobile Communication)

This level shows the overall context of the system and its operating environment and shows the whole system as just one process. The above figure Fig 4.1 describes the system of client and server and the figure 4.2 describes the personal information management assistance module. Page 27

Client

Server

Fig 5.6 Level one Data Flow Diagram (Client-Server)

This level (level 1) shows client and server processes. The purpose of this level is to show the major high-level processes of the system and their interrelation. This level (level 1) shows mobile communication processes. The purpose of this level is to show the major high-level processes of the system and their interrelation. This level is decomposition of a client process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram. The level 1 and level 2 diagrams can be compared and studied to distinguish. The purpose of this level is to show the major high-level processes of the system and their interrelation. The details are in mentioned figure.

Check_port_Open

SMS Input

GSM Network

Valid Port for Connection

Check_port_Close
Figure 5.7: Level one Data Flow Diagram (Mobile Communication)

Page 28

Key_Combination

path Sneakiness

Dangerous_Key Text_Editor_Application

Timer Configuration

Snapshots

Keyboard Tracking

Path_Set

Client

IP_Address

Remote Server URL

Mouse

Path_Set

Server_Name

Path_Set

Figure 5.8: Level Two Data Flow Diagram (Client-Server)

Path_Info

Client availability status

Path setting for sending file Email_Address

Email

Server

Client termination Mobile_Number SMS Setting Comm_port_Check Surveillance control

Figure 5.9: Level Two Data Flow Diagram (Server)

This level is decomposition of a Server process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram. Page 29

Capture

Shutdown

Standby

Port connected

Read SMS

PC Controlling features

lock

Log-Off

Hibernate

Figure 5.10: Level Two Data Flow Diagram (Mobile Communication)

This level is decomposition of a mobile communication process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram

5.4 CONTEXT DIAGRAM

A Context Diagram in software engineering and systems engineering are diagrams that represent all external entities that may interact with a system. This diagram is the highest level view of a system, similar to Block Diagram, showing a, possibly softwarebased, system as a whole and its inputs and outputs from/to external factors. System Context Diagram is diagrams used in systems design to represent all external entities that may interact with a system. This diagram pictures the system at the center, with no details of its interior structure, surrounding by all its interacting systems, environment and activities. The objective of a system context diagram is to focus attention on external factors and events that should be considered in developing a complete set of system requirements and constrain.

Page 30

From Sender

To Reciepant

E-Mail Settings

Server Name

IP_Address

Set URL Logger Remote Server Track URL Path Settings Set Keylogger Configurational Manager Main Application Keystroke Tracker Choose Application Log_Path

Sneakiness Mode

Start Application Halt Application

Snapshot

Pointing Device Tracker

Time Interval Time Defination

Path

Set Mouse Tracker

Choose Application

Log_Path

Figure 5.11: Contextual Diagram-I

System context diagram are related to Data Flow Diagram, and show the interactions between a system and other actors with which the system is designed to face. System context diagrams can be helpful in understanding the context in which the system will be part of software engineering. Context diagrams are used early in a project to get agreement on the scope under investigation. These diagrams must be read by all project stakeholders and thus should be written in plain language, so the stakeholders can understand items within the document. The contextual diagram of the overall project work is displayed below in Figure 4.11, 4.12.

Page 31

COM Port check

Win32 API

WMI

Executes Controls

Main Application

GSM-Network

Lock PC

Shut Down

Restart

HIbernate

Log Off

Capture/ Send

Short SMS Code

UserMobile

Fig 5.12 Contextual Diagram-II

5.5 DETAILED DESIGN

The introduction of structured programming in the 1960s and 70s brought with it the concept of Structured Flow Charts. In addition to a standard set of symbols, structured flow charts specify conventions for linking the symbols together into a complete flow chart. The structured programming paradigm evolved from the mathematically proven concept that all problems can be solved using only three types of control structures: Sequence Decision (Selection) Iterative (or looping). In software engineering, a class diagram in the Unified Modeling Language (UML), is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes. Class diagram showing generalization between one super-class and two subclasses The Generalization relationship indicates that one of the two related classes (the subtype) Page 32

is considered to be a specialized form of the other (the supertype) and supertype is considered as Generalization of subtype. In practice, this means that any instance of the subtype is also an instance of the supertype. An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so on. The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, a mammal is an animal). The UML graphical representation of a Generalization is a hollow triangle shape on the supertype end of the line (or tree of lines) that connects it to one or more subtypes. The generalization relationship is also known as the inheritance or "is a" relationship. The supertype in the generalization relationship is also known as the "parent", superclass, base class, or base type. The subtype in the generalization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type. Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading. Generalization can only be shown on class diagrams and on Use case diagrams. In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes the behavior that the other model element (the supplier) specifies. A realization is displayed in the diagram editor as a dashed line with an unfilled arrowhead towards the supplier. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface.

Page 33

Program Static Class RootHook Class

GetCurrentProcess GetIEHandle():int PrintCurrentProcess StartURLThread Main(): void

Form Class Container Controll

Win32API Static Class

CallNextHookExe( EnumChildWindows GetClassname GetForeGroundWindow() GetKeyState() GetModuleHandle() GetWindowProcess() GetWindowText GetWindowThreadProcessID SendMessage() SetWindowHook() UnHookWindowsHookExe()

MainHook class
Activate(): void Change_status() Disable():void Dispose(): void MainHook():

mainForm Class Form

CalcInterval check_settings EnableRemoteStealth End_Simulation Form1_Load Form1_VisibleChanged Get_dangerousKeys GetCurrentTimeArray GetHourChosen GetPath Keyspath_Click Start_communication Start_timer Stop_click_event TimeToEnd TimeToStart UDanKey_Checked Utime_Interval_Check

PasswordEnter Class Form

Before_password_closing_event() Dispose(bool disposing): void InitializeComponent(): void PassOK_Click() PasswordEnter()

SendMail Static Class

Send(Strings to)

Networking Class
FileTransfer() ListenerFunc() Networking()

MouseHook Class RootHook

Activate():void CALLBACK_func() Disable():Void Dispose(): Void Init_arr_mouse() MouseHook()

KeyHook Class RootHook

Activate():void CALLBACK_func() Disable():Void Dispose(): Void Init_arr_mouse() KeyHook() Take_picture()

URLHooks Class

MediaHook Class
OnTimeEvent() StartFilming(): Void StopFilming(): Void

Callback_func() GetURL(): void

Fig 5.13 class flow diagram

5.5.1 Project Client Class Diagram Overview Program: The main class of the application is Program. From there, we saved instances of the classes: From1, PasswordEnter and MainHook. From this class we run the main client form and initiate the hook. MainSpyForm: As a form, it derives from the class Form. This is the main form of the application. This class uses the static methods of the classes SendMail and Networking. PasswordEnter: As a form, it derives from the class Form. This is the form from which a password must be entered to exit stealth mode.

Page 34

Send Mail

Capture Screen

System Controls User

boundary

Figure 5.14: Use Case Diagram

MainHook: This is the class of all of the different hooks and monitoring in the application, its members are instances of: MediaHook, KeyHook, MouseHook. URLHook,

Media Hook: This class creates screenshots. URLHook: This class captures visited websites through internet explorer. It uses static methods from the class win32API. KeyHook: A class to capture keystrokes and saving them to a log file. It uses static methods from the class win32API and derives from RootHook. MouseHook: A class to capture mouse clicks and saving their location to a log file. It uses static methods from the class win32API and derives from RootHook.

RootHook: Saves constants and methods used in different hook types.

Page 35

CaptureScreen
[from DesignView ] {namespace=OutlookPCControl}

ShortMessage CaptureScreen::List
[from DesignView ]

OutLookContextMenu
[from DesignView ] {namespace=OutlookPCControl}

+ GetDesktopImage() : Bitmap

:CaptureScreen

ShortMessage
[from DesignView ]

:ShortMessage

{namespace=OutlookPCControl}

Fig 5.15 Object Diagrams

5.6 STRUCTURED CHART

Structured flow chart gives overall strategy for structuring program. It gives details about each module evolve during detail design and coding. The modules and their design for this specific application is as shown in diagram. A structure chart is a top-down modular design tool, constructed of squares representing the different modules in the system, and lines that connect them. The lines represent the connection and or ownership between activities and sub activities as they are uses in organization charts. In structured analysis structure charts are used to specify the high-level design, or architecture, of a computer program. As a design tool, they aid the programmer in dividing and conquering a large software problem, that is, recursively breaking a problem down into parts that are small enough to be understood by a human brain. The process is called top-down design, or functional decomposition. Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is drawn and used as a way for the client and the various software designers to communicate. During the actual building of the program (implementation), the chart is continually referred to as the master-plan.

Page 36

A structure chart is also used to diagram associated elements that comprise a run stream or thread. It is often developed as a hierarchical diagram, but other representations are allowable. The representation must describe the breakdown of the configuration system into subsystems and the lowest manageable level. An accurate and complete structure chart is the key to the determination of the configuration items, and a visual representation of the configuration system and the internal interfaces among its CIs. During the configuration control process, the structure chart is used to identify CIs and their associated artifacts that a proposed change may impact
Major Application

Configurational Manager

Remote Server

Snapshot

Track URL

Keystroke Tracker

Pointing device tracker

Sneakiness Mode

Start Application

Stop Application

E-Mail Settings

Server Name

Communication IP Address

Time Interval

Set URL Logger

Set Keylogger

Set Mouse Tracker

Time Definition

Path settings

Choose Application

Choose Application

Start /Stop Time Settings

Key Combination

Password Entry

From Sender

To Recipient Path

Path

Path

Figure 5.16: Structure Chart-I

A structure chart can be developed starting with the creating of a structure, which places the root of an upside-down tree which forms the structure chart. Next, the programmer focuses on each sub-task individually, and conceptualizes how each can be broken down into even smaller tasks. The next step is to conceptualize the main sub-tasks that must be performed by the program to solve the problem. Eventually, the program is Page 37

broken down to a point where the leaves of the tree represent simple methods that can be coded with just a few program statements .The next step is to conceptualize the main subtasks that must be performed by the program to solve the problem. the programmer focuses on each sub-task individually, and conceptualizes how each can be broken down into even smaller tasks. Details are shown in the mentioned figure.
User Cellphone

Short Message Code

Lock PC

Shut Down

Hibernate

Restart

Log Off

Capture / Send

EMAIL-API

Win32-API

Desktop PIMA Application

Reads

Performs Action accordingly

Figure 5.17: Structure Chart-II

Page 38

CHAPTER-

HARDWARE AND SOFTWARE REQUIREMENTS

6.1 RESOURCE-REQUIREMENTS
It deals with the several resources used in the projected such as Microsoft .Net Framework, Visual studio 2005, c#.Net. 6.1.1 Microsoft .Net Framework The Microsoft .NET Framework is a software framework available with several Microsoft Windows operating systems. It includes a large library of coded solutions to help the programmer and a virtual machine that manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering and is intended to be used by most new applications created for the Windows platform. The framework's Base Class Library provides a large range of features including user interface, data and data access, database connectivity, cryptography, web application development, numeric algorithms and network communications. The class library is used by programmers, who combine it with their own code to produce applications. 6.1.2 Visual Studio 2005 Microsoft Visual Studio is an Integrated Development Environment (IDE) from Microsoft. It can be used to develop console and graphical user interface applications along with Windows Forms applications, web sites, web applications, and web services in both native code together with managed code for all platforms supported by Microsoft Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact Framework and Microsoft Silverlight. Visual Studio includes a code editor supporting IntelliSense as well as code refactoring. The integrated debugger works both as a source-level debugger and a machine-level debugger. Other built-in tools include a forms designer for building GUI applications, web designer, class designer, and database scrhema designer. It accepts plug-ins that enhance the functionality at almost every levelincluding adding support for source control systems (like Subversion and Visual SourceSafe) to adding new toolsets like editors and visual designers for domain-specific languages or toolsets for other aspects of the software development lifecycle (like the Team Foundation Server client: Team Explorer).

Page 39

6.1.3 About C#.Net C# is a multi-paradigm programming language encompassing imperative, functional, generic, object-oriented (class-based), and component-oriented programming disciplines. It was developed by Microsoft within the .NET initiative and later approved as a standard by Ecma (ECMA-334) and ISO (ISO/IEC 23270). C# is one of the programming languages designed for the Common Language Infrastructure. C# is intended to be a simple, modern, general-purpose, object-oriented programming language. Its development team is led by Anders Hejlsberg. The most recent version is C# 3.0, which was released in conjunction with the .NET Framework 3.5 in 2007. The next proposed version, 4.0, is in development. The ECMA standard lists these design goals for C#:

C# language is intended to be a simple, modern, general-purpose, object-oriented programming language.

The language, and implementations thereof, should provide support for software engineering principles such as strong type checking, array bounds checking, detection of attempts to use uninitialized variables, and automatic garbage collection. Software robustness, durability, and programmer productivity.

The language is intended for use in developing software components suitable for deployment in distributed environments.

Source code portability is very important, as is programmer portability, especially for those programmers already familiar with C and C++.

Support for internationalization is very important. C# is intended to be suitable for writing applications for both hosted and embedded systems, ranging from the very large that use sophisticated operating systems, down to the very small having dedicated functions.

Although C# applications are intended to be economical with regard to memory and processing power requirements, the language was not intended to compete directly on performance and size with C or assembly language.

6.2HARDWARE REQUIREMENT SPECIFICATION

i. ii. iii. Intel Pentium III Processor (min), 2 GB RAM, 80 GB HDD,CD-ROM LAN/ Internet Connection to Server Machine TCP/IP network for communication between clients and server

Page 40

6.3 SOFTWARE REQUIREMENT SPECIFICATION:

i) ii) iii) iv) Operating System: Windows NT 4.0/2000/XP with SP2 Programming Tool: Microsoft Visual Studio .Net-2005 Platform: .Net Platform and C#.Net Concepts to be Implemented in coding: a) b) c) d) e) f) g) Event Driven Programming Socket Programming Thread Programming Windows Hook Technology Event Driven Programming Windows Message Low-level win32 API Programming

Page 41

CHAPTER-

IMPLEMENTATION
The implementation phase of any project development is the most important phase as it yields the final solution, which solves the problem at hand. The implementation phase involves the actual materialization of the ideas, which are expressed in the analysis document and developed in the design phase. Implementation should be perfect mapping of the design document in a suitable programming language in order to achieve the necessary final product. Often the product is ruined due to incorrect programming language chosen for implementation or unsuitable method of programming. It is better for the coding phase to be directly linked to the design phase in the sense if the design is in terms of object oriented terms then implementation should be preferably carried out in a object oriented way. The factors concerning the programming language and platform chosen are described in the next couple of sections. The implementation stage in a system project in its own right. It involves Careful planning Investigation of the current system and the constraints on implementation. Training of staff in the newly developed system.

7.1 DESCRIPTION
Implementation of any software is always preceded by important decisions regarding selection of the platform, the language used, etc. these decisions are often influenced by several factors such as real environment in which the system works, the speed that is required, the security concerns, and other implementation specific details. It is better for the coding phase to be directly linked to the design phase in the sense if the design is in terms of object oriented terms. There are three major implementation decisions that have been made before the implementation of this project. They are as follows: Selection of the platform (Operating System). Selection of the programming language for development of the application. Coding guideline to be followed.

Page 42

7.2 SELECTION OF LANGUAGE

For the implementation of our project we need flexible systems implementation language. Compilation should be relatively straightforward compiler, provide low-level access to memory, provide language constructs that map efficiently to machine instructions, and require minimal run-time support. Program should be compiled for a very wide variety of computer platforms and operating systems with minimal change to its source code. For Graphical User Interface programming, language chosen must be simple to uses, secure, architecture neutral and portable.

7.3 CLIENT IMPLEMENTATION TECHNIQUES & CODE

We discuss techniques and coding related to client implmentations. 7.3.1 Key Logger When addressing the description of the implementation, we firstly need to install the low level keyboard hook which will intercept all of the keystrokes. After completing this stage, we shall describe the key logging. 7.3.2 Initializing Keyboard Hook In order to initiate the hook, we need to address 3 methods in user32.dll:

SetWindowsHookEx which sets up the keyboard hook UnhookWindowsHookEx which removes the keyboard hook CallNextHookEx which passes the keystroke information to the next application listening for keyboard events

We created a class responsible for the key logging, all of the actions described from now on are in this class. Now for the hook initialization: public KeyHook() { } public void Activate() After initializing the hook, we address the second parameter, the pointer and the function itself. One can see that the second parameter callback wasn't explained, this is the function delegate. For creating the hook we need to declare a delegate (pointer to function) which receives 3 parameters and returns void, for this is the function expected: Page 43

public delegate IntPtr PtrCALLBACK(int nCode, IntPtr wParam, IntPtr lParam); Whenever a keyboard event occurs, the following parameters will be passed to CALLBACK_func:

nCode: The callback function should return the result of CallNextHookEx if this value is less than zero. Normal keyboard events will return an nCode of 0 or more.

WParam: This value indicates what type of event occurred: key up or key down and whether the key pressed was a system key (left or right-hand Alt keys).

lParam: A structure to store precise information on the intercepted event. In this particular case the keystroke. The type of this parameter is IntPtr, and when dealing with a specific event it needs to be cast to the event's defined type. Information regarding a keystroke can be such as the code of the key which was pressed.

The structure defined for the keyboard is KBDLLHOOKSTRUCT: public struct KBDLLHOOKSTRUCT { } The two public parameters are the only ones used by the callback method. vkCode returns the virtual key code, which can be cast to System.Windows.Form.Keys to obtain the key's name, while flags indicates if this is an extended key (the Windows Start key, for instance) or if the Alt key was pressed at the same time. 7.3.3 The Key Logger After initializing the hook, every keystroke typed by the user is now intercepted and received by the callback, we present the callback function: private IntPtr CALLBACK_func(int nCode, IntPtr wParam,

IntPtr lParam)

Page 44

After those line, another filter is activated, one that checks whether the user chose the "Key Logger" option, and if the current process in which the key was pressed is in the user selected monitored processes list: if (KeyActive == true) { if( arr[0] ==1 || (GetCurrentProcess() == "WINWORD" && arr[1] ==1)|| (GetCurrentProcess() == "EXCEL" && arr[2] ==1)|| (GetCurrentProcess() == "POWERPNT" && arr[3] ==1)|| (GetCurrentProcess() == "notepad" && arr[4] ==1)|| (GetCurrentProcess() == "OUTLOOK" && arr[5] ==1)|| (GetCurrentProcess() == "iexplore" && arr[6] ==1)|| (GetCurrentProcess() == "firefox" && arr[7] ==1)||) }

Now, we activate the last filter, which left out system key such as Alt and Ctrl. the method CallNextHookEx forwards the parameters to the next function in the chain, basically frees the keystroke from the method. After filtering all of the information with lesser relevance, we print the keystrokes to the log file with a path written by the user using the method print_character. We also print the date, process name and window name using the function PrintCurrentProcessName (it's second parameter determines whether to print a blank row or not). 7.3.4 Disabling the Key Logger Whenever the user chooses to stop the keystrokes tracing, the function Dspose is called, moreover, it is also called when the program terminates, as requested from a class that derives from IDisposable: public void Dispose() { if (hookID != IntPtr.Zero) win32API.UnhookWindowsHookEx(hookID); }

Page 45

7.4 MOUSE LOGGER

When addressing the description of the implementation, we firstly need to install the low level mouse hook which will intercept all of the mouse clicks. After completing this stage, we shall describe the key logging. 7.4.1 Initializing Mouse Hook This section is similar to the keyboard hook initialization, there are however 2 main differences:

idHook: This number determines the type of hook to be set up in the function SetWindowsHookEx, in previous section it's value was 13. in our case we change the value to 14 which is the mouse hook's id. To make the code more legible, this has been assigned to the constant WH_MOUSE_LL.

lParam: A structure to store precise information on the intercepted event. In this particular case the keystroke. The type of this parameter is IntPtr, and when dealing with a specific event it needs to be cast to the event's defined type. Our interests lie under POINT which stores the location of the click. The type of this parameter is IntPtr, and when dealing with a specific event it needs to be cast to the event's defined type.

7.4.2 The Mouse Logger After initializing the hook, every mouse click done by the user is now intercepted and received by the callback, we present the callback function: private IntPtr CALLBACK_func(int nCode, IntPtr wParam,

IntPtr lParam) After this line, another filter is activated, one that checks whether the user chose the "Mouse Logger" option, and if the current process in which the mouse was clicked is in the user selected monitored processes list. 7.4.3 Disabling the Mouse Logger Whenever the user chooses to stop the keystrokes tracing, the function Dispose is called, moreover, it is also called when the program terminates, as requested from a class that derives from IDisposable:

Page 46

public void Dispose() { } As already stated earlier, we use the member hookID to terminate the hook, we see again the similarity between the two intercepted events.

7.5 URL HOOK

This feature allows us to record any web site the user has visited. The output is the FileURL file (in the usual html format, including date and time for each visited site). The recording of the sites works the following way: In the handle function of the keyboard hook, if we get that the key that was pressed is Enter, we call the StartURLThread() function. We do the exact same thing in the mouse hook, for each left mouse click (also, if the URLActive Boolean is set to true, meaning the user chose the option of URL recording). , we call the StartURLThread () function to execute the command.

7.6 IMAGE RECORDER

One of the software features is the option to obtain screenshots. In the next sections we'll describe how it is done. 7.6.1 Create a Screenshot Firstly, we save a bitmap in the size of the screen, and then we create a Graphics instance from that image (in order to restrain the size). The last stages are the copying and saving of the new image. The parameter i is saved to create several screenshots. These 5 lines are the entire function OnTimedEvent. One of the screenshots option is to create one every selected number of minutes defined by the user. 7.6.2 Time Intervals One of the screenshots option is to create one every selected number of minutes defined by the user. To achieve that we used time event handling. The first thing to do is creating an instance of the timer: public System.Timers.Timer aTimer;

Page 47

Then we initialize the field Elapsed to a delegate pointing to the screenshots function described in the previous subchapter, and then we choose the time interval to be whatever the user defined in minutes and lastly enabling the time intervals. Note that in case the user doesn't choose this option, the member intervals are set to -1 and the function does nothing: public void StartFilming( ) { }

7.6.3 Dangerous Keystrokes The second option of creating the screenshots is to trigger a screenshot by a dangerous keystroke. Whenever a user selected word is typed, the application creates a screenshot. From that logic it is quite obvious that the code for that option lies in the class that handles the keyboard interception. Thus, inside the callback function of the key hook lays the next piece of code. Thus, whenever the user presses "Space" or "Enter", all of the previous saved keystrokes are compared to the patterns entered by the user and if one of them is similar the screenshot is taken. 7.6.4 Timer This options gives the user an options to set a specific time he wants the application to start recording, and an end-time (or never, if he wants the application not to stop at a pre-defined hour) for the application to stop recording. * This options doesnt work with communicating with a server. The main idea behind implementing this options is that it calls the start function the same function that is called when pushing the Start button (which does the necessary checks, updates flags, retrievs necessary information from the GUI window like current paths, and sets the hooks (their Booleans to true) that were chosen), in the time defined by the user. The class Timer (in System.Timers) sets a new timer istance. The

ElapsedEventHandler is the functions the will be called when the StartTimer.Interval expires (the variable is in miliseconds and simply calculated by the difference left from current time to the target time).

Page 48

7.6.5 Email In any time, the user can ask to send the 3 log files by email, to any address he wants to (both by the server and the client). This option is implemented in the SendMail class. Creating the email message object MailMessage mail = new MailMessage(); Attachment att1; Attachment att2; Attachment att3; NetworkCredential cred = new NetworkCredential("WindowsSpyProject@gmail.com", "WindowsSpy"); mail.To.Add(to); mail.Subject = "Windows Spy Logs"; mail.From = new MailAddress("WindowsSpyProject@gmail.com"); mail.IsBodyHtml = true; The to parameter passed to the function is the target mail. The source mail is constant one, and is always sent from google gmails account WindowsSpyProject@gmail.com. Finally to send the mail SmtpClient smtp = new SmtpClient("smtp.gmail.com"); smtp.UseDefaultCredentials = false; smtp.EnableSsl = true; smtp.Credentials = cred; smtp.Port = 587; smtp.Send(mail);

7.7 STEALTH MODE & PASSWORD

The most important feature of our application is making the application hidden. The application can be hidden by checking the Stealth Checkbox in the main window, and also it is automatically goes hidden once you start a communication with the server. In the first option, the idea is that the user of the spy software approaches the monitored computer afterwards to view the logs, and he can then stop and return to the applications main window by pressing a secret key combination, which brings up a Page 49

password window. If he enters the correct password (which he also defined earlier, this is to prevent an accidental secret key combination pressed by the computer user that is being monitored) the application stops monitoring and the main screen appears again. We implement the secret key combination and the password window request this way: In the KeyHook class, each time a key is pressed, we compare this key to the current place in the secret combination string that is to be compared, and if they match we advance the string pointer (passlen) by 1. If there isnt a match, we set the pointer to the beginning of the string, and start the comparison all over again. If we reached the end of the string then the correct secret key combination was pressed, and we bring to front the Form for password checking. The class than handles it is PasswordEnter that inherits from Form. First of all, we prevent this form from being closed by the user in any way besides hitting the right password cancelling its closing in the form_closing event. Now, if the user clicks the Enter Password button, we compare the text he entered in this window, if there is a match, we make the main application interface visible, disable the hooks (we completely stop the monitoring and allow the user to define new settings for a new monitoring session), and make the password form invisible again. If the password is incorrect we print a message on screen.

7.8 CLIENT SERVER COMMUNICATION IMPLEMENTATION

This section will explain the client server interaction. Explains the logical n relational structure between client and server. 7.8.1 The Client Side The communication with the server is done once the user chooses to connect to one such in a given IP address or name in the "Remoting" tab. When the button is clicked, the form becomes invisible, a different thread is opened to deal with the communication with the server and the control goes to the server. The thread is set to the function ListnerFunc in the class Networking. The function mentioned handles the requests (usually file transfer requests) sent by the server. The implementation is actually a big switch, for each different message sent by the server. StreamReader sr = new StreamReader(Program.s); ... while (NetMessage != "End" ) Page 50

{ NetMessage = sr.ReadLine(); ... switch (NetMessage) { ca case "Disable": case "Enable": case "SendKeyFile": case "SendMouseFile": case "SendURLFile": case "SendPicture": case "SendStatus": } } Each of the requests is handled individually. It is worth mentioning that the client opens the socket through port 80 (http) for security reasons. 7.8.2 The Server Side When first initialize, the server's form is not loaded, the server is merely waiting for a request from a remote client. Once such a request is sent the form is loaded and the control on the client can be handled from the form. It can be seen that a socket is opened and for each button pressed in the form a message is sent through that socket. 7.8.3 File transferring One of the main and most useful features of the server is the options of getting the log files that were created on the client side (our main application). If you choose to if you choose to connect with an ip number, these lines are the relevent ones (instead of the last 2) Program.client = new TcpClient(); Program.client.Connect(ip_text, 80); Program.s = Program.client.GetStream();

Page 51

7.8.4 The protocol of sending a file to the server An important thing to take notice of, that the maximum amount of data that can be transferred on a socket each time is 8192 bytes. Thus, what we do is break the file to packets of 8192 bytes and send each packet (like we sent the string, only now its bytes) separately (and that the remainder of the file. And finally we reconstruct the file on the server side and get the original file. The code is the following: First, the server breaks down the file into pieces of 8192, and sends the size of the file to the server, so he would know how many pieces he should expect: myDataBuffer is the bytes array the dols the file bytes that we want to send. 7.8.5 Execution of PC control commands
Table 7.1: Execution of PC Control commands

SL. NO. 1 2 3 4 5

COMMAND Lock#IP Address of the PC Standby#IP Address of the PC Shutdown#IP Address of the PC Hybernate#IP Address of the PC SendMail#IP Address of the PC

REMARK which you want to lock which you want to make Standby which you want to Shutdown which you want to Hibernate From you want to Get Loggers File Emailed.

SendFile#IP Address of the PC

from which you want to Get File as an Email Attachment

Capture#IP Address of the PC

from which you want current Screen Shots To Be Captured and send as an Email Attachment

Page 52

CHAPTER-

TESTING
Testing is running the program (or product) under various circumstances and conditions to find errors and bugs in it. This is important as releasing a faulty product will not only cause serious problems to the end user, it will also harm the companys reputation. There are various kind of Testing conditions and which one to use depends on type of product. Types of Testing in Software Engineering Types of Testing in Software Engineering As per Test Target, there is Unit Testing, Interface Testing and Integration Testing.

8.1 UNIT TESTING

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method, which may belong to a base/super class, abstract class or derived/child class.
Table 8.1: Notify Icon status

Sl # Test Case : Name of Test: -

UTC-1 Notify Icon status

Item being tested: - Notify Icon Instance Sample Input: Expected output: Actual output: Remarks: Icon Notify Icon should appear on System Tray Notify Icon is shown on System Tray Pass
Table 8.2: Show Main Form from Notify Icon

Sl # Test Case : Name of Test: Item being tested:Sample Input: Expected output: Actual output: Remarks: -

UTC-2 Show Main Form from Notify Icon Context Menu item Click on Show Main Form CMI Main Form should be loaded Main Form is Loaded Pass Page 53

Table 8.3: Text Box Displaying IP Address

l # Test Case : Name of Test: -

UTC-3 Text Box Displaying IP Address

Item being tested: - Text Box Sample Input: Expected output: Actual output: Remarks: Client IP Address Display of IP Addresses of Connected Client Displaying IP Addresses of Connected Client Pass

Table 8.4: Checking Client Status without selecting client

Sl # Test Case : Name of Test: -

UTC-4 Checking Client Status without Selecting client

Item being tested: - Click Event of Get Status Sample Input: Expected output: Actual output: Remarks: Client IP Address If No Client is selected Alert Message Display To Select Client Alert Message Box Pass

8.2 INTEGRATION TESTING

Integration testing (sometimes called Integration and Testing, abbreviated "I&T") is the phase in software testing in which individual software modules are combined and tested as a group.
Table 8.5: Checking Client Status by selecting client

Sl # Test Case : Name of Test: Item being tested: Sample Input: Expected output: -

ITC-1 Checking Client Status by Selecting client Get Status Button, List Box , Label Client IP Address and Click Event of Get Status and Input Operation event at Client Machine Label Display PC is in use / PC not in use Page 54

Actual output: Remarks: -

PC is in use / PC not in use Pass

It occurs after unit testing and before system testing. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.
Table 8.6: Enabling Client Surveillance

Sl # Test Case : Name of Test: -

ITC-2 Enabling Client Surveillance

Item being tested: - Enable Button and File logs at client Sample Input: Expected output: Actual output: Remarks: Key Logging, Mouse Logging, Screen Shots, URL Logging Logging files for Key, Mouse, Screen Shots, URL Log Files for Key, Mouse, Screen Shots, URL Pass

Table 8.7: Get Clients Status

Sl # Test Case : Name of Test: Item being tested: -

ITC-3 Get Clients Status Here we get Clients Status Whether Client is Active or not Client Should be running. Send message status to Client Machine Display Message Busy or Ideal Same as Expected Successful

Sample Input: Expected output: Actual output: Remarks: -

Page 55

8.3 SYSTEM TESTING

System testing of software or hardware is testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic.
Table 8.8: File Transfer to Server

Sl # Test Case : Name of Test: -

STC-1 File Transfer to Server

Item being tested: - Test the icon Sample Input: Expected output: Actual output: Remarks: Icon shown Exit the icon Set the icon in desktop Pass

Table 8.9: Testing Key logger file transfer

Sl # Test Case : Name of Test: Item being tested: Sample Input: Expected output: Actual output: Remarks: -

STC-2 Testing Key logger file transfer Here server requests key logger file by sending Command SendKeyFile Create key file by typing some text in any editor Key log File gets Transferred Same as Expected Success

Table 8.10: Testing Images transfer

Sl # Test Case : Name of Test: Item being tested: Sample Input: Expected output: -

STC-3 Testing Images transfer Here server requests Images by Command SendPicture Leave Computer for some duration Images Gets Transferred Page 56 sending

Actual output: Remarks: -

Same as Expected Success

Table 8.11: Testing URL log files transfer

Sl # Test Case : Name of Test: Item being tested: Sample Input: Expected output: Actual output: Remarks: -

STC-4 Testing url log files transfer Here server requests url logger file by sending Command SendURLFile url log File Should Exist in Client Machine Browse some sites Same as Expected. URL log File gets Transferred Success

As a rule, system testing takes, as its input, all of the "integrated" software components that have successfully passed integration testing and also the software system itself integrated with any applicable hardware system(s). System testing is a more limiting type of testing; it seeks to detect defects both within the "inter-assemblages" and also within the system as a whole.
Table 8.12: Check for proper termination of clients from server

Sl # Test Case : Name of Test: -

STC-5 Check for proper termination of clients from server Listbox and end button of server and socket of client Select the client IP address in listbox of server, and then select end button to terminate it The client IP address is successfully removed from the listbox of the server Same as above Successful

Item being tested: -

Sample Input: -

Expected output: Actual output: Remarks: -

Page 57

Table 8.13: Check for visual display

Sl # Test Case : Name of Test: -

STC-6 Check for visual display of log files of client machine from server Operational check proper visualization of real-time log report transmission from client machine Select snaps / key / mouse /URL log files button in server machine All the HTML generated log reports are instantly

Item being tested: -

Sample Input: -

Expected output: -

transferred to the predefined folder in server machine.

Actual output: Remarks: -

Same as expected Successful

Page 58

CHAPTER-

RESULTS AND SNAPSHOTS

9.1 CLIENT SIDE
As we run the Client Side the form will get open with the Configuration window as shown in Figure 7.1.

Figure 9.1: Configuration window

We need to click on the client button to get the Server Settings in the client side form.

Figure9.2: Server setting window

The next module will be capture screen-this settings help in capturing the images and snap-shots n store it in client side in hidden form. Page 59

Figure 9.3: Screen capture window

To get the URL we will click on track URL and save the path where we want to store our information.

Figure 9.4: Track URL window

This gives the key strokes related information.

Page 60

Figure 9.5: Keystroke Tracker window

The pointing device trackers keep list of co-ordinates where ever it will be clicked by the user on the monitor.

Figure 9.6: Pointing Device Tracker

Use of Sneakiness mode with hot key and password setting, this provides the administrator a particular password with the help of which it will go in the back ground and will be hidden in client(users) eyes.

Page 61

Figure 9.7: Use of Sneakiness mode with hot key and password setting

Password entry form after pressing hotkey, it is the only way through which administrator can get back to its client side form.

Figure 9.8: Password entry form after pressing hotkey

The Key entry in notepad.

Figure 9.9: The Key entry in notepad

Creation of File for key Logging in respective defined folder.

Page 62

Figure 9.10 : Creation of File for key Logging in respective defined folder

Recorded key board entry in HTML file, the detail will get stored in the defined folder.

Figure 9.11: Recorded key board entry in HTML file

Creation of File for key Logging in respective folder and recorded mouse click.

Page 63

Figure 9.12: Creation of File for key Logging in respective folder & Recorded mouse click entry in HTML file

Recorded Screen shot images in respective defined folder.

Figure 9.13: Recorded Screen shot images in respective defined folder

Captured Screen Image opened in image viewer, it gives the snap-shots of the window screen.

Page 64

Figure 9.14: Captured Screen Image opened in image viewer

We do get the content of email of file requested in defined email ID, it includes FileKey, FileMouse, FileURL.

Figure 9.15: content of email of file requested in defined email ID: myacademicproject2010@gmail.com

Page 65

9.2 SERVER SIDE SCREEN

Ones we start running the server side an icon will appear at the taskbar menu showing Open and Exit Icon.

Figure 9.16: Main Server Icon on Taskbar

Server Start notification Icon in system tray, it comes when we click on the open option after right click on the icon coming on the task bar.

Figure 9.17: Main Server Screen showing all the options for user

Page 66

 Maximum 8-clients can be connected to the single server with their respective IP address and administrator can check the status of the client side by clicking on the IP address of the respective client.

Figure 9.18: Concurrent Client connection IP address display

Figure 9.19 Getting Selected Client status

The display of log files (HTML and image files) of the selected client in defined folder.

Page 67

Figure 9.20 Display of the log files (both HTML and image files) of selected client in defined folder

With the help of Enable and Disable option we can maintain the connection between client-server, and get or disable to fetch the entire information of the client side to the server.

Figure 9.21 Options for disable and enabling of surveillance of clients machine from servers machine

Page 68

Figure 9.22: Client PC is Lock after execution of command

Page 69

CHAPTER-

10

PROJECT MANAGEMENT
10.1 PROCESS MODEL USED: PROTOTYPE MODEL
The Prototyping Model is a systems development method (SDM) in which a prototype (an early approximation of a final system or product) is built, tested, and then reworked as necessary until an acceptable prototype is finally achieved from which the complete system or product can now be developed. This model works best in scenarios where not all of the project requirements are known in detail ahead of time. It is an iterative, trial-and-error process that takes place between the developers and the users. There are several steps in the Prototyping Model: The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system. A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product. The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users. The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed. The second prototype is evaluated in the same manner as was the first prototype. The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired. The final system is constructed, based on the final prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

Page 70

10.2 ROLES & RESPONSIBILITIES

Table 10.1 Role & Responsibility of Team Members

Govind Raj Shivam Raj

Project Manager, Analyst and Testing Technical Head, Designer and Coding

10.3 PROJECT SCHEDULE

Table 10.2 Timeline Chart

Week 1-3 4-6 6-8 9-11 12-14 15-18 19-22 23-25 Requirement Gathering Design Analysis Architecture Analysis Analysis Diagrams Documentation Coding Testing Implementation

Work Done

Page 71

CHAPTER-

11

CONCLUSION
One of the main security threats is the ability of malicious software to steal important or confidential information. The project work highlights about the noble intentions of the security manager of any organization to keep an eye on the activities of the employee over the network. This act results in very lethal consequences, as the employee too doesnt understand, that by unauthorized access on certain websites containing malicious code, or using Instant Messaging Service, or access the wireless range by their home computers strikes a great deal of security violation. Instead of just being used as a phone or organizer, handheld devices can also be used as remote controls for computers and household and office appliances. Remote Control turns your mobile phone into a remote control that can control various applications on your PC. The software does have a few limitations and requirements though. Both the PC and mobile phone have to support the network which is being used to send and receive the data. The user installs a server on the PC and a client on the mobile phone. Both applications have been programmed in Microsoft C#.Net.

Page 72

CHAPTER-

12

FUTURE ENHANCEMENT
The project work which is carried out has got certain advantage, but this research and development work is carried out in a very short range of time. If the time permits, there can be lot of many modifications in this research work. For an example, when the application traces various information, it is sent to email ID of the administrator. It could be made into the wireless device also. So that the administrator does not have to be dependent on accessing his email Account from the cyber PC or home desktop. This is one the most important issue which should be covered in the development and research work in the development stage of the project. But this work can be pulled in the near future with a working experience of wireless Toolkit. To make the project feel as realtime, if the interfacing is done with the assistance of GSM, than it could be more effective as the messaging of the log file goes instantly to the trusted hand-held device. But still it could call of implementation of AT-Commands and communication APIs to create such work, which may take more 6-7 months. The project work has got certain limitation due to slackness in mobile service provider. The project work has been developed in C#.Net due to its dependency in Win32APIs as well as Microsoft PIMA. The future modification of this work will include the GUI design on the mobile application, which may enable the user to see the desktop itself on their phone. It is almost equivalent to having the GUI of the application in their cell-phone using GPRS. This will make the project more mobile and easy for any user to check and operate from their cell phone only in a run mode.

Page 73

REFERENCES
[1]. Remote Control of Home Automation Systems with Mobile Devices - Authors: Luca Tarrini, Rolando Bianchi Bandinelli, Vittorio Miori, and Graziano Bertini Publication: IEEE 2002. [2]. Using handhelds for wireless remote control of PCs and appliances - Author: Brad A. Myers, Publication: Human Computer Interaction Institute, School of Computer Science, Carnegie Mellon University, Pittsburgh, PA 15213-3891, USA Received 16 January 2004. [3]. Virtual Reality Tools for Internet Robotics - Author: Igor R. Belousov, Ryad Chellali, Gordon J. Clapworthy, Publication: Proceedings of the 2001 IEEE, International Conference on Robotics & Automation Seoul, Korea May 21-26, 2001. [4]. PdaDriver: A Handheld System for Remote Driving - Author: Terrence Fong Charles Thorpe Betty Glass, Publication: IEEE International Conference on Advanced Robotics 2003. [5]. Context Aware User Interface System for Smart Home Control - Author: Markus Ritala, Tomi Tieranta and Jukka Vanhala, Publication: HOIT 2003 Conference, Irvine, California. [6]. System integration of WAP and SMS for home network system - Author: ChiHsiang Wu and Rong-Hong, Publication: Department of Computer and Information Science, National Chiao Tung University, 1001 Ta Hsueh Rd., Hsinchu 30050, Taiwan Received 12 October 2001. [7]. Xun Wang, Wei Yu, Xinwen Fu, Dong Xuan and Wei Zhao, iLOC: An invisible LOCalization Attack to Internet Threat Monitoring Systems, for publication in the IEEE INFOCOM 2008 proceedings. [8]. Jianfeng Peng, Chuan Feng, Haiyan Qiao, Jerzy Rozenblit, An Event-driven Architecture for Fine Grained Intrusion Detection and Attack Aftermath Mitigation, Proceedings of the 14th Annual IEEE International Conference and Workshops on the Engineering of Computer-Based Systems (ECBS'07), IEEE 2007. [9]. Mary L. Denz, A Benchmark Evaluation of Network Intrusion Detection System, IEEE 2001.

Page 74