Virus Detection System

1. INTRODUCTION
1.1 Existing System
A computer virus is a computer program that can copy itself and infect a computer
without permission or knowledge of the user. The term "virus" is also commonly used,
albeit erroneously, to refer to many different types of malware and adware programs. The
original virus may modify the copies, or the copies may modify themselves, as occurs in a
metamorphic virus. anti-virus software that can detect and eliminate known viruses after
the computer downloads or runs the executable. There are two common methods that an
anti-virus software application uses to detect viruses. The first, and by far the most
common method of virus detection is using a list of virus signature definitions. They are
heuristic analysis and signature scanning. In signature scanning only single virus can be
detected at a time where as in The second method is to use a heuristic algorithm to find
viruses based on common behaviors. This method has the ability to detect viruses that anti-
virus security firms have yet to create a signature for.
1.2 Proposed System
irus !etection "ystem is an application which shows the way of approaching a
generic antivirus product. #nlike to some antivirus products which binds themselves to
specific signatures of some particular viruses, this simulation provides a generic approach
by which we are able to detect more than a single virus with a common virus code in the
database.
$or the users of antivirus products who would like to know the simulation of an
antivirus the irus !etection "ystem is an application which shows the way of approaching
a generic antivirus product
#nlike to some antivirus products which binds themselves to specific signatures of
some particular viruses, this simulation provides a generic approach by which we are able
to detect more than a single virus with a common virus code in the database.
1
2. REUIRE!ENT "N"#$SIS
2.1 System Re%uirements&
2.1.1 Hardware Requirements:
The various hardware details re%uired for the pro&ect are,
'()*+"")( , Intel 'entium II or above
'()*+"")( speed , -../ 012 or above
(A3 , 45 36 or above
1!! , 78 36

2.1.2 So't()re Re%uirements&
The various software re%uirements of this pro&ect are,
'9AT$)(3 , :I;!):" <'
$();T +;! , *, *= .;+T
6A*> +;! , 3" A**+""
2
2.2 SRS
2.2.1 Vision
*or the users of antivirus products (+o would like to know the simulation of an
antivirus the ,irus Detection System is an application which shows the way of
approaching a generic antivirus product.
Un-i.e to some antivirus products which binds themselves to specific signatures of
some particular viruses, this simulation provides a generic approach by which we are able
to detect more than a single virus with a common virus code in the database.
2.2.2 Scope
2.2.2.1Overview:
#ser can get the file, folder or the entire system to be scanned by selecting an
option from the scanning form. As a result of this a report is generated which is provided to
the user. If there are any infected files they are listed in the report. The user will be
provided options to delete the infected files or record their locations to delete them later.
The files selected to be deleted by the user will be removed from the computer
permanently. The locations of infected files will be stored in a safe place if the user selects
the option to delete them later. The user is also provided with an option to update the virus
data base by adding a new code or deleting the existing one.
2.2.2.2 Exclusions:-
The new viruses cannot be detected which are not in the database.
2.2.2.3 ssumptions:-
The virus code in the database must be in Assembly level language.
!atabase contains at least one virus code.
3
2.2.3 S!stem "unctions
S.No.
System
Function
Description
DATABASE UPDATION
1. s1.1 Adding new code to the database.
2. s1.2 Deleting the existing old code.
SCANNIN !I"ES
3. s2.1 Scanning the selected #le o$ %olde$
4. s2.& A $e'o$t is gene$ated with stat(s o% scanned #les.
5. s2.)
P$o*ides the o'tion to delete the #les which is
in%ected.
6. s2.+
P$o*ides an alte$nate o'tion to $eco$d the in%ected
#le location.
SCANNING RE!R"
#. s&.1
S$o%s t$e in&ecte' ()es *&ter sc*nnin+ is comp)ete'.
,. s&.2
ro-i'es t$e options )i.e mo-in+ to -*u)t *n' 'e)ete no%.
,I-US ,AU"T
,. s).1 ,iew the a.ected #les.
/ s).2 Delete the selected #les.

