final chapters

CHAPTER-1

INTRODUCTION

In today‘s world, use of information systems has become mandatory for businesses to

perform the day to day functions efficiently. Use of Desktop PC‘s, 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 organization‘s intellectual property now resides on employee‘s

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

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 software‘s is limited to external

intrusion control such as spyware, malware, viruses etc. But, today‘s 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 input-

output 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 input-

output 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.

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 one‘s 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,

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 client-

server 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

client‘s 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.

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

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.

CHAPTER-2

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

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 don‘t 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.

http://msdn2.microsoft.com/en-us/library/ms644990(VS.85).aspx

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

functions—that 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. Today‘s 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 Moore‘s 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 form-

factor 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

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 5–30 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, today‘s

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

(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

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]

CHAPTER-3

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.

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 doesn‘t 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

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 administrator‘s 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:

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 client‘s logger file either to server‘s 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.

CHAPTER-4

PROPOSED SYSTEM

4.1 ARCHITECTURE OF PROPOSED SYSTEM

4.1.1 Architecture Diagram

Figure 4.1: Event driven architecture for system monitoring.

Re

mo

tin

g T

ech

on

olo

gy

Network

SMTP

POP

User-1

User-2

Unauthorized IM

Unauthorized E-Mails

User-3

Illegal Home Wireless laptops

Security Engineer

Security Engineer

User-4Browsing insecure

websites

Management Server

Configurational Manager

Remote Server

Desktop Snapshots

Track URL

Key event tracking

Pointing Device Tracking

Mic

roso

ft U

nifie

d

Co

mm

un

ica

tio

n

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 today‘s 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

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 doesn‘t 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: signature-

based 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

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

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

CHAPTER-5

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

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 user‘s 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 one-

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 one-

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.

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,

won‘t 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 over-

size 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.

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.

Event-Driven

Programming

Clients URL

Visited

Key

Events

Mouse

Events

GUI recording

Remoting

GUI

snapshot

Captured

Desktop

Recording

Server Name

Server IP Address

Windows Hook

technology

Security Engineer

Figure 5.1: Client Server Architecture

Figure 5.2: Mobile Communication

Configurational Mgr

Remote Server

Snapshots

Track URL

Keystroke Tracker

Pointing Device

Tracker

De

plo

yin

g M

icro

so

ft

PIM

A

A: For Remote Shut-Down

B: writing the contents of RAM to non-volatile

storage systems

C: E-Mail File manager

Network

SMTP

POP

User-1

User-2

Unauthorized IM

Unauthorized E-Mails

User-3Illegal Home Wireless

laptops

Security Engineer

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

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.

Main

Application

PC input

output

Recorded

input / output

log in email

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

Main

Application

SMS

Commands

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.

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.

SMS Input GSM Network Valid Port for

Connection

Check_port_Open

Check_port_Close

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

Client

Keyboard

Tracking

Snapshots

Configuration

Mouse

URL

Remote

Server

Timer

Sneakiness

Key_Combination

path Dangerous_Key

Text_Editor_Application

Path_Set

Path_Set

Path_Set

IP_Address

Server_Name

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

Server

Client

availability

status

Path setting

for sending

file

Email

Client

termination

Surveillance

control

SMS Setting

Email_Address

Path_Info

Mobile_Number

Comm_port_Check

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.

Port connected Read SMSPC Controlling

features

Capture Shutdown

Standby

lock

HibernateLog-Off

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 software-

based, 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.

Configurational

Manager

Remote Server

Snapshot

Track URL

Keystroke

Tracker

Pointing Device

Tracker

Main

Application

E-Mail

Settings

Server

NameIP_Address

Sneakiness

Mode

Start

Application

Halt

Application

From

Sender

To

Reciepant

Time

Interval

Time

Defination

Path

Set URL

Logger

Path

Settings

Set

Keylogger

Choose

Application

Log_Path

Set Mouse

Tracker

Choose

ApplicationLog_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.

WMI

Win32 API

Main

Application

Lock PC Shut Down Restart

HIbernate Log OffCapture/

Send

Short SMS Code

COM Port

check

Executes

Controls

GSM-Network

User-

Mobile

Fig 5.12 Contextual Diagram-II

5.5 DETAILED DESIGN

The introduction of structured programming in the 1960‘s and 70‘s 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)

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.

RootHook

Class

GetCurrentProcess

