Final Chapters
-
Upload
vaibhavikantharia -
Category
Documents
-
view
146 -
download
2
Transcript of Final Chapters
Page 1
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
Page 2
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.
Page 3
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,
Page 4
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.
Page 5
The following new technologies and subjects encountered in the process of
development are as follows:
.Net platform and C#
The .NET Framework is an integral Windows component that supports building
and running desktop applications and Web services. It provides a managed execution
environment, simplified development and deployment, and support for a wide variety
of programming languages. Two key components are the common language runtime
(CLR), which manages memory, code execution, and other system services, and the
.NET Framework class library, which is a collection of reusable types you can use to
develop your applications.
Windows Forms and controls
With the design and modification of the user interface of Windows Forms
applications, there is a need to add, align, and position controls. Controls are objects
that are contained within form objects. Each type of control has its own set of
properties, methods, and events that make it suitable for a particular purpose. It can
manipulate controls in the designer and write code to add controls dynamically at run
time.
Low level win32 API programming
Win32 is the core API of Microsoft Windows CE. If the operating system
supports a feature, it must by definition be supported in Win32. For certain kinds of
operating system extensions, again, the only choice is Win32. If the user wants
something that will be portable to a wide range of Windows CE platforms, such as a
device driver, using Win32 makes a lot of sense. Win32 and the .NET Compact
Framework are each portable in their own way. Even some display-based devices do
not support enough of the required Win32 API to support the .NET Compact
Framework.
Windows messages
The system passes input to a window procedure in the form of messages.
Messages are generated by both the system and applications. The system generates a
message at each input event.
Windows hook technology
In the Microsoft Windows operating system, a hook is a mechanism by which a
function can intercept events (messages, mouse actions, keystrokes) before they reach
an application. The function can act on events and, in some cases, modify or discard
Page 6
them. Functions that receive events are called filter functions and are classified
according to the type of event they intercept.
Event driven programming
Before the advent of Microsoft Windows, many programs had a strictly
procedural design. The user ran the program, it did its work while the user waited, and
when it was done, the command prompt returned and it could run another program.
With Windows, a new programming paradigm became dominant: event-driven
programming. As the user interacts with an application, events occur. For example,
clicking a command button raises a button's Click event. Sections of code called event
handlers react to events. One can think of events as signals from one part of their
application to another. It's up to the user as the developer to write code to respond to
events. Events with no handler are simply discarded by Windows.
Network programming
The Microsoft .NET Framework provides a layered, extensible, and managed
implementation of Internet services that can be quickly and easily integrated into your
applications. The applications can build on pluggable protocols to automatically take
advantage of new Internet protocols, or they can use a managed implementation of the
Windows socket interface to work with the network on the socket level.
Thread Programming
Threading enables C# program to perform concurrent processing so one can do
more than one operation at a time. For example, one can use threading to monitor
input from the user, perform background tasks, and handle simultaneous streams of
input. The System Threading namespace provides classes and interfaces that support
multithreaded programming and enable to easily perform tasks such as creating and
starting new threads, synchronizing multiple threads, suspending threads, and aborting
threads.
Serial communication in win32
Serial communications in Microsoft Win32 is significantly different from serial
communications in 16-bit Microsoft Windows. Those familiar with 16-bit serial
communications functions will have to relearn many parts of the system to
program serial communications properly.
AT-Commands
AT commands are instructions used to control a modem. AT is the abbreviation of
Attention. Every command line starts with "AT" or "at". That's why modem
commands are called AT commands.
Page 7
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
Page 8
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.
Page 9
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
Page 10
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
Page 11
(e.g.: close windows and doors and switch on the heating if the temperature is
low, switch on/off appliances, etc). Mobile devices can provide some
improvements to the performance of HA systems. Indeed, they allow people to be
connected independently of time and space constraints. In this report the problem
of implementing a WAP access and related interfaces for HA systems remote
control, is addressed. [1]
ii. Work-Summary:
This research paper provides an overview of the capabilities that we are
developing as part of the Pebbles research project for wireless handheld devices
such as mobile phones and palm-size computers like Palm Organizers and
PocketPCs. Instead of just being used as a phone or organizer, handheld devices
can also be used as remote controls for computers and household and office
appliances. [2]
iii. Work Summary:
Virtual reality tools for robot teleoperation via the Internet have been developed.
Two systems for WWW-based control of the PUMA and CRS robot manipulators
have been developed using these tools. Experiments with these systems on robot
control from a long distance (England-Russia, France-Russia) with a low-speed
Internet connection revealed that only real-time 3D virtual environments should
be used for efficient robot control. TV images produce intrinsic delays and should
only be used, from time to time, for checking that the system operates normally,
or that some particular event (grasping or dropping the object) has really occurred.
System realization with open technologies Java, Java3D and 3-tier client/server
architecture provided system portability among the different computer platforms
and types of robots. [3]
iv. Work Summary:
PdaDriver is a Personal Digital Assistant (PDA) system for vehicle teleoperation.
It is designed to be easy-to-deploy, to minimize the need for training, and to
enable effective remote driving through multiple control modes. This paper
presents the motivation for PdaDriver, its current design, and recent outdoor tests
with a mobile robot. [4]
v. Work Summary:
Describes an easy to use handheld remote control device for controlling all the
home appliances. The user interface is designed as simple as possible without
losing the usability issues. This kind of controlling system is very robust and
Page 12
adaptive. It is possible to configure the system in very different environments.
And because the most of the calculations can be done in a powerful computer the
controlling device itself can be kept very simple and cheap especially when it is
manufactured in a large scale. The user interface in this prototype has been kept
very simple and easy to use. [5]
vi. Work Summary:
This paper proposes a Home Network System (HNS) architecture integrated with
Wireless Application Protocol and Short Message Service to support the
connectivity between home and Internet/Global System for Mobile
Communication (GSM) networks. The HNS architecture includes an HNS
gateway and three home network subsystems, i.e., home appliance, security and
messaging subsystems. The main objective of the integrated system is to remotely
monitor and control the devices in the HNS via laptop computer or a GSM mobile
terminal. [6]
Page 13
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.
Page 14
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
Page 15
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:
Page 16
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.
Page 17
CHAPTER-4
PROPOSED SYSTEM
4.1 ARCHITECTURE OF PROPOSED SYSTEM
4.1.1 Architecture Diagram
Figure 4.1: Event driven architecture for system monitoring.
Page 18
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
Page 19
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
Page 20
attacks. To overcome this, our proposed architecture uses an anomaly-based detection
approach, which models normal behaviors and attempts to identify abnormal activities on
the computer. The precondition for such anomaly detection IDS to work is to create a
range of normal behaviors. In our system, this normal base is established through an
extensive user profiling process whose purpose is to build an in-depth knowledge of how
the user uses this computer. The following information is derived: during normal usage of
the computer, what processes take what kind of actions on what hardware resources or
software objects?
4.2 .2 Alarm Fusion
Once an abnormal event happens, it is very likely to trigger multiple alarms at
Subject, Verb and Object checkpoints. In order to minimize redundant alarms and
condense alarms that stem from the same event into one integral alarm, an alarm fusion
module is needed. In the proposed architecture, a multi-level alarm fusion algorithm is
used.
The first one is a source preprocessing level, which synchronizes the information
flow from different sensors to reduce data redundancy for further processes. The second
level is alarm normalization, which transforms different alarms into a consistent set of
scale. The third level is spatial alarm fusion, which fuses alarms from different anomaly
detection monitors. The fourth level is temporal alarm fusion, which analyzes alarms
within a certain time window and gives more useful intrusion information.
4.2.3 Alarm Verification
The task of this module is to verify the correctness of fused alarms in an effort to reduce
false alarms. The verification module works by checking the normality of an event that
has triggered an alarm. This includes checking the frequency of similar operations that
have been performed before, as well as identifying the security level of the objects that
the process is trying to access.
4.2.4 Impact Evaluation
A successful attack on a computer usually results in considerable impact on some
aspects of its normal operation. Such impact includes disruption of critical services,
undermined computation capability, and increased network latency due to excessive
outbound traffic and hardware resource exhaustion. To evaluate the impact of an attack, it
is necessary to carry out a detailed comparison of system characteristics before and after
an alarm is triggered. This is made possible by our real-time system performance
Page 21
monitoring tool, which collects system run-time performance data and saves them into a
system metadata database.
4.3 DECISION SUPPORT AND AFTERMATH MITIGATION
One of the major contributions of the proposed architecture is its capability to
provide insightful information on current attacks and more precise counteraction with
regard to the Subject, Verb or the Object. Depending on which elements of the SVO triple
pose threats to the protected system, the decision support engine can automatically
perform any one or a combination of the following three categories of actions:
Ban current user
Terminate operation
Quarantine objects
Page 22
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
Page 23
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-
Page 24
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.
Page 25
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
Page 26
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
Page 27
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.
Page 28
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)
Page 29
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
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.
Page 30
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.
Page 31
Configurational
Manager
Remote Server
Snapshot
Track URL
Keystroke
Tracker
Pointing Device
Tracker
Main
Application
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.
Page 32
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)
Page 33
is considered to be a specialized form of the other (the supertype) and supertype is
considered as Generalization of subtype. In practice, this means that any instance of the
subtype is also an instance of the supertype. An exemplary tree of generalizations of this
form is found in binomial nomenclature: human beings are a subtype of simian, which are
a subtype of mammal, and so on. The relationship is most easily understood by the phrase
'A is a B' (a human is a mammal, a mammal is an animal).
The UML graphical representation of a Generalization is a hollow triangle shape on
the supertype end of the line (or tree of lines) that connects it to one or more subtypes.
The generalization relationship is also known as the inheritance or "is a" relationship. The
supertype in the generalization relationship is also known as the "parent", superclass, base
class, or base type.
The subtype in the generalization relationship is also known as the "child", subclass,
derived class, derived type, inheriting class, or inheriting type. Note that this relationship
bears no resemblance to the biological parent/child relationship: the use of these terms is
extremely common, but can be misleading.
Generalization can only be shown on class diagrams and on Use case diagrams.
In UML modeling, a realization relationship is a relationship between two model
elements, in which one model element (the client) realizes the behavior that the other
model element (the supplier) specifies. A realization is displayed in the diagram editor as
a dashed line with an unfilled arrowhead towards the supplier. A realization is a
relationship between classes, interfaces, components, and packages that connects a client
element with a supplier element. A realization relationship between classes and interfaces
and between components and interfaces shows that the class realizes the operations
offered by the interface.
Page 34
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.
Page 35
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.
Page 36
:ShortMessage
ShortMessage
[from DesignView ]
{namespace=OutlookPCControl}
OutLookContextMenu
[from DesignView ]
{namespace=OutlookPCControl}
CaptureScreen
[from DesignView ]
{namespace=OutlookPCControl}
+ 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.
Page 37
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
Page 38
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
Page 39
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).
Page 40
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
Page 41
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
Page 42
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.
Page 43
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:
Page 44
public delegate IntPtr PtrCALLBACK(int nCode, IntPtr wParam,
IntPtr lParam);
Whenever a keyboard event occurs, the following parameters will be passed to
CALLBACK_func:
nCode: The callback function should return the result of CallNextHookEx if
this value is less than zero. Normal keyboard events will return an nCode of 0 or
more.
WParam: This value indicates what type of event occurred: key up or key down
and whether the key pressed was a system key (left or right-hand Alt keys).
lParam: A structure to store precise information on the intercepted event. In this
particular case the keystroke. The type of this parameter is IntPtr, and when
dealing with a specific event it needs to be cast to the event's defined type.
Information regarding a keystroke can be such as the code of the key which was
pressed.
The structure defined for the keyboard is KBDLLHOOKSTRUCT:
public struct KBDLLHOOKSTRUCT
{
}
The two public parameters are the only ones used by the callback method. vkCode
returns the virtual key code, which can be cast to System.Windows.Form.Keys to
obtain the key's name, while flags indicates if this is an extended key (the Windows Start
key, for instance) or if the Alt key was pressed at the same time.
7.3.3 The Key Logger
After initializing the hook, every keystroke typed by the user is now intercepted and
received by the callback, we present the callback function:
private IntPtr CALLBACK_func(int nCode, IntPtr wParam,
IntPtr lParam)
Page 45
After those line, another filter is activated, one that checks whether the user chose the
"Key Logger" option, and if the current process in which the key was pressed is in the
user selected monitored processes list:
if (KeyActive == true)
{
if( arr[0] ==1 ||
(GetCurrentProcess() == "WINWORD" && arr[1] ==1)||
(GetCurrentProcess() == "EXCEL" && arr[2] ==1)||
(GetCurrentProcess() == "POWERPNT" && arr[3] ==1)||
(GetCurrentProcess() == "notepad" && arr[4] ==1)||
(GetCurrentProcess() == "OUTLOOK" && arr[5] ==1)||
(GetCurrentProcess() == "iexplore" && arr[6] ==1)||
(GetCurrentProcess() == "firefox" && arr[7] ==1)||)
}
Now, we activate the last filter, which left out system key such as Alt and Ctrl.
the method CallNextHookEx forwards the parameters to the next function in the
chain, basically frees the keystroke from the method.
After filtering all of the information with lesser relevance, we print the keystrokes to
the log file with a path written by the user using the method print_character. We
also print the date, process name and window name using the function
PrintCurrentProcessName (it's second parameter determines whether to print a
blank row or not).
7.3.4 Disabling the Key Logger
Whenever the user chooses to stop the keystrokes tracing, the function Dspose is
called, moreover, it is also called when the program terminates, as requested from a class
that derives from IDisposable:
public void Dispose()
{
if (hookID != IntPtr.Zero)
win32API.UnhookWindowsHookEx(hookID);
}
Page 46
7.4 MOUSE LOGGER
When addressing the description of the implementation, we firstly need to install the
low level mouse hook which will intercept all of the mouse clicks. After completing this
stage, we shall describe the key logging.
7.4.1 Initializing Mouse Hook
This section is similar to the keyboard hook initialization, there are however 2
main differences:
idHook: This number determines the type of hook to be set up in the function
SetWindowsHookEx, in previous section it's value was 13. in our case we
change the value to 14 which is the mouse hook's id. To make the code more
legible, this has been assigned to the constant WH_MOUSE_LL.
lParam: A structure to store precise information on the intercepted event. In this
particular case the keystroke. The type of this parameter is IntPtr, and when
dealing with a specific event it needs to be cast to the event's defined type. Our
interests lie under POINT which stores the location of the click. The type of this
parameter is IntPtr, and when dealing with a specific event it needs to be cast to
the event's defined type.
7.4.2 The Mouse Logger
After initializing the hook, every mouse click done by the user is now intercepted
and received by the callback, we present the callback function:
private IntPtr CALLBACK_func(int nCode, IntPtr wParam,
IntPtr lParam)
After this line, another filter is activated, one that checks whether the user chose the
"Mouse Logger" option, and if the current process in which the mouse was clicked is in
the user selected monitored processes list.
7.4.3 Disabling the Mouse Logger
Whenever the user chooses to stop the keystrokes tracing, the function Dispose is
called, moreover, it is also called when the program terminates, as requested from a class
that derives from IDisposable:
Page 47
public void Dispose()
{
}
As already stated earlier, we use the member hookID to terminate the hook, we see
again the similarity between the two intercepted events.
7.5 URL HOOK
This feature allows us to record any web site the user has visited. The output is the
FileURL file (in the usual html format, including date and time for each visited site).
The recording of the sites works the following way: In the handle function of the
keyboard hook, if we get that the key that was pressed is Enter, we call the
StartURLThread() function. We do the exact same thing in the mouse hook, for
each left mouse click (also, if the URLActive Boolean is set to true, meaning the user
chose the option of URL recording). , we call the StartURLThread () function to
execute the command.
7.6 IMAGE RECORDER
One of the software features is the option to obtain screenshots. In the next sections
we'll describe how it is done.
7.6.1 Create a Screenshot
Firstly, we save a bitmap in the size of the screen, and then we create a Graphics
instance from that image (in order to restrain the size). The last stages are the copying and
saving of the new image. The parameter i is saved to create several screenshots. These 5
lines are the entire function OnTimedEvent. One of the screenshots option is to create one
every selected number of minutes defined by the user.
7.6.2 Time Intervals
One of the screenshots option is to create one every selected number of minutes
defined by the user. To achieve that we used time event handling. The first thing to do is
creating an instance of the timer:
public System.Timers.Timer aTimer;
Page 48
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).
Page 49
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
Page 50
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" )
Page 51
{
NetMessage = sr.ReadLine();
...
switch (NetMessage)
{
ca case "Disable":
case "Enable":
case "SendKeyFile":
case "SendMouseFile":
case "SendURLFile":
case "SendPicture":
case "SendStatus":
}
}
Each of the requests is handled individually. It is worth mentioning that the client opens
the socket through port 80 (http) for security reasons.
7.8.2 The Server Side
When first initialize, the server's form is not loaded, the server is merely waiting for
a request from a remote client. Once such a request is sent the form is loaded and the
control on the client can be handled from the form.
It can be seen that a socket is opened and for each button pressed in the form a
message is sent through that socket.
7.8.3 File transferring
One of the main and most useful features of the server is the options of getting the
log files that were created on the client side (our main application). If you choose to if
you choose to connect with an ip number, these lines are the relevent ones (instead of the
last 2) –
Program.client = new TcpClient();
Program.client.Connect(ip_text, 80);
Program.s = Program.client.GetStream();
Page 52
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
Page 53
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
Sl # Test Case : - UTC-2
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
Page 54
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‖
Sl # Test Case : - UTC-4
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
Page 55
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
Sl # Test Case : - ITC-2
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
Sl # Test Case : - ITC-3
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
Page 56
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
Sl # Test Case : - STC-2
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
Actual output: - Same as Expected
Remarks: - Success
Table 8.10: Testing Images transfer
Sl # Test Case : - STC-3
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
Page 57
Actual output: - Same as Expected
Remarks: - Success
Table 8.11: Testing URL log files transfer
Sl # Test Case : - STC-4
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
Sl # Test Case : - STC-5
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
Remarks: - Successful
Page 58
Table 8.13: Check for visual display
Sl # Test Case : - STC-6
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
Remarks: - Successful
Page 59
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.
Page 60
Figure 9.3: Screen capture window
To get the URL we will click on track URL and save the path where we want to
store our information.
Figure 9.4: Track URL window
This gives the key strokes related information.
Page 61
Figure 9.5: Keystroke Tracker window
The pointing device trackers keep list of co-ordinates where ever it will be clicked
by the user on the monitor.
Figure 9.6: Pointing Device Tracker
Use of Sneakiness mode with hot key and password setting, this provides the
administrator a particular password with the help of which it will go in the back
ground and will be hidden in client(users) eyes.
Page 62
Figure 9.7: Use of Sneakiness mode with hot key and password setting
Password entry form after pressing hotkey, it is the only way through which
administrator can get back to its client side form.
Figure 9.8: Password entry form after pressing hotkey
The Key entry in notepad.
Figure 9.9: The Key entry in notepad
Creation of File for key Logging in respective defined folder.
Page 63
Figure 9.10 : Creation of File for key Logging in respective defined folder
Recorded key board entry in HTML file, the detail will get stored in the defined
folder.
Figure 9.11: Recorded key board entry in HTML file
Creation of File for key Logging in respective folder and recorded mouse click.
Page 64
Figure 9.12: Creation of File for key Logging in respective folder & Recorded mouse click entry in
HTML file
Recorded Screen shot images in respective defined folder.
Figure 9.13: Recorded Screen shot images in respective defined folder
Captured Screen Image opened in image viewer, it gives the snap-shots of the
window screen.
Page 65
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:
Page 66
9.2 SERVER SIDE SCREEN
Ones we start running the server side an icon will appear at the taskbar menu
showing Open and Exit Icon.
Figure 9.16: Main Server Icon on Taskbar
Server Start notification Icon in system tray, it comes when we click on the open
option after right click on the icon coming on the task bar.
Figure 9.17: Main Server Screen showing all the options for user
Page 67
Maximum 8-clients can be connected to the single server with their respective IP
address and administrator can check the status of the client side by clicking on the
IP address of the respective client.
Figure 9.18: Concurrent Client connection IP address display
Figure 9.19 Getting Selected Client status
The display of log files (HTML and image files) of the selected client in defined
folder.
Page 68
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
Page 69
Figure 9.22: Client PC is Lock after execution of command
Page 70
CHAPTER-10
PROJECT MANAGEMENT
10.1 PROCESS MODEL USED: PROTOTYPE MODEL
The Prototyping Model is a systems development method (SDM) in which a
prototype (an early approximation of a final system or product) is built, tested, and then
reworked as necessary until an acceptable prototype is finally achieved from which the
complete system or product can now be developed. This model works best in scenarios
where not all of the project requirements are known in detail ahead of time. It is an
iterative, trial-and-error process that takes place between the developers and the users.
There are several steps in the Prototyping Model:
The new system requirements are defined in as much detail as possible. This usually
involves interviewing a number of users representing all the departments or aspects of
the existing system.
A preliminary design is created for the new system.
A first prototype of the new system is constructed from the preliminary design. This is
usually a scaled-down system, and represents an approximation of the characteristics
of the final product.
The users thoroughly evaluate the first prototype, noting its strengths and weaknesses,
what needs to be added, and what should to be removed. The developer collects and
analyzes the remarks from the users.
The first prototype is modified, based on the comments supplied by the users, and a
second prototype of the new system is constructed.
The second prototype is evaluated in the same manner as was the first prototype.
The preceding steps are iterated as many times as necessary, until the users are
satisfied that the prototype represents the final product desired.
The final system is constructed, based on the final prototype.
The final system is thoroughly evaluated and tested. Routine maintenance is carried
out on a continuing basis to prevent large-scale failures and to minimize downtime.
Page 71
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
Page 72
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.
Page 73
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.
Page 74
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.