2.2.# $lossar!
Virus
co'e
A pro+r*m t$*t in&ects t$e system
Virus
-*u)t
"$e -irus *0ecte' ()es *re store' $ere %$ic$ c*n 1e 'e)ete' )*ter
1y t$e user
4
2.2.% &etailed So'tware Requirements
2.2.%.1 (se case model
2.2.%.1.1 ctors:
Actor Name User
Actor I' AC"231
!escription 4*n')es *)) t*s.s t$rou+$out t$e *pp)ic*tion.
3ain Activities
C*n se)ect t$e set o& ()es in $is C to sc*n t$em.
C*n -ie% t$e Sc*nnin+ report %$en sc*nnin+ is
(nis$e'.
C*n Se)ect t$e options pro-i'e' in Sc*nnin+ report.
C*n up'*te t$e -irus D*t*1*se.
C*n -ie% t$e -irus -*u)t *t *ny time to 'e)ete t$e
in&ecte' ()es.
$re%uency of #se 4i+$
:ork +nvironment ? 9ocation St*n' *)one 5in'o%.
;umber of #sers 1 to 6*ny
5
2.2.%.1.2 )ist o' (se *ases:
Sc*nnin+ Fi)es.
7p'*tin+ D*t*1*se.
Storin+ t$e In&ecte' Fi)es.
2.2.%.1.3 (se case dia+ram:
"i+ 2.2.%.1.3 (se case dia+ram
User
Sc*nnin+
Fi)es
Storin+ t$e
in&ecte' Fi)es.
7p'*tin+
D*t*1*se
6
2.2., &etailed (se *ase &escriptions:
2.2.,.1 Scannin+ -a.le
Use Case
Name
Sc*nnin+ Fi)es
Use Case
ID
7C1
Actor(s) 7ser
Summary
The user can scan a file, folder, And All drives in 3y computer and detects the infected
files, generate a scanning report to #se.
Precondit
ions
D*t*1*se must cont*in *t )e*st one co'e.
Main Flow 1. "$e user enters t$e use c*se.
2. 7ser se)ects one o& t$e options8 S1
or S2 or S3. For S1 *n' S29 7ser must
enter:se)ect t$e ()e n*me or &o)'er
n*me.
1.1. System 'isp)*ys t$e )ist o&
Sc*nnin+ options. "$e &o))o%in+
options *re +i-en to t$e user.
S1. "o Sc*n A ()e.
S2. "o Sc*n A &o)'er.
S3. "o Sc*n A-*i)*1)e Dri-es in 6y
Computer.
2.1. "$e se)ecte' option ;su1 <o%=
is e>ecute'.
#
Sub Flows S1: Scannin A !le
1. 7ser se)ects S1 *&ter se)ectin+
Sc*nnin+ !ptions.
1.1. 7ser se)ects t$e ()e
&rom ()e 1ro%ser.
1.2. System +ener*tes t$e
sc*nnin+ Report *&ter
Sc*nnin+ Comp)ete'.
S": Scannin A #older
1. 7ser se)ects S2 *&ter se)ectin+
Sc*nnin+ !ptions.
1.1. 7ser se)ects t$e &o)'er
&rom &o)'er 1ro%ser.
1.2. System +ener*tes t$e
Sc*nnin+ Report *&ter
Sc*nnin+ Comp)ete'.
S$: Scannin All dri%es in My Com&uter
1. 1. 7ser se)ects S3 *&ter
se)ectin+ Sc*nnin+ !ptions.
1.1. System Sc*ns t$e ()es
in A-*i)*1)e Dri-es in 6y
Computer.
1.2. System +ener*tes "$e
Sc*nnin+ Report *&ter
Sc*nnin+ Comp)ete'.
Alternate
Flows
A1. 7ser c$ooses to c*nce) t$e oper*tion. I& it is &rom one o& t$e su1 <o%s9 it
t*.es t$e user to t$e m*in <o%. I& E>it is se)ecte' &rom t$e m*in <o%9 t$e
user is t*.en to t$e *pp)ic*tion m*in screen.
Post
Condition
s
System must +ener*te sc*n report.
Cross
'e#erence
S2.1 9 S2.2 9 S2.3 9 S2.4 9 S2.5
,
Assum&ti
ons
"$e '*t*1*se cont*ins *t )e*st one -irus co'e.
(usiness
'ules
22
Se)uence
Diarams
Screen
S*ot
User Scanner
1: File / folder
3: Scanning Report
2: Scanning
/
2.2.,.2 (pdation -a.le
Use Case
Name
7p'*tin+ D*t*1*se.
Use Case
ID
7C2
Actor(s) 7ser
Summary 7ser c*n A'' * Ne% co'e into '*t*1*se *n' 'e)ete t$e o)' co'e &rom
'*t*1*se
Precondit
ions
Main Flow 1. "$e user enters t$e use c*se.
2. 7ser se)ects one o& t$e options8 S1
or S2 or S3.
1.1. System 'isp)*ys t$e )ist o&
D*t*1*se options. "$e &o))o%in+
options *re +i-en to t$e user.
S1.A''in+ * ne% co'e into
'*t*1*se.
S2.A''in+ Co'e &rom AS6 Fi)e to
'*t*1*se.
S2.De)ete !)' co'e &rom '*t*1*se.
2.1 "$e se)ecte' option ;su1 <o%= is
e>ecute'.
Sub Flows S1+Addin a new code into database+
1. 7ser se)ects S1 *&ter se)ectin+
'*t*1*se !ptions.
1.1. 7ser enters t$e co'e
n*me *n' instructions to
'*t*1*se.
1.2 7ser *''s t$e co'e
n*me *n' instructions to
'*t*1*se.
1.3 7ser is returne' to t$e
m*in <o%.
13
S"+Addin new codes #rom ASM !le to database+
1. 7ser se)ects S2 *&ter se)ectin+
'*t*1*se !ptions.
1.1. 7ser enters t$e co'e
n*me se)ects t$e AS6 ()e
&rom ()e 1ro%ser.
1.2 Co'e n*me *n'
instructions *re *''e' to
'*t*1*se.
1.3 7ser is returne' to t$e
m*in <o%.
S"+Delete ,ld code #rom database+
1. 7ser se)ects S2 *&ter se)ectin+
'*t*1*se !ptions.
1.1. 7ser se)ects *-*i)*1)e
co'e n*mes *n' instructions
&rom '*t*1*se.
1.2 7ser 'e)etes t$e se)ect
co'e n*me *n' instructions
&rom '*t*1*se.
1.3 7ser returne' to t$e m*in
<o%.
Alternate
Flows
A1. 7ser c$ooses to c*nce) t$e oper*tion. I& it is &rom one o& t$e su1 <o%s9 it
t*.es t$e user to t$e m*in <o%. I& E>it is se)ecte' &rom t$e m*in <o%9 t$e user
is t*.en to t$e *pp)ic*tion m*in screen.
Post
Condition
Virus '*t*1*se %i)) 1e up'*te' 1y *''in+ ne% co'e or 'e)etin+ t$e e>istin+
co'e.
11
s
Cross
'e#erence
S1.19S1.2
Assum&ti
ons
1. "$ere *re on)y -irus co'es in '*t*1*se.
(usiness
'ules
22
Se)uence
Diaram
User Database
1: Adding code
3: Status
2: Updating
4: Deleting Code
6: Status
: Updating
12
Screens*
ot
13
2.2.,.3 Vault -a.le
Use Case
Name
Storin+ t$e In&ecte' ()es
Use Case
ID
7C3
Actor(s) 7ser
Summary Virus V*u)t cont*ins t$e )ist o& ()en*mes %$ic$ *re in&ecte' 1y * -irus in
'*t*1*se.
Precondit
ions
?oc*tions o& Fi)es in -irus -*u)t s$ou)' not 1e mo'i(e'.
Main Flow 1. "$e user enters t$e use c*se.
2. 7ser se)ects one option or c)oses t$e
&orm.
1.1. System 'isp)*ys t$e )ist o&
in&ecte' ()es. Fo))o%in+ options is
+i-en to t$e user.
S1.De)ete ()es.
2.1 "$e se)ecte' option ;su1 <o%= is
e>ecute'.
Sub Flows S1+ Delete File
1. 7ser se)ects S1 *&ter se)ectin+
Virus -*u)t.
1.1. System 'e)etes t$e
se)ecte' ()e &rom Computer.
Alternate
Flows
A1. 7ser c$ooses to c*nce) t$e oper*tion. I& it is &rom su1 <o%9 it t*.es t$e
user to t$e m*in <o%. I& E>it is se)ecte' &rom t$e m*in <o%9 t$e user is t*.en
to t$e *pp)ic*tion m*in screen.
Post
Condition
s
Se)ecte' ()es %i)) 1e remo-e' &rom C
Cross
'e#erence
S3.19S3.2
Assum&ti
ons
Virus -*u)t cont*ins in&ecte' ()es on)y.
14
Se)uence
Diaram
(usiness
'ules
22
Screens*
ot
User !irus !ault
Selecting "ption
#ro$ide "ption %Delete files&
Delete files
15
2.2./ "unctional *apa.ilities
"$e *0ecte' ()e )oc*tions must 1e *utom*tic*))y mo-e' to t$e -irus
-*u)t %$en t$e user 'oesn@t se)ect *ny one o& t$e options )i.e 'e)etin+
()e or mo-e to t$e -irus -*u)t in t$e report &orm.
Durin+ t$e sc*nnin+9 ()e s$ou)' not 1e *ccesse' 1y *not$er process.
2.2.0 1on-"unctional Requirements
"$e -irus '*t*1*se s$ou)' 1e up'*te' %it$out internet connection.
;7s*1i)ity=
"$e -irus '*t*1*se s$ou)' 1e up'*te' *s per user reAuirements.
;Support*1i)ity=
5$i)e ()e is 1ein+ sc*nne' 9it s$ou)' not 1e *ccesse' 1y *ny ot$er
process.;Support*1i)ity=
"$e sc*nnin+ process must st*rt %it$in 2 secon's. ;er&orm*nce=
"$e sc*nnin+ process s$ou)' not t*.e )on+ perio' o& time. ;er&orm*nce=
"$e system s$ou)' 1e *-*i)*1)e 24 B #. ;Re)i*1i)ity: *-*i)*1i)ity=
16
/. S$STE! DESI0N
/.1 D)t) Diction)ry
T"1#E NO /&/.1&
N"!E& "*)!+
PURPOSE&
This table is used to store the virus codes that will be used to compare with the translated
file codes.
*olumn ;ame !ata Type "i@e *onstraints
*ode ;ame Text 48 ;)T ;#99
Instruction Text A8 ;)T ;#99
"no Integer -A ;)T ;#99
T"1#E NO /&/.2&
N"!E& (+')(T
PURPOSE&
This table is used to store the file locations and their status that have been scanned
temporarily to pass them to the next module after completing all the selected files.
*olumn ;ame !ata Type "i@e *onstraints
$ilename Text 5AA ;)T ;#99
"tatus Text A8 ;)T ;#99
T"1#E NO /&/./&
N"!E& ,"U#T
1#
PURPOSE&
This table is used to store the locations of the files that are affected and have been moved
to the vault for deleting them in the future.
/.2 D)t)2)se #ogic)- Design
1ormali2ation
;ormali@ation is the process of efficiently organi@ing data in a database. There are
two goals of the normali@ation process, eliminating redundant data Bfor example, storing
the same data in more than one tableC and ensuring data dependencies make sense Bonly
storing related data in a tableC. 6oth of these are worthy goals as they reduce the amount of
space a database consumes and ensure that data is logically stored.
3.2.1 1ormal "orms
The database community has developed a series of guidelines for ensuring that
databases are normali@ed. These are referred to as normal forms and are numbered from
one Bthe lowest form of normali@ation, referred to as first normal form or -;$C through
five Bfifth normal form or A;$C. In practical applications, youDll often see -;$, 5;$, and
4;$ along with the occasional 7;$. $ifth normal form is very rarely seen and wonDt be
discussed in this article.
6efore we begin our discussion of the normal forms, itDs important to point out that
they are guidelines and guidelines only. )ccasionally, it becomes necessary to stray from
them to meet practical business re%uirements. 1owever, when variations take place, itDs
extremely important to evaluate any possible ramifications they could have on your system
and account for possible inconsistencies. That said, letDs explore the normal forms.
3.2.1.1 "irst 1ormal "orm 311"4
$irst normal form B-;$C sets the very basic rules for an organi@ed database,
+liminate duplicative columns from the same table.
*reate separate tables for each group of related data and identify each row with a
uni%ue column or set of columns Bthe primary keyC.
*olumn ;ame !ata Type "i@e *onstraints
$ilename Text 5AA ;)T ;#99
"tatus Text A8 ;)T ;#99
1,
3.2.1.2 Second 1ormal "orm 321"4
"econd normal form B5;$C further addresses the concept of removing duplicative data,
3eet all the re%uirements of the first normal form.
(emove subsets of data that apply to multiple rows of a table and place them in
separate tables.
*reate relationships between these new tables and their predecessors through the
use of foreign keys.
3.2.1.3 -5ird 1ormal "orm 331"4
Third normal form B4;$C goes one large step further,
3eet all the re%uirements of the second normal form.
(emove columns that are not dependent upon the primary key.
3.2.1.# 6o!ce-*odd 1ormal "orm
The criteria for 6oyce-*odd normal form B6*;$C are,
The table must be in 4;$.
+very non-trivial functional dependency must be a dependency on a super key.
3.2.1.% "ourt5 1ormal "orm 3#1"4
The criteria for fourth normal form B7;$C are,
The table must be in 6*;$.
There must be no non-trivial multi valued dependencies on something other than a
super key. A 6*;$ table is said to be in 7;$ if and only if all of its multi valued
dependencies are functional dependencies.
3.2.1., "i't5 1ormal "orm
The criteria for fifth normal form BA;$ and also 'E?;$C are,
The table must be in 7;$.
There must be no non-trivial &oin dependencies that do not follow from the key
constraints. A 7;$ table is said to be in the A;$ if and only if every &oin
dependency in it is implied by the candidate keys.
$or a database to be in 5;$, it must first fulfill all the criteria of a -;$ database.
*olumn ;ame !ata Type "i@e *onstraints
$ilename Text 5AA ;)T ;#99
"tatus Text A8 ;)T ;#99
1/
/./ U!# Di)gr)ms
3.3.1 (se *ase &ia+ram
Use case diagrams are created to visuali@e the relationships between actors and use
cases. A use case is a pattern of behavior the system exhibits. +ach use case is a se%uence
of related transactions performed by an actor and the system.
A flow of events documents is created for each use cases, written from an actor
point of view. !etails what the system must provide to the actor when the use cases are
executed.
Typical *ontents,
1ow the use case starts and ends.
;ormal flow of events.
Alternate flow of events.
+xceptional flow of events.
"i+ure 3.3.1.1 S!m.ols
"ctor

Actor
Use case,
23
3.3.1.2 (se case dia+ram 'or (ser
"i+ure 3.3.1.2 (se case dia+ram 'or (ser
3.3.2 *lass &ia+ram
Use
r
Sc*nnin+
Fi)es
Storin+ t$e
in&ecte' Fi)es.
7p'*tin+
D*t*1*se
21
" C-)ss di)gr)m gives an overview of a system by showing its classes and the
relationships among them. #39 class is a rectangle divided into, class name, attributes,
and operations.
)ur class diagram has three kinds of relationships.
"ssoci)tion -- a relationship between instances of the two classes. There is an
association between two classes if an instance of one class must know about the
other in order to perform its work.
"ggreg)tion -- an association in which one class belongs to a collection. An
aggregation has a diamond end pointing to the part containing the whole. In our
diagram, Order has a collection of Order Det)i-s.
0ener)-i3)tion -- an inheritance link indicating one class is a super class of the
other
22
/./.2.1 C-)ss Di)gr)m 'or ,irus Detection System
User
Scan%&
Delete%&
Data 'ase
$irus code
add code%&
delete code%&
1(()
1
1(()
1
Files
pat*
e+tension
access rig*ts
,o$e to $ault%&
1
1((n
1
1((n
1
1((n
1
1((n
*igure /./.2.1 C-)ss Di)gr)m 'or ,irus Detection System
23
3.3.3 Sequence &ia+ram
A type of interaction diagram, a se%uence diagram shows the actors of the ob&ect
participating in an interaction and the events they generate arranged in a time se%uence.
)ften a se%uence diagram shows the events that results from a particular instance of a
particular instance of a use case but a se%uence diagram can also exist in a more generic
form.
The vertical dimension in a se%uence diagram represents timeF with time preceding
down the page the hori@ontal dimension represents different actors.

!1Cect c)*ss1 !1Cect c)*ss2 !1Cect c)*ss3
24
/././.1 Se%uence Di)gr)m 'or Sc)nning
User Scanner
Selecting "ptions%file-Folder-./ Co,puter&
Displa/ "ptions
0enerates Report
Scanning
*igure /././.1 Se%uence Di)gr)m 'or Sc)nning
25
3.3.# *olla.oration &ia+ram
Collaboration diagrams are also relatively easy to draw they show the relationship
between ob&ects and the order of messages passed between them. The ob&ects are listed as
icons and arrows indicate the messages being passed between them .The numbers next to
the messages are called the se%uence numbers. As the name suggests, they show the
se%uence of the messages as they are passed between the ob&ects. There are many
acceptable se%uence numbering schemes in #39.
*igure 3.3.#.1 *olla.oration &ia+ram
User
Data
base
1: Code 1a,e- 2nstructions
2: Adding
3: Status
4: Code na,e
: Deleting
6: Status
26
4. S$STE! I!P#E!ENT"TION
4.1 Se-ected So't()re
#.1.1 7icroso't.1E- "ramewor8
The .;+T $ramework is a new computing platform that simplifies application
development in the highly distributed environment of the Internet. The .;+T $ramework is
designed to fulfill the following ob&ectives,
To provide a consistent ob&ect-oriented programming environment whether ob&ect
code is stored and executed locally, executed locally but Internet-distributed, or
executed remotely.
To provide a code-execution environment that minimi@es software deployment and
versioning conflicts.
To provide a code-execution environment that guarantees safe execution of code,
including code created by an unknown or semi-trusted third party.
To provide a code-execution environment that eliminates the performance problems
of scripted or interpreted environments.
To make the developer experience consistent across widely varying types of
applications, such as :indows-based applications and :eb-based applications.
To build all communication on industry standards to ensure that code based on
the .;+T $ramework can integrate with any other code.
$irst clearing that Eava is two things Eava language and Eava 'latform. "imilarly .;et is
two things the .;et supported languages and .;et 'latform. ;ow come to ma&or difference
which is root cause of differences between Eava and .;et
2#
-5e ideal o' 9ava 5as alwa!s .een a Sin+le lan+ua+e s5ared .! multiple :lat'orms.
;5ereas .1et is .ased on 7ultiple lan+ua+es s5ared .! sin+le :lat'orm. ;ow come to
derived differences from this ma&or difference.
;et has 3ultilanguage support. :hile &ava has based on &ava language only.
According to 3icrosoft latest news .;et support around 78 languages including
ma&or market share *)6)9 b.net *=.net 'erl and many others.
"ince &ava is multiplatform so itGs set of $ramework *lasses is limited to what is
available on all platforms. :hile .;et has set of all the *lasses available on
3icrosoft 'latform.
;et due to disconnected data access through A!).;et has hi level of performance
against Eava E!6* which re%uires multiple round trips to data base.
Eava has support to open source platform while .;et has no direct support for )pen
source 'latforms.
#.1.2 7et5odolo+!
)ur pro&ect is developed by the following main methodologies,
*= !)T;+T Bfront endC
* Bmiddle endC
3" A**+"" Bback endC
#.1.2.1 * < &ot net:
*= !)T;+T is used as the front end as it is the latest and flexible technology
which is comprised of * and isual *HH. It has a wide range of features which are very
useful.
&ot net "eatures&
!)T;+T makes it easy for your database administrator to set up a centrali@ed unit
database on your unitDs $T' site so that multiple readers can access the "A3+ set
of data files. This means you no longer have to worry about providing database
2,
backups to numerous readers and then trying to coordinate database updates
without someone getting left out of the loop.
!ata securityI The web database is fully encrypted using a data encryption
password that you define. ;o one without that password can view your data, even if
someone hacks into your $T' site or intercepts the database upload.
Through the use of !ata Access 'asswords, the database administrator can control
who can update the data and which functional areaBsC theyDre allowed to update.
Jou can assign the same functional area to more than one user. )f course, the
database administrator retains update authority over the entire database.
$or each !ata Access 'assword, simple checkbox options allow you to block users
with that password from even being able to see sensitive data items, such as social
security numbers and driverDs licenses. ThereDs a separate checkbox for each
sensitive data item, so you have full control.
!)T;+T automatically handles the $T' site interface for you. :hen you log on,
!)T;+T connects to your $T' site, downloads your encrypted database, and
decrypts it. Troop 3aster?'ack 3aster then decompresses the database and loads
the files into your Troop 3aster?'ack 3aster data folder. At that point, you can
even disconnect from the Internet. :hen you exit Troop 3aster?'ack 3aster,
!)T;+T compresses and encrypts your updated database and uploads the
encrypted files back to your $T' site.
2/
!)T;+T guarantees the safe execution of code, including code created by
unknown or semi-trusted third parties. This is where the term managed code comes
from, because the applications have to meet security standards and are managed
&ust for that very purpose.
!)T;+T enables developers to work in a consistent programming environment
whether creating applications for desktops or the Internet. This ensures that
although there are techni%ues that vary between :eb and desktop applications, you
can use the same languages, such as *=.
!)T;+T builds all communication on industry standards to ensure that code based
on the .;+T $ramework can integrate with any other code. .;+T uses <39
extensively, as well as other communication protocols such as ")A' B"implified
)b&ect Application 'rogrammingC, which are both industry standards.
!)T;+T minimi@es software deployment and versioning conflicts. Also called
!99 hell, these conflicts occurred fre%uently when you were developing in prior
platforms such as isual 6asic and using Active< controls. A lot of times when you
installed new versions of your applications, controls would conflict and not work.
!)T;+T eliminates performance problems of scripted or interpreted
environments. +verything is compiled into a common language that the various
parts of the platform are designed to work with.
#.1.3 *oncepts used:
$)(3"
)9+!6 '()I!+(
33