GetIEHandle():int

PrintCurrentProcess

StartURLThread

Win32API

Static Class

CallNextHookExe(

EnumChildWindows

GetClassname

GetForeGroundWindow()

GetKeyState()

GetModuleHandle()

GetWindowProcess()

GetWindowText

GetWindowThreadProcessID

SendMessage()

SetWindowHook()

UnHookWindowsHookExe()

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

Callback_func()

GetURL(): void

MediaHook

Class

OnTimeEvent()

StartFilming(): Void

StopFilming(): Void

MainHook

class

Activate(): void

Change_status()

Disable():void

Dispose(): void

MainHook():

Program

Static Class

Main(): void

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()

Form

Class àContainer Controll

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.

System Controls

Capture Screen

boundary

Send Mail

User

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, URLHook,

KeyHook, MouseHook.

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.

:ShortMessage

ShortMessage

[from DesignView ]

{namespace=OutlookPCControl}

OutLookContextMenu

[from DesignView ]


CaptureScreen

[from DesignView ]


+ GetDesktopImage() : Bitmap

ShortMessage

CaptureScreen::List

[from DesignView ]

:CaptureScreen

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.

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

ManagerRemote Server Snapshot Track URL

Keystroke

Tracker

Pointing device

tracker

Sneakiness

ModeStart

ApplicationStop

Application

Start /Stop

Time SettingsKey

Combination

Password

Entry

E-Mail Settings

From Sender To Recipient

Server NameCommunication

IP Address Time Interval

Time Definition

Path

Set URL

Logger

Path settings

Set Keylogger

Choose

Application

Path

Set Mouse

Tracker

Choose

Application

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

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 sub-

tasks 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.

Lock PC Shut Down Hibernate Restart Log OffCapture /

Send

Short

Message

Code

User

Cellphone

EMAIL-API Win32-API

Performs

Action

accordingly

Desktop PIMA

Application

Reads

Figure 5.17: Structure Chart-II

CHAPTER-6

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 level—including 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).

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.2 HARDWARE REQUIREMENT SPECIFICATION

i. Intel Pentium III Processor (min), 2 GB RAM, 80 GB HDD,CD-ROM

ii. LAN/ Internet Connection to Server Machine

iii. TCP/IP network for communication between clients and server

6.3 SOFTWARE REQUIREMENT SPECIFICATION:

i) Operating System: Windows NT 4.0/2000/XP with SP2

ii) Programming Tool: Microsoft Visual Studio .Net-2005

iii) Platform: .Net Platform and C#.Net

iv) Concepts to be Implemented in coding:

a) Event Driven Programming

b) Socket Programming

c) Thread Programming

d) Windows Hook Technology

e) Event Driven Programming

f) Windows Message

g) Low-level win32 API Programming

CHAPTER-7

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.

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 implémentations.

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:

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)

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);

}

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:

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;

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 doesn‘t 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).

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("[email protected]",

"WindowsSpy");

mail.To.Add(to);

mail.Subject = "Windows Spy Logs";

mail.From = new MailAddress("[email protected]");

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 gmail‘s account – [email protected].

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

application‘s main window by pressing a secret key combination, which brings up a

mailto:[email protected]

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 isn‘t 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 it‘s 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" )