#.1.3.1 "orms:
The ob&ects from the standard classes are called graphical user interface B0#IC
ob&ects, and are used to handle the user interface aspect or programs. The style of
programming we use with these 0#I ob&ects is called event-driven programming. An event
occurs when the user interacts with a 0#I ob&ect. $or example, when we move the cursor,
click on a button, or select a menu choice, an event occurs. In event-driven programs, we
program ob&ects to respond to these events by defining event-handling methods.
31
A form is a general-purpose window in which the user interfaces with the
application. A &ava 0#I application program must have at least one form that serves as the
programGs main window. The visual basic supports the most rudimentary functionality to
support features found in any frame window, such as minimi@ing the window, moving the
window, resi@ing the window and so forth.
#.1.3.2 Oled.:
The )9+ !6 !ata 'rovider is for use with databases that support )9+ !6
interfaces. This data provider uses native )9+ !6 through *)3 interoperability to access
the database and execute commands. To use the )9+!6 !ata 'rovider we must also have
a compatible )9+ !6 provider. The following )9+ !6 providers are, at the time of
writing, compatible with A!).;+T,
7icroso't.9et.Oled..#.= K )9+ !6 'rovider for 3icrosoft Eet
The )9+! !6 !ata 'rovider does not support )9+ !6 5.A interfaces, such as
those re%uired for 3icrosoft )9+ !6 'rovider for +xchange and 3icrosoft )9+ !6
'rovider for Internet 'ublishing. The )9+ !6 !ata 'rovider also does not support the
3"!A"L9 'rovider B3icrosoft )9+ !6 'rovider for )!6*C. The )9+!6 !ata
'rovider is the recommended data provider for applications that use "L9 "erver /.A or
earlier, )racle, or 3icrosoft Access.
The classes for the )9+ !6 !ata 'rovider are found in the "ystem.!ata.)le!b
namespace
In )9+ !6 !ata 'rovider there are four key classes that are derived from the
following A!).;+T interfaces, found in the "ystem.!ata namespace,
>&.*onnection K "%l*onnection and )le!b*onnection
>&.*ommand K "%l*ommand and )le!b*ommand
>&ataReader K "%l!ata(eader and )le!b!ata(eader
>&.&atadapter K "%l!ataAdapter and )le!b!ataAdapter
32
#.1.3.3 *onnection:
The connection classes inherit, as we &ust saw, from the I!b*onnection interface.
They are manifested in each data provider as either the "%l*onnection Bfor the "L9 "erver
!ata 'roviderC or the )le!b*onnection Bfor the )9+ !6 !ata 'roviderC. The connection
class is used to open a connection to the database on which commands will be executed.
#.1.3.# *ommand:
The command classes inherit from the I!b*ommand interface. As with the
connection class, the command classes are manifested as either the "%l*ommand or the
)le!b*ommand. The command class is used to execute T-"L9 commands or stored
procedures against a database. *ommands re%uire an instance of a connection ob&ect in
order to connect to the database and execute a command. In turn, the command class
exposes several execute methods, depending on what expectations you have.
#.1.3.% &ata Reader:
The datareader classes inherit from the I!ata(eader interface. *ontinuing the trend,
the data reader is manifested as either a "%l!ata(eader or an )le!b!ata(eader. The
datareader is a forward-only, read-only stream of data from the database. This makes the
datareader a very efficient means for retrieving data, as only one record is brought into
memory at a time.
#.1.3., &ata dapter:
The !ata Adapter classes inherit from the I!b!ataAdapter interface and are
manifested as "%l!ataAdapter and )le!b!ataAdapter. The !ataAdapter is intended for
use with a !ata"et and can retrieve data from the data source, populate !ataTables and
constraints, and maintain the !ata Table relationships. The !ata"et can contain multiple
!ataTables, disconnected from the database. The data in the !ata"et can be manipulated K
changed, deleted, or added to K without an active connection to the database.
33
4.1.4 C&
The disassembling part of the system re%uires the language that can be written in
both high level and low level and the immediate option is the * language. :e used *
language to create the disassembler and we have created the executable file of the
disassembly program and we used it as a disassembler tool in our pro&ect.
4.1.5 !S "CCESS&
3icrosoft Access has changed the image of desktop databases from specialist
applications used by dedicated professionals to standard business productivity applications
used by a wide range of users. 3ore and more developers are building easy-to-use business
solutions on, or have integrated them with, desktop applications on usersD desktops.
3icrosoft Access has built a tradition of innovation by making historically difficult
database technology accessible to general business users. :hether users are connected by a
9A;, the Internet, or not at all, 3icrosoft Access ensures that the benefits of using a
database can be %uickly reali@ed. :ith its integrated technologies, 3icrosoft Access is
designed to make it easy for all users to find answers, share timely information, and build
faster solutions.
At the same time, 3icrosoft Access has a powerful database engine and a robust
programming language, making it suitable for many types of complex database
applications.
#.1.%.1 &ata en+ine:
3icrosoft Access ships with the 3icrosoft Eet database engine. B$or additional
information on the Eet database engine, please refer to 3icrosoft Eet !atabase +ngine
'rogrammerDs 0uide, published by 3icrosoft 'ressC. This is the same engine that ships
with isual 6asic and with 3icrosoft )ffice. 3icrosoft Eet is a 45-bit, multithreaded
database engine that is optimi@ed for decision-support applications and is an excellent
workgroup engine.
34
3icrosoft Eet has advanced capabilities that have typically been unavailable on
desktop databases. These include,
#.1.%.2 ccess to 5etero+eneous data sources:
3icrosoft Eet provides transparent access, via industry-standard )pen !atabase
*onnectivity B)!6*C drivers, to over -.8 different data formats, including 6orland
International d6ase and 'aradox, )(A*9+ from )racle *orporation, 3icrosoft "L9
"erver, and I63 !65. !evelopers can build applications in which users read and update
data simultaneously in virtually any data format.
#.1.%.3 En+ine-level re'erential inte+rit! and data validation:
3icrosoft Eet has built-in support for primary and foreign keys, database-specific
rules, and cascading updates and deletes. This means that a developer is freed from having
to create rules using procedural code to implement data integrity. Also, the engine itself
consistently enforces these rules, so they are available to all application programs.
#.1.%.# dvanced wor8+roup securit! 'eatures:
3icrosoft Eet stores #ser and 0roup accounts in a separate database, typically
located on the network. )b&ect permissions for database ob&ects Bsuch as tables and
%ueriesC are stored in each database. 6y separating account information from permission
information, 3icrosoft Eet makes it much easier for system administrators to manage one
set of accounts for all databases on a network.
#.1.%.% (pdatea.le d!nasets:
As opposed to many database engines that return %uery results in temporary views
or snapshots, 3icrosoft Eet returns a dynaset that automatically propagates any changes
users make back to the original tables. This means that the results of a %uery, even those
based on multiple tables can be treated as tables themselves. Lueries can even be based on
other %ueries.
35
6inding ob&ects and data is easy with 3icrosoft Access. *omplex data-
management forms can be created easily by dragging and dropping fields and controls onto
the form design surface. If a form is bound to a parent table, dragging a child table onto the
form creates a sub form, which will automatically display all child records for the parent.
3icrosoft Access has a variety of wi@ards to ease application development for both
users and developers. These include,
The !atabase :i@ard, which includes more than 58 customi@able templates to create
full-featured applications with a few mouse clicks.
The Table Analy@er :i@ard, which can decipher flat-file data intelligently from a wide
variety of data formats and create a relational database.
"everal form and report wi@ards, which allow users great flexibility in creating the
exact view of data re%uired, regardless of underlying tables or %ueries.
The Application "plitter :i@ard, which separates a 3icrosoft Access application from
its tables and creates a shared database containing the tables for a multi-user
application.
The 'ivotTableM :i@ard, which walks users through the creation of 3icrosoft +xcel
'ivotTables based on a 3icrosoft Access table or %uery.
The 'erformance Analy@er :i@ard, which examines existing databases and
recommends changes to improve application performance.
In addition to the wi@ards &ust listed, 3icrosoft Access provides a number of ease-of-
use features in keeping with its goal of providing easy access to data for users. These
include,
$ilter by $orm, which allows users to type the information they seek and have
3icrosoft Access build the underlying %uery to deliver only that data, in a form view.
36
$ilter by Input, which allows users simply to right-click on any field, in any view, and
then type the criteria they are looking for into an input box on a pop-up menu. #pon
pressing +;T+(, the filter is applied and the user then sees only the information they
are looking for.
$ilter by "election, which allows users to locate information %uickly on forms or
datasheets by highlighting a selection and filtering the underlying data based on that
selection.
3#
4&2 S"!P#E CODE&
using "ystemF
using "ystem.*ollections.0enericF
using "ystem.*omponent3odelF
using "ystem.!ataF
using "ystem.!rawingF
using "ystem.9in%F
using "ystem.TextF
using "ystem.I)F
using "ystem.!ata.)le!bF
using "ystem.:indows.$ormsF
namespace :indows$ormsApplication-
N
public partial class start , $orm
N
public startBC
N
Initiali@e*omponentBCF
O
private void startP9oadBob&ect sender, +ventArgs eC
N
drives Q +nvironment.0et9ogical!rivesBCF
3,
sdrive Q drivesR8SF
con Q new )le!b*onnectionBT"'roviderQmicrosoft.&et.oledb.7.8Fdata
sourceQ" H sdrive H T"!"Uviruscodes.mdb"CF
try
N
!irectory.*reate!irectoryBsdrive H "!""CF
O
catch B+xception aeC
N
O
try
N
$ile.*opyB"viruscodes.mdb", sdrive H T"!"Uviruscodes.mdb"CF
O
catch B+xception aeC
N
O
try
N
$ile.*opyB"T(IA9.+<+", sdrive H T"!"UT(IA9.+<+",trueCF
O
catch B+xception aeC
3/
N
O
O
new virusvaultBC."howBCF
O
private void add*odeTool"trip3enuItemP*lickBob&ect sender, +ventArgs eC
N
new addBC."howBCF
O
private void add$rom$ileTool"trip3enuItemP*lickBob&ect sender, +ventArgs eC
N
new addfileBC."howBCF
O
private void delete*odeTool"trip3enuItemP*lickBob&ect sender, +ventArgs eC
N
new deleteBC."howBCF
O
private void exitTool"trip3enuItemP*lickBob&ect sender, +ventArgs eC
N
Application.+xitBCF
O
O
43
CODE *OR "DD D"T" 1"SE
public partial class add , $orm
N
public addBC
N
Initiali@e*omponentBCF
O
private void addbutP*lickBob&ect sender, +ventArgs eC
N
try
N
if Bcon."tate QQ 8C
con.)penBCF ?? opening the connection
ss%l Q "select Vfrom codes where nameQD" H text6ox-.Text H "DF"F
cmd Q new )le!b*ommandBss%l,conCF
rdr Q cmd.+xecute(eaderBCF
if Brdr.1as(owsC
N
rdr.(eadBCF
ifBIBrdr.Is!6;ullB8CCC
count Q *onvert.ToInt45Brdr.0etalueB8CC H -F
rdr.!isposeBCF
41
O
O
ss%l Q "insert into codes valuesBD" H text6ox-.Text H "D,D" H text6ox5.Text H
"D," H count H "CF"F
cmd Q new )le!b*ommandBss%l, conCF
cmd.+xecute;onLue
3essage6ox."howB"Instruction inserted
successfully",""uccess",3essage6ox6uttons.)>,3essage6oxIcon.Informa
tionCF
??same code name with different code instructions so we disable the
*)!+;A3+ textbox,enable *9)"+ button
text6ox5.Text Q ""F
text6ox5.$ocusBCF
text6ox-.+nabled Q falseF
closebut.+nabled Q trueF
cmd.!isposeBCF
O
private void closebutP*lickBob&ect sender, +ventArgs eC
N
3essage6ox."howB"D"Htext6ox-.Text H"D *ode has been added successfully, Jou
may insert another
code",""uccess",3essage6ox6uttons.)>,3essage6oxIcon.InformationCF
text6ox-.Text Q ""F
text6ox5.Text Q ""F
42
text6ox-.+nabled Q trueF
closebut.+nabled Q falseF
text6ox-.$ocusBCF
O
private void exitbutP*lickBob&ect sender, +ventArgs eC
N
this.*loseBCF
O
private void addP9oadBob&ect sender, +ventArgs eC
N
stringRS drives Q +nvironment.0et9ogical!rivesBCF
string sdrive Q drivesR8SF
con Q new )le!b*onnectionBT"'roviderQmicrosoft.&et.oledb.7.8Fdata
sourceQ" H sdrive H T"!"Uviruscodes.mdb"CF
O
O
43
"DD *RO! *I#E
private void addbutP*lickBob&ect sender, +ventArgs eC
N
try
N
if Bcon."tate QQ 8C
con.)penBCF
if B(dr.1as(owsC
N
try
N
ss%l Q "select maxBsnoC from codes "F
cmd Q new )le!b*ommandBss%l, conCF
(dr Q cmd.+xecute(eaderBCF
(dr.(eadBCF
sno Q *onvert.ToInt45B(dr.0etInt45B8CCF
O
catch B+xception aeC
N
O
snoHHF
while BBfcode Q tr.(ead9ineBCC IQ nullC
44
N
insert into codes valuesBD" H text6ox-.Text H "D,D" H fcode H "D," H sno H "CF"F
cmd Q new )le!b*ommandBss%l, conCF
xHQcmd.+xecute;onLueryBCF
O
private void browsebutP*lickBob&ect sender, +ventArgs eC
N
open$ile!ialog-."how!ialogBCF
fp Q open$ile!ialog-.$ile;ameF
text6ox5.Text Q fpF
O
private void exitbutP*lickBob&ect sender, +ventArgs eC
N
this.*loseBCF
O
private void addfileP9oadBob&ect sender, +ventArgs eC
N
stringRS drives Q +nvironment.0et9ogical!rivesBCF
string sdrive Q drivesR8SF
con Q new )le!b*onnectionBT"'roviderQmicrosoft.&et.oledb.7.8Fdata
sourceQ" H sdrive H T"!"Uviruscodes.mdb"CF
O
45
O
O
DE#ETE CODE
public deleteBC
N
Initiali@e*omponentBCF
O
private void fillcomboboxBC
N
try
N
if B*on."tate QQ 8C
*on.)penBCF
combo6ox-.Text Q ""+9+*T 1+(+"F
O
catch B+xception aeC
N
3essage6ox."howB";o !ata +xists in !atabase or ;ot Accessible Un'lease
restart Application to "olve this
problem","!atabase+rror",3essage6ox6uttons.)>,3essage6oxIcon.:arningCF
this.*loseBCF
O
O
46
private void deletebutP*lickBob&ect sender, +ventArgs eC
N
try
N
name Q combo6ox-."electedItem.To"tringBCF
int sno Q (dr.0etInt45B8CF
(dr.!isposeBCF
*md.!isposeBCF
s"L9 Q "update codes set snoQsno-- where snoW" H snoF
*md Q new )le!b*ommandBs"L9, *onCF
int y Q *md.+xecute;onLueryBCF
list6ox-.Items.*learBCF
combo6ox-.Items.*learBCF
fillcomboboxBCF
if B*on."tate IQ 8C
*on.*loseBCF
O
catch B+xception aeC
N
O
catch B+xception aeC
N
4#
O
O
private void exitbutP*lickBob&ect sender, +ventArgs eC
N
this.*loseBCF
O
private void combo6ox-P"electedIndex*hangedBob&ect sender, +ventArgs eC
N
try
N
if B*on."tate QQ 8C
*on.)penBCF
(dr.!isposeBCF
*md.!isposeBCF
if B*on."tate IQ 8C
*on.*loseBCF
O
4,
5. TEST C"SES
Testing is the process of detecting errors. Testing performs a very critical role for
%uality assurance and for ensuring the reliability of software. The results of testing are used
later on during maintenance also
5.1 Psyc+o-ogy o' Testing
The aim of testing is often to demonstrate that a program works by showing that it
has no errors. The basic purpose of testing phase is to detect the errors that may be present
in the program. 1ence one should not start testing with the intent of showing that a
program works, but the intent should be to show that a program doesnGt work.
Testing is the process of executing a program with the intent of finding errors.
5.2. Testing O26ectives&
The main ob&ective of testing is to uncover a host of errors, systematically and with
minimum effort and time. "tating formally, we can say,
Testing is a process of executing a program with the intent of finding an error.
A successful test is one that uncovers an as yet undiscovered error.
A good test case is one that has a high probability of finding error, if it exists.
The tests are inade%uate to detect possibly present errors.
The software more or less confirms to the %uality and reliable standards.
4/
%.3 )evels O' -estin+
In order to uncover the errors present in different phases we have the concept of
levels of testing.The basic levels of testing are
*lient ;eeds Acceptance Testing
(e%uirements "ystem Testing
!esign Integration Testing
*ode #nit Testing
%.3.1 (nit testin+:
#nit testing focuses verification effort on the smallest unit of software i.e. the
module. #sing the detailed design and the process specifications testing is done to uncover
errors within the boundary of the module. All modules must be successful in the unit test
before the start of the integration testing begins.
In this pro&ect X+valuation of +mployee 'erformanceY each service can be thought
of a module. There are so many modules like +xecutive, !ebit *ard, *redit *ards,
'erformance, and 6ills. +ach module has been tested by giving different sets of inputs
Bgiving wrong !ebit card ;umber, +xecutive codeC when developing the module as well as
finishing the development so that each module works without any error. The inputs are
validated when accepting from the user.

53
%.3.2 >nte+ration -estin+:
After the unit testing we have to perform integration testing. The goal here is to see
if modules can be integrated properly, the emphasis being on testing interfaces between
modules. This testing activity can be considered as testing the design and hence the
emphasis on testing module interactions.
In this pro&ect Z+valuation of +mployee 'erformanceG, the main system is formed
by integrating all the modules. :hen integrating all the modules I have checked whether
the integration effects working of any of the services by giving different combinations of
inputs with which the two services run perfectly before Integration.
%.3.3 S!stem -estin+
1ere the entire software system is tested. The reference document for this process
is the re%uirements document, and the goals to see if software meets its re%uirements.
1ere entire Z+valuation of +mployee 'erformanceG has been tested against
re%uirements of pro&ect and it is checked whether all re%uirements of pro&ect have been
satisfied or not.
%.3.# cceptance -estin+
Acceptance Test is performed with realistic data of the client to demonstrate that
the software is working satisfactorily. Testing here is focused on external behavior of the
systemF the internal logic of program is not emphasi@ed.
In this pro&ect Z+valuation of +mployee 'erformanceGs have collected some data
and tested whether pro&ect is working correctly or not.
Test cases should be selected so that the largest number of attributes of an
e%uivalence class is exercised at once. The testing phase is an important part of software
development. It is the process of finding errors and missing operations and also a complete
verification to determine whether the ob&ectives are met and the user re%uirements are
satisfied.
51
%.3.% ;5ite 6ox -estin+
This is a unit testing method where a unit will be taken at a time and tested
thoroughly at a statement level to find the maximum possible errors.
I tested step wise every piece of code, taking care that every statement in the code
is executed at least once. The white box testing is also called 0lass 6ox Testing.
I have generated a list of test cases, sample data. :hich is used to check all
possible combinations of execution paths through the code at every module level[
%.3., 6lac8 6ox -estin+
This testing method considers a module as a single unit and checks the unit at
interface and communication with other modules rather getting into details at statement
level. 1ere the module will be treated as a block box that will take some input and generate
output. )utput for a given set of input combinations are forwarded to other modules.
5.4 Test P-)n
Testing commence with a test plan and terminates with acceptance testing. A test
plan is a general document for the entire pro&ect that defines the scope, approach to be
taken and the schedule of testing as well as identifies the test item for the entire testing
process and the personal responsible for the different activities of testing. The test
planning can be done well before the actual testing commences and can be done in parallel
with the coding and design phases. The inputs forming the test plan are
'ro&ect plan
(e%uirements document
"ystem design document
52
This pro&ect plan is needed to make sure that the test plan is consistent with the
over all plan for the pro&ect and the testing schedule matches that of the pro&ect plan. The
re%uirement document and the design document are the basic documents used for selecting
the test units and deciding the approaches to be used during testing. A test plan should
contain the following
Test unit specification
$eatures to be tested
Approaches for testing
Test deliverables
"chedule
)ne of the most important activities of the test plan is to identify the test units. The
test unit is a set of one or more modules, together with associated date that are from a
single computer program and that are ob&ects of testing.
A test unit can occur at any level and can contain from a single module to the entire
system thus a test unit may be a module, a few modules or a complete system.
%.#.1 -est plan &ocument
A Test 'lan is a general document for the entire pro&ect, which defines the scope,
approach to be taken and the schedule of testing, as well as identifying the test items for
entire testing process and the personnel responsible for the different activities of testing.
A test plan should contain the following
Test unit specification
A test unit is a set of one or more modules together with associated date which are
from a single program and which are the ob&ect of testing. Test unit may be a module, a
few modules or a complete program,. !ifferent units are usually specified for unit,
integration and system testing.
53
The basic units to be tested are
+xecutive 3odule to register +xecutive !etails.
!ebit card 3odule to register !ebit card !etails.
*redit card 3odule to register *redit card !etails.
6ills 3odule to store the 6ills.
'erformance 3odule to store +xecutive 'erformance !etails.
All these modules are integrated and the final system is also tested against various
possible test cases.
%.#.1.1 "eatures to .e -ested:
$eatures to be tested include all software features and combinations of features that
should be tested .A software feature is a software characteristics specified or simplified by
the re%uirements of design documents. These may include functionality, performance,
design constraints and attributes.
All the functional features specified in the re%uirement document will be tested. ;o
testing will be done for the performance. "ince we doesnGt consider the response time,
throughout time and memory re%uirements.
5.4.1.2 pproac5 'or -estin+:
The approach for testing specifies the over all approach to be followed in the
current pro&ect this is some times called testing criteria.
%.#.1.3 -est &elivera.les:
Testing deliverables should be specified in the test plan, before the actual testing
begins. !eliverables could be a list of test cases that were used, detailed results of testing.
Test summary report, test log and data about the code coverage.
54
%.#.1.# Sc5edule
The test log provides a chronological record of relevant details about the execution
of the test cases. !ifferent activities of testing and testing of different units that have
identified.
%.#.1.% :ersonnel allocation
'ersonnel allocation identifies the persons responsible for performing the different
activities.
%.#.1., -est *ase Report
1ere we specify all the test cases that are used for system testing. The different
conditions that need to be tested along with the test cases used for testing those conditions
and the expected outputs are given .The goal is to test the different functional
re%uirements, as specified in the re%uirements document. Test cases have been selected for
both valid and invalid inputs.
55
5.5 Test C)ses
%.%.1 dd *ode
Test c)se ID Input Description Expected resu-t
!"PT*8- *ode name
Instruction
0iving codename
without
instruction.
$illing all the fields is
compulsory.
!"PT*85 *ode name
Instruction
0iving
instruction
without
codename.
$illing all the fields is
compulsory.
!"PT*84 *ode name
Instruction
:ithout giving
both codename
and Instruction
$illing all the fields is
compulsory.
!"PT*87 *ode name
Instruction
0iving both the
code name and
Instruction
Instruction inserted
successfully
!"PT*8A *ode name
Instruction
0iving same
codename
*odename already exits,
please enter another
codename
56
%.%.2 dd *ode "rom "ile
Test c)se ID Input Description Expected resu-t
!"PT*8- *ode name
$ile name
0iving codename
without $ile
name.
'lease select A"3 file
!"PT*85 *ode name
$ile name
0iving $ile name
without
codename.
'lease enter the code name
!"PT*84 *ode name
$ile name
:ithout giving
both codename
and $ile name
$illing all the fields is
compulsory.
!"PT*87 *ode name
$ile name
0iving both
codename and
$ile name
*ode lines in file are
inserted successfully
5#
%.%.3 &elete *ode
Test c)se ID Input Description Expected resu-t
!"PT*8- *ode name
instruction
"elect the
codename from
combo box
without database.
no data exits or database
not accessible
!"PT*85 *ode name
instruction
"elect the
codename from
combo box with
instruction.
irus code is deleted
successfully.
%.%.# Virus Vault
Test c)se ID Input Description Expected resu-t
!"PT*8- !elete "elected file is
not present in the
ault
The file was not exists
%.%.% Report
Test c)se ID Input Description Expected resu-t
!"PT*8- 3ove to vault "elected file will
be moved to
virus vault.
!elete function will not
work
7. SCREENS 8 REPORTS
5,
7.1 Output Screens&
7.1.1.1 9ome P)ge

*ig 7.1.1.1 9ome P)ge
5/
7.1.1.2 Sc)nning !odu-e
*ig 7.1.1.2 Sc)nning !odu-e
63
7.1.1./ *or Sc)nning Sing-e *i-e
*ig 7.1.1./ *or Sc)nning Sing-e *i-e
61
7.1.1.4 1ro(se *or Sc)nning Sing-e *i-e
*ig 7.1.1.4 1ro(se *or Sc)nning Sing-e *i-e
62
7.1.1.5 *or Sc)nning Sing-e *o-der
*ig 7.1.1.5 *or Sc)nning Sing-e *o-der
63
7.1.1.7 1ro(se *or Sc)nning Sing-e *o-der
*ig 7.1.1.7 1ro(se *or Sc)nning Sing-e *o-der
64
7.1.1.: *or Sc)nning !y Computer
*ig 7.1.1.: *or Sc)nning !y Computer
65
7.1.2 D)t)2)se Upd)tion !odu-e
*ig 7.1.2 D)t)2)se Upd)tion !odu-e
66
7.1.2.1 *or "dding " Ne( Code To D)t)2)se
*ig 7.1.2.1 *or "dding " Ne( Code To D)t)2)se
6#
7.1.2.2 *orm To "dd T+e Ne( Code
*ig 7.1.2.2 *orm To "dd T+e Ne( Code
6,
7.1.2./ *or "dding " Ne( *i-e To D)t)2)se
7.1.2./ *or "dding " Ne( *i-e To D)t)2)se
6/
C*orm To "dd T+e Ne( Code *rom *i-e
*ig 7.1.2./ *orm To "dd T+e Ne( Code *rom *i-e
#3
7.1.2.5 *or De-eting " Ne( Code *rom D)t)2)se
*ig 7.1.2.5 *or De-eting " Ne( Code *rom D)t)2)se
#1
7.1.2.7 *orm To De-ete T+e Code *rom D)t)2)se
*ig 7.1.2.7 *orm To De-ete T+e Code *rom D)t)2)se
#2
7.1./ 9e-p
*ig 7.1./ 9e-p
#3
7.2 Reports
7.2.1.1 Sc)nning Sing-e *i-e
*ig 7.2.1.1 Sc)nning Sing-e *i-e
#4
7.2.1.2 Sc)nning Report Sing-e *i-e
*ig 7.2.1.2 Sc)nning Report Sing-e *i-e
#5
7.2.1./ Sc)nning Process *or Sing-e *o-der
*ig 7.2.1./ Sc)nning Process *or Sing-e *o-der
#6
7.2.1.4 Sc)nning Report Sing-e *o-der
*ig 7.2.1.4 Sc)nning Report Sing-e *o-der
##
7.2.1.5 Sc)nning Process *or !y Computer
*ig 7.2.1.5 Sc)nning Process *or !y Computer
#,
7.2.1.7 Sc)nning Report *or !y Computer
7.2.1.7 Sc)nning Report *or !y Computer
#/
7.2./ ,irus ,)u-t
*ig 7.2./ ,irus ,)u-t
,3
:. CONC#USION 8 *UTURE SCOPE
:.1 Conc-usion
This pro&ect has dropped a small stone in water, by designing an application that
provides a generic antivirus approach that is used to scan the files efficiently. Xirus
!etection "ystemY being developed by restricting to the present technology available in
our college meets the desired needs of the re%uirements completely.
)ur system can be extended further to an extent at which it can provide more
facilities and flexibility than it provides at present. At present the disassembling of the file
to be scanned is limited to the exe files that were written in * and *HH only. The
disassembler provided in this system may not work properly when we are going to scan the
files that are written in other high level languages. "o more the decompiling tools we can
add we can scan a wide range of variety of files.
:.2 *uture Scope
At present in our system only the files that were scanned and reported as affected
can be deleted or can be moved to vault to delete in future. "o the only option provided for
the user is to delete the affected file. 3ore over the affected file can be repaired by deleting
the virus code that was matched from the disassembled code and restoring the new file
from the repaired code
,1
;. 1I1#IO0R"P9$
0.1 -ext .oo8s
S.NO TIT#E "UT9OR
-. X,isu)- C< 2==5 Express Edition St)rter >it?@ $. "*)TT 6A(>+(,
5. AC<& $OUR ,ISU"# 1#UE PRINT *OR +(I* 6#T): \ T)3J
1UI#DIN0 .NET "PP#IC"TIONSY, (JA;,
4. A" TO B C?@ >. E)"+'1 :+"9+J \
(AE+"1 E+6A A;6IA1
7. X9euristic "n)-ysis CDetecting Un.no(n ,iruses? !AI! 1A(9+J \
A;!(+: 9++.
0.2 ;e.sites Visited
R-S.http,??www.this.net?]frank?pstill.html
R5S http,??www.google.com?antivirus co'es.$tm)
R4S. http,??en.wikipedia.org?wiki?!isassembler
R7S. http,??en.wikipedia.org?wiki?Antivirus
RAS. http,??en.wikipedia.org?wiki?virus
R/S. http,??www.eset.com
,2