{

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();

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 it‘s

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. COMMAND REMARK

1 Lock#IP Address of the PC which you want to lock

2 Standby#IP Address of the PC which you want to make Standby

3 Shutdown#IP Address of the PC which you want to Shutdown

4 Hybernate#IP Address of the PC which you want to Hibernate

5 SendMail#IP Address of the PC From you want to Get Loggers File

Emailed.

6 SendFile#IP Address of the PC from which you want to Get File as

an Email Attachment

7 Capture#IP Address of the PC from which you want current Screen

Shots To Be Captured and send as an

Email Attachment

CHAPTER-8

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 company‘s

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 : - UTC-1

Name of Test: - Notify Icon status

Item being tested: - Notify Icon Instance

Sample Input: - Icon

Expected output: - Notify Icon should appear on System Tray

Actual output: - Notify Icon is shown on System Tray

Remarks: - Pass

Table 8.2: Show Main Form from Notify Icon


Name of Test: - Show Main Form from Notify Icon

Item being tested:- Context Menu item

Sample Input: - Click on Show Main Form CMI

Expected output: - Main Form should be loaded

Actual output: - Main Form is Loaded

Remarks: - Pass

Table 8.3: Text Box Displaying IP Address

l # Test Case : - UTC-3

Name of Test: - Text Box Displaying IP Address

Item being tested: - Text Box

Sample Input: - Client IP Address

Expected output: - Display of IP Addresses of Connected Client

Actual output: - Displaying IP Addresses of Connected Client

Remarks: - Pass

Table 8.4: Checking Client Status without selecting client

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 : - ITC-1

Name of Test: - Checking Client Status by Selecting client

Item being tested: - Get Status Button, List Box , Label

Sample Input: - Client IP Address and Click Event of Get Status

and Input Operation event at Client Machine

Expected output: - Label Display ―PC is in use / PC not in use‖


Name of Test: - Checking Client Status without Selecting client

Item being tested: - Click Event of Get Status

Sample Input: - Client IP Address

Expected output: - If No Client is selected Alert Message Display

―To Select Client‖

Actual output: - Alert Message Box

Remarks: - Pass

Actual output: - PC is in use / PC not in use

Remarks: - 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


Name of Test: - Enabling Client Surveillance

Item being tested: - Enable Button and File logs at client

Sample Input: - Key Logging, Mouse Logging, Screen Shots, URL

Logging

Expected output: - Logging files for Key, Mouse, Screen Shots, URL

Actual output: - Log Files for Key, Mouse, Screen Shots, URL

Remarks: - Pass

Table 8.7: Get Client’s Status


Name of Test: - Get Client‘s Status

Item being tested: - Here we get Clients Status Whether Client is

Active or not

Sample Input: - Client Should be running. Send message status to

Client Machine

Expected output: - Display Message Busy or Ideal

Actual output: - Same as Expected

Remarks: - Successful

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 : - STC-1

Name of Test: - File Transfer to Server

Item being tested: - Test the icon

Sample Input: - Icon shown

Expected output: - Exit the icon

Actual output: - Set the icon in desktop

Remarks: - Pass

Table 8.9: Testing Key logger file transfer


Name of Test: - Testing Key logger file transfer

Item being tested: - Here server requests key logger file by sending

Command SendKeyFile

Sample Input: - Create key file by typing some text in any editor

Expected output: - Key log File gets Transferred


Remarks: - Success

Table 8.10: Testing Images transfer


Name of Test: - Testing Images transfer

Item being tested: - Here server requests Images by sending

Command SendPicture

Sample Input: - Leave Computer for some duration

Expected output: - Images Gets Transferred


Remarks: - Success

Table 8.11: Testing URL log files transfer


Name of Test: - Testing url log files transfer

Item being tested: - Here server requests url logger file by sending

Command SendURLFile

Sample Input: - url log File Should Exist in Client Machine

Expected output: - Browse some sites

Actual output: - Same as Expected. URL log File gets Transferred

Remarks: - 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


Name of Test: - Check for proper termination of clients from

server

Item being tested: - Listbox and end button of server and socket of

client

Sample Input: - Select the client IP address in listbox of server, and

then select ―end‖ button to terminate it

Expected output: - The client IP address is successfully removed from

the listbox of the server

Actual output: - Same as above


Table 8.13: Check for visual display


Name of Test: - Check for visual display of log files of client

machine from server

Item being tested: - Operational check proper visualization of real-time

log report transmission from client machine

Sample Input: - Select snaps / key / mouse /URL log files button in

server machine

Expected output: -

All the HTML generated log reports are instantly

transferred to the predefined folder in server

machine.

Actual output: - Same as expected


CHAPTER-9

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.

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.

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.

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.

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.

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.

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:

“[email protected]”

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

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.

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 client’s machine from server’s

machine

Figure 9.22: Client PC is Lock after execution of command

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.

10.2 ROLES & RESPONSIBILITIES

Table 10.1 Role & Responsibility of Team Members

Govind Raj Project Manager, Analyst and Testing

Shivam Raj Technical Head, Designer and Coding

10.3 PROJECT SCHEDULE

Table 10.2 Timeline Chart

Week Work Done

1-3 Requirement Gathering

4-6 Design Analysis

6-8 Architecture Analysis

9-11 Analysis Diagrams

12-14 Documentation

15-18 Coding

19-22 Testing

23-25 Implementation

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

doesn‘t 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.

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 real-

time, 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.

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: Chi-

Hsiang 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.

final chapters

Documents