CHAPTER ONE

INTRODUCTION
1.1 Background of the Study
Malware or malicious code refers to the broad class of software threats to computer systems and
networks. It includes any code that modifies, destroys or steals data, allows unauthorized access,
exploits or damages a system, or does some-thing that the user does not intend to do. Perhaps the
most sophisticated types of threats to computer systems are presented by malicious codes that
exploit vulnerabilities in applications. Pattern based signatures are the most common technique
employed for malware detection. Implicit in a signature-based method is apriority knowledge of
distinctive patterns of malicious code. The advantage of such malware detectors lies in their
simplicity and speed. While the signature-based approach is successful in detecting known
malware, it does not work for new malware for which signatures have not yet been prepared.
There is a need to train the detector often in order to detect new malware.
Malware authors often tend to obfuscate the executable so as to make analysis difficult and to
evade detection. Four techniques are commonly employed for obfuscating executables. The first
approach, insertion of dead code involves insertion of code that does not change the malware
behavior, such as a sequence of NOPs (no operation instructions). The second approach, register
reassignment involves changing the usage of one register with another such as eax with ebx to
evade detection. The third approach, instruction substitution replaces a sequence of instructions
with an equivalent instruction sequence. Finally, the fourth approach, code transposition involves
jumbling the sequences of instructions in such a way that the behavior of the code remains the
same. We note that, although all of these approaches change the code pattern in order to evade
detection, the behavior of the malware still remains the same.
Past research has focused on modeling program behavior for intrusion and malware detection.
Such modeling of program behavior was first studied by Forrest et al (2017). Their approach
called N-Grams used short sequences of system calls to model normal program behavior. Sekar
et al (2018), used system calls to construct a control flow graph of normal program behavior.
Peisert et al (2017), use sequence of function calls to represent program behavior. Based on such
results, in our approach, we have used API calls as measure of the malware program behavior.
Specifically, we use only a subset of API calls, called critical API calls in our analysis. These
critical API calls are the ones that can possibly cause malicious behavior. API calls have been
used in the past research for modeling program behavior and for detecting malware.
We use static analysis to extract critical API calls from known malicious programs to construct
signatures for an entire malware class rather than for a single specimen of malware. In our
approach, a malicious program is detected by statistical comparison of its API calls with that of a
malware class. The technique presented in this paper aims to detect known and unknown
malicious programs, including self-mutating malware. Also, it is capable of detecting malware
that use common obfuscations. Our approach relies on the fact that the behavior of the malicious
programs in a specific malware class differs considerably from programs in other malware
classes and benign programs.

One of the most common reasons that the signature-based approaches fail is when the malware
mutates, making signature based detection difficult. The presence of such a metamorphism has
already been witnessed in the past. These days, cell phones, such as cell phones and tablets, have
gotten exceptionally main stream because of a decrease in their expense and an expansion in
their functionalities and administrations accessibility. Also, the developing pattern of executing
bring your own gadget (BYOD) approaches in associations has additionally added to the
selection of these advances for ordinary correspondence exercises as well as to help to undertake
systems, industrial applications, and business exchanges, which raise new security issues.
Malware diseases have tormented associations and clients for quite a long time and are becoming
stealthier and expanding in number constantly. Thus, this application is used to secure the user's
device.
1.2 Statement of the Problem.
1. The problem has been largely on how to detect malware.
2. Problem of malfunction because of malware.
3. Problem of accessing data because of malware.
4. Problem of efficiently identifying malware.

1.3 Aim and Objectives

The aim of this project is to develop a malware detection using signature matching.
The specific objectives are.
1. To design a system that will detect malware.
2. To design a system that will identify and block known malicious software.
3. Enable timely and available of comparing its characteristics against a database of known
malware signatures.
4. Ensure retrieval of Information when needed.

1.4 Significance of the Study

This study would help in a good number of ways to malware detection using signature matching.
The result of this study would help individual and organization to detect malware in their system
or device.

1.5 Scope of the Study

The scope of this project is limited to the development systems that detect and prevent malware,
which provide a comprehensive solution to enhance the performance of a system.

1.6 Limitations of Study

In the course of carrying out this research work a number of problems were encountered.
i. Lack of adequate fund to finance the project: this was another limitation to this work because
much money is needed to carry out a detailed research work which is not easily borne by
every student.
ii. Time Constraints: Looking at the interval between the resumption of the final semester, the
time given is too short for collection of required information and a more comprehensive fact
finding for a better work would have been done if given enough time.
1.7 Definition of Terms
Data: It is the facts collected for decision making they are facts that are kept to be processed to
get more information.

Database: A database is a system intended to organize, store, and retrieve large amounts of data
easily. It consists of an organized collection of data for one or more uses, typically in digital
form.

Design:It is the art or process of designing how something will look, work.

Documentation: Material that provides official information or evidence that serves as record;
written specifications and information that describes the product.

Domain Name System (DNS): The mechanism for tracking and regulating Internet domain
names and addresses.

Operation: The method by which a device performs its function.

Packet:It is a short piece of a larger statement. Packets are data sent over computer networks,
such as the Internet.

Protocol:It is a set of guidelines for formatting and processing data.

Security: This helps to prevent unauthorized users from illegally accessing certain data within
the database, it protects your data/ files.

Software: These are set of logically related instructions given to the computer to perform some
specific tasks.

Storage:It is a device for recording (storing) information (data)..

 CHAPTER TWO
LITERATURE REVIEW
2.1 Review of the Study
Several techniques have been studied in the past for malware detection. Cohenand Chess &
White (2017), use sandboxing to detect viruses. They proved that in general the problem of virus
detection is undecidable. Christodorescu and Jha (2019), use static analysis to detect malicious
code in executables. Their implementation called SAFE handles most common types of
obfuscations used by malware writers, such as insertion of NOPs between instructions that are
used to evade detection. Christodorescu et al (2019) exploited semantic heuristics to detect
obfuscated malware. Although, their approach works well for obfuscated malicious programs,
the time taken (over a minute to classify) by their approach makes it impractical for use in
commercial antivirus scanners. Kruegel et al (2015) use control flow graph information and
statistical methods for disassembling obfuscated executables. Bergeron et al (2016) consider
critical API calls and security policies to test for presence of malicious code. Their approach
does not work for obfuscated malicious executables. Zhang et al (2019) use fuzzy pattern
recognition to detect unknown malicious code. The approach does not handle obfuscated
program binaries and gives many false positives.
Martignoni et aluse (2013) real-time program monitoring to detect deobfuscation in memory.
Their implementation Omni Unpack detects obfuscation for both known and unknown packers.
MetaAware identifies patterns of system or library functions called from a malware sample to
detect its metamorphic version. Bilar (2016) uses statistical structures such as opcode frequency
distribution and graph structure fingerprints to detect malicious programs. The approach
presented in this paper detects malicious programs including those with common obfuscations as
well as previously unknown variants of malware families.
Krugel et al (2017) use dynamic analysis to detect obfuscated malicious code, using mining
algorithm. Their approach works well for obfuscated malicious programs but takes several
seconds to test a single program. DOME uses static analysis to detect system call locations and
run-time monitoring to check all system calls are made from a location identified during static
analysis. Min-Sun et al (2018) use dynamic monitoring to detect worms and other exploits. Their
approach is limited to detection of worms and exploits that use hard-coded addresses of API
calls, and does not work for other malware types such as Trojans or backdoors.
2.2 Signature-Based Malware Detection
The utilization of signature-based malware identification serves as a fundamental element inside
our cybersecurity strategy. The present methodology has been developed with the objective of
detecting and preventing the occurrence of established malware patterns and signatures. By
acknowledging these well-established hazards, we can rapidly react to and mitigate them,
thereby offering a strong initial safeguard for small and medium-sized enterprises (SMEs) and
Smart Homes.

2.2.1 Comprehending Signature-Based Detection

The detection method known as signature-based detection operates by utilizing predetermined
patterns or signatures that exhibit distinct characteristics of established malware strains. The
signatures serve as analogous to fingerprints, providing a distinctive means of identification for
malicious software. When network traffic is intercepted, the system retrieves these signatures
and does a comparison with a database containing known malware signatures. In the event that a
match is detected, an alert is activated, indicating the presence of a potential malware hazard.

2.2.2 Details of Implementation

In order to execute signature-based malware detection, a selection of tools and technologies has
been incorporated.
Python and dpkt Package:
Python is widely employed due of its multifunctionality and effectiveness in handling network
traffic. The dpkt package is utilized for the purpose of dissecting network packets and rapidly
retrieving pertinent signatures
Cloud Server Architecture:
The signatures that have been collected are transferred to cloud servers using the Python Flask
framework. The utilization of a cloud-based methodology provides the system with the
flexibility to scale and analyze data in real-time, hence ensuring efficient management of diverse
workloads.
Utilizing Snort and Emerging Threats
The core of our detection system is centered around Snort, an extensively utilized open-source
Intrusion Detection System (IDS) and Intrusion Prevention System (IPS). The Snort system has a
rule-based architecture in order to efficiently identify threats by matching packets with extracted
signatures.

2.2.3 Improved Signature Detection

In order to boost the efficacy of signature-based malware detection, a number of improvements
have been incorporated.
Barnyard2 Integration:
Barnyard2 is employed for the efficient parsing of Snort's binary logs. This procedure facilitates
the arrangement and storage of processed data, hence enabling efficient analysis.

2.3 Signature-Based Malware Detection

Comparison with ClamAV:
In conjunction with our internal repository of signatures, we do cross-reference of extracted
signatures with publicly available databases of malware signatures, such as ClamAV. The
utilization of cross-referencing techniques improves the precision of malware detection and
guarantees the ability to identify exceedingly evasive malware variations.
The incorporation of signature-based security measures is essential for the successful
implementation of our project. By expeditiously detecting and addressing recognized malware
threats, we construct a resilient defense mechanism that effectively thwarts the entrance of well-
established harmful software. The initial layer of protection establishes the foundation for our
behavior-based malware detection system, thereby safeguarding small and medium-sized
enterprises (SMEs) and Smart Homes from a diverse array of cyber threats.

3.4 Behavior-Based Malware Detection

Behavior-based malware detection refers to a method of identifying and mitigating malicious
software by analyzing its behavioral patterns. This approach focuses on the actions and
activities shown by malware, rather than relying solely on signature-based detection methods
Although signature-based malware detection plays a crucial role in safeguarding against
established threats, it is important to acknowledge that hackers are consistently adapting
their strategies. In order to tackle this issue, we integrate behavior-based malware detection
as a dynamic and adaptable strategy for recognizing and mitigating emerging threats.

2.4.1 Explanation of the Behavior-Based Approach

Behavior-based malware detection, commonly referred to as heuristic analysis, is a technique
that centers on the identification of malicious software through the examination of deviations
from anticipated system behavior. In contrast to the utilization of predefined patterns in
signature-based detection, behavior-based detection evaluates the real-time behaviors and
interactions of software.
The aforementioned methodology demonstrates significant efficacy in the detection of
previously unidentified malware variants and zero-day vulnerabilities, hence constituting a
highly beneficial inclusion within our cybersecurity framework.

2.4.2 Models of Supervised Machine Learning

In order to execute behavior-based detection, supervised machine learning models are utilized.
The models have undergone training to identify patterns of behavior that are indicative of
malicious software activity. The models have the capability to detect potential security threats by
analyzing anomalies in system behavior, utilizing historical data on normal system activity as
well as known patterns of malware behavior.

2.4.3 Sources of Data and Analysis in Real-Time

Behavior-based malware detection is predicated upon the ongoing surveillance of network
and system operations. The study relies on network packets and system logs as the main
sources of data. The cloud-based machine learning module evaluates data in real-time as it
traverses the network, making comparisons between current behavior and anticipated trends.
Through continuous evaluation of the conduct exhibited by software and network entities, our
system possesses the capability to identify deviations that may potentially signify the existence
of malicious software. The occurrence of these anomalies elicits alarms and prompts automatic
responses in order to promptly mitigate the perceived threat.
2.4.4 The Implementation of Adaptive Security Measures
The versatility of behavior-based malware detection is considered to be one of its primary
advantages. As the strategies employed by malware continue to develop, our machine learning
models possess the capability to acquire knowledge and adjust accordingly in response to
emerging threats. The versatility of our cybersecurity procedures guarantees their continued
effectiveness in
2.5 Behavior-Based Malware Detection
Countering newly emerging and previously unidentified malware variants.
In the following sections, we will examine the integration of signature-based and behavior-based
malware detection methods inside our security infrastructure. This integration aims to capitalize
on the respective advantages of each technique, thereby bolstering the overall effectiveness of
our cybersecurity measures.
 CHAPTER THREE

METHODOLOGY AND SYSTEM ANALYSIS

3.1 Methodology

System development methodologies are promoted as a means of improving the management and

control of the software development process, structuring and simplifying the process, and

standardizing the development process and product by specifying activities to be done and

techniques to be used. It is often tacitly assumed that the use of a system development

methodology will improve system development productivity and quality. One software

development methodology framework is not necessarily suitable for use by all projects. Each of

the available methodology frameworks are best suitable to specific kinds of projects, based on

various technical, organizational, project and team considerations. These software development

frameworks are often bound to some kind of organization, which further develops, supports the

use, and promotes the methodology framework. The methodology framework is often defined in

some kind of formal documentation. Specific software development methodology frameworks

include:

3.1.1 Prototyping

A prototyping method is a software development process which allows developers to create

portions of the solutions to demonstrate functionality and make needed refinement before

developing the final solution. Software prototyping produces a ‘throw away’ solution that is

designed for the sole purpose of verifying user functionality and for demonstrating capability. It

is an excellent way for the development team to confirm understanding of the requirements and

ensure that the proposed solution is consistent with business expectation. It works well with web-
based development and can quickly help confirm page navigation and other user interaction

requirement.

The Three Major Types of Prototyping are

i. Throwaway

ii. Evolutionary

iii. Incremental

Throwaway or rapid prototyping refers to the creation of a model that will eventually be

discarded rather than becoming part of the final delivered software. ... When this goal has been

achieved, the prototype model is 'thrown away', and the system is formally developed based on

the identified requirements.

Evolutionary prototyping is a software development method where the developer or

development team first constructs a prototype. Note that evolutionary prototyping is similar to

incremental development in that parts of the system may be inspected or delivered to the

customer throughout the software life cycle model.

In an incremental prototyping model the product features are added into each of several

prototypes. Typically development starts with the external features and user interface, and then

adds features as prototypes are developed.

Advantages of Prototyping

i. Encourages active participation by users and producers

ii. Development cost is reduced

iii. Increases system development speed

iv. Identifies any problems with the efficiency of earliest design, requirement analysis and

coding activities.
Disadvantages of Prototyping:

i. User expectation may be above the performance of the prototype.

ii. Possibility of causing system to be left unfinished

iii. Implementing system before they are ready

iv. Night prove to be inadequate for overall organizational needs

3.1.2 Object Oriented Analysis and Design Methodology (OOADM)

This methodology models a system as a group of interacting objects. Each object represents

some entity of interest in the system being modeled, and is characterized by its class, its state

(data element) and its behavior. Various models can be created to show the static structure,

dynamics behavior, and run-time development of these collaborating objects. Object oriented

analysis (OOA) applies object modeling techniques to analyze the functional requirements for a

system, it focuses on what a system does. Object oriented Design (OOD) elaborates the analysis

model to produce implementation specification. It focuses on how the system does things.

Benefits of Object-Oriented

i. Reduced Maintenance: The primary goal of object-oriented development is the

assurance that the system will enjoy a longer life while having far smaller maintenance

costs. Because most of the processes within the system are encapsulated, the behaviors

may be reused and incorporated into new behaviors.

ii. Real-World Modeling: Object-oriented system tends to model the real world in a more

complete fashion than do traditional methods. Objects are organized into classes of

objects, and objects are associated with behaviors. The model is based on objects, rather

than on data and processing.

 iii. High Code Reusability: When a new object is created, it will automatically inherit the

data attributes and characteristics of the class from which it was spawned. The new

object will also inherit the data and behaviors from all super classes in which it

participates. When a user creates a new type of a widget, the new object behaves

"wigitty", while having new behaviors which are defined to the system.

Demerits of Object-Oriented

i. Object-oriented Development is not a panacea - Object-oriented Development is best

suited for dynamic, interactive environments, as evidenced by its widespread acceptance

in CAD/CAM and engineering design systems. Wide-scale object-oriented corporate

systems are still unproved, and many bread-and-butter information systems applications

(i.e. payroll, accounting), may not benefit from the object-oriented approach.

ii. Object-oriented Development is not a technology - Although many advocates are

religious in their fervor for object-oriented systems, remember that all the "HOOPLA" is

directed at the object-oriented approach to problem solving, and not to any specific

technology.

3.1.3 Expert System

Expert system is a computer program that simulates an expert's thinking to solve a particular

problem. It is based on the principles of artificial intelligence, and its reasoning processes are

similar to normal human thinking. An expert system consists of a knowledge base, which

contains encoded knowledge, and an inference engine, which uses the knowledge base in

reasoning about a particular problem. Expert systems are most common in a specific problem

domain and are a traditional application or subfield of artificial intelligence. Expert system is
most valuable to organization that have a high level of know-how experience and expertise that

cannot be easily transferred to other members. They are designed to carry the intelligence and

information found in the intellect of experts and provide this knowledge to other members of

organization for problem solving purpose.

Fig.3.1 Expert System Diagram

3.1.4 Structured System Analysis and Design Methodology (SSADM)

This is a Systematic approach to the Analysis and Design of Information System. SSADM

divides an application development project into modules, stages, steps and tasks and it provides a

framework for describing project in a fashion suited to managing the project.

In detail SSADM, sets out a cascade or water fall view of the system development in which there

are series of steps, each of which leads to the next step. The SSADM stages are:

i. Problem Identification (Preliminary Studies)

ii. Feasibility Study

iii. Analysis

iv. Design

v. Implementation

vi. Maintenance

Benefits of SSADM

Amongst the benefits of using SSADM are:

i. Timelines: Theoretically, SSADM allows one to plan, manage and control a project

well. These points are essential to deliver the product on time.

ii. Usability: Within SSADM special emphasis is put on the analysis of user needs.

Simultaneously, the systems model is developed and a comprehensive demand analysis is

carried out. Both are tried to see if they are well suited to each other.

iii. Respond to changes in the business environment: As in SSADM documentation of

the project’s progress is taken very seriously, issues like business objectives and business

needs are considered while the project is being developed. This offers the possibility to

tailor the planning of the project to the actual requirements of the business.

iv. Effective use of skills: SSADM does not require very special skills and can easily be

taught to the staff. Normally, common modeling and diagramming tools are used.

Commercial CASE tools are also offered in order to be able to set up SSADM easily.

v. Better quality: SSADM reduces the error rate of IS by defining a certain quality level in

the beginning and constantly checking the system.

Disadvantages of SSADM
SSADM puts special emphasis on the analysis of the system and its documentation. This causes

the danger of over-analyzing, which can be very time and cost consuming. Due to various types

of description methods, checks of consistence cannot be carried out. Especially with large

systems, the outline diagram can become very unclear, because all relevant data flows have to be

included.

Chosen Methodology

Based on the above explanations of some system development methodology, the most suited

methodology for the system under study is the SSADM. This method gives the project

development team the opportunity to interact with the system users in order to find out their

mode of operations, the problem they encounter which will lead to the team decision of

designing a new system or modifying the existing one.

3.2 System Analysis

A System is the collection of interrelated units, facts and information that are joined together to

accomplish a specific objective. It can also be seen as a set of interrelated components or parts

that interact to achieve a special/desired goal. Analysis is a process of separating a whole into its

component parts or detailed examination of the different elements of a system or structure of a

system with the potential goal of improving or modifying it.

System analysis is therefore determining the requirement for a new system. Data is collected

about the present system, the data is then analyzed and new requirement is determined. Three

tasks of this phase are: gathering data, analyzing the data, and documenting the analyses.
 i. Data Gathering: The prerequisite information needed are gotten in this phase. Sources

include observation, interviews, and questionnaire and looking at helpful documents, one

of which is the organization chart which shows an organization foundations and levels of

management.

ii. Analyzing data:- there are several tools for the analyzing of data which includes

checklist, decision tables and system flows charts

iii. Documenting system analysis. To document and to communicate the finding of phase 2,

a system analysis report is prepared for higher management.

3.3 Methods of Data Collection

During the research work, data needed for the project was gathered from various sources. In
gathering and collecting necessary data and information needed for system analysis, two major
fact-finding techniques were used in this work and they are:

Primary Source

This refers to the sources of collecting original data in which the researcher made use of
empirical approach such as personal interview and questionnaires.

i. Oral Interview: This is the act of obtaining information through face – to – face
conversation. Questions asked in this case can be outlined or not. For the later, the next
question is usually based on the response of the interviewee.
ii. Observation: The researcher in this case has to in person observe the operations and
activities on-going in the data collection field. Data obtained from there are first hand and
are very useful and important in the course of the study.
iii. Questionnaire: The questionnaire is a written form of interview. The questions are
prepared as a document and given to respondents. The researcher then collates the
response of the respondents after collection.
Secondary Source
The secondary data were obtained by the researcher from magazines, Journal, Newspapers,
Library source and Internet downloads. The data collected from this means have been covered in
literature review in the chapter two of the project.

3.4 Organization and its Environment

USER

SYSTEM

Signature-Based Malware
Detection

Fig 3.2 Organization Structure of the Existing System

3.5 Modus Operandi of the Present System
Signature-based detection is a malware detection approach in which at least one byte of the code
will be compared to an existing signature of already existing malwares, which are stored in a
database known as Blacklist.

3.5.1 Input Analysis

Signature-based Name ******************
Id *****************
Detection *************
Session *************

3.5.2 Process analysis

The admin to collect and analyzed that commodities details are completed register in the form.
ents a file, table, etc. In the
model, a datastore is an object
y. Data Stores are some location
data is held temporarily or
nently. 3.5.3 Output analysis
Signature-based Name virus
Id 1
Detection malware
Session 4
n and Coad
ore Notation 3.5.4 Data Flow Diagram of the Present System
Data Flow Diagram shows the flow of data or information, and can be partitioned into single

processes or functions or grouped together or decomposed into multiple processes. There can be

physical DFD’s that represent the physical files and transactions, or they can be business DFD’s

(aka logical, or conceptual).

PROCESS NOTATIONS

Process (aka Activity, Function)

A process transforms incoming data
DATASTORE NOTATIONS
A data flow diagram illustrates the processes, data stores, and external entities in a business or
flow into outgoing data flow Processes
transform or manipulate data. Each box
has a unique number as identifier (top
left) and a unique name (an imperative -
eg: 'do this' - statement in the main box Datastores are repositories of data in
area) The top line is used for the
location of, or the people responsible the system. They are sometimes also
other system and the data flows between these things.
for, the process.
referred to as files. A repository of
information. In the physical model, this
Yourdon and Coad represents a file, table, etc. In the
Process Notations
logical model, a datastore is an object
nd Sarson Four diagrammatical components are used to develop a DFD. These are:
or entity. Data Stores are some location
where data is held temporarily or
ore Notations
PROCESS NOTATIONS Gane and Sarson
permanently.

PROCESS NOTATIONS
Process Notation

DATAFLOW NOTATIONS
Process (aka Activity, Function)
Dataflows are pipelines through which

RNAL ENTITY NOTATIONS

packets of information flow. Label the

*
A processData movesFlow
transforms through it .Data(represented
arrows with the name of incoming
the data that
Flows depict
data by an arrow)
Process
flow into process. The(aka
outgoing arrows used Activity,
data
data/information flow
flowing Processes
to or from a
to represent Function)
Yourdon and Coad
transform or manipulate data. Each box Datastore Notation
the flows must either start and/or end at

A process
has a unique number astransforms
a process box.
identifier (top incoming data
al Entity(s) (aka Sink, Source,
flow into outgoing
left) and a unique name (an imperative data
- flow Processes
eg: 'do this' - statement in the main box
ator) External entities are
transform
area) The top line or is used manipulate for the data. Each box
locationhas
of, ora the unique people number responsible as identifier (top
outside the system, with which
for, the process.
left) and a unique name (an imperative -
stem communicates. External
eg: 'do this' - statement in the main box
are sources and area)destinations
The top lineof is used for the
tem's inputs *
and
YourdonData Process
outputs.
location
and Coad (represented
of, or the people by a Sarson
circle or rounded rectangle)
Ganeresponsible
and
Process Notations Datastore Notations
al Entities, also for, the known
process. as
EXTERNAL ENTITY NOTATIONS
al source/recipients, are things External Entity(s) (aka Sink, Source,
eople, machines, organisations Terminator) External entities are
objects outside the system, with which
which contribute data or the system communicates. External
entities are sources and destinations of
ation to theGane system
Yourdon and
and Sarson
Process Notation
or Coad
which the system's inputs and outputs.
External Entities, also known as
Process
data/information from it. Notations 'External source/recipients, are things
* External
DATAFLOW NOTATIONS Entity (represented by a square or oval, also called
(eg: people, machines, organisations a 'Source/Sink')
Dataflows are pipelines through which etc.) which contribute data or
packets of information flow. Label the information to the system or which
arrows with the name of the data that receive data/information from it.
moves through it .Data Flows depict
data/information flowing to or from a
process. The arrows used to represent
the flows must either start and/or end at
a process box.

Gane and Sarson

Process Notation

DATAFLOW NOTATIONS
 permanently.
Datastores are repositories of data in
Yourdon and Coad the system. They are sometimes also
Datastore Notation referred to as files. A repository of
information. In the physical model, this
represents a file, table, etc. In the
Yourdon and Coad logical model, a datastore is an object
Datastore Notationor entity. Data Stores are some location
* Data Store (represented by twowhere
parallel lines,
data is sometimes connected
held temporarily or by a vertical)
permanently.

Yourdon and Coad

Gane and Sarson Datastore Notation
0.0 S Commodity
Datastore Notations D1
Data Database
Admin ENTITY Registered Data Database
EXTERNAL FilledNOTATIONS
Registration user
Form
External Entity(s) (aka Sink, Source,
Gane andentities
Terminator) External Sarson are
objects outside Datastore
the system,Notations
with which
the system communicates. External
0.1
entities are sources and destinations
EXTERNAL ENTITY of NOTATIONS
the system's inputs and outputs.
External Entities, also known as
External Entity(s)
'External source/recipients, Gane
are things (aka Sink, Source,
and Sarson
Terminator) Detection
External Notations
Datastore entities are
(eg: people, machines, organisations
etc.) which objects outside
contribute data theorsystem, with which
information to the EXTERNAL ENTITY NOTATIONS
system communicates.
the system or which External
receive data/information
entities from it.
are sources
External Entity(s) (aka of
and destinations Sink, Source,
the system's inputs and outputs.
Terminator) External entities are
External Entities, also
objects known
outside as with which
the system,
the system
'External source/recipients, communicates.
are things External
Approve
entities are sources
(eg: people, machines, organisations and destinations of
the system's inputs and outputs.
etc.) which contribute data or
External Entities, also known as
information to the system
'External or which are things
source/recipients,
receive data/information frommachines,
(eg: people, it. organisations
etc.) which contribute data or
information to the system or which
receiveSignature
data/information from it.
Malware

Fig 3.2 Dataflow Diagram of the present System

3.6 Problem of the Present System

The problems are:

 Has been largely on how to locate commodities where they are produced and the record in the
state. This includes grading of commodities. Standard measures and price attached to each grade.
i. .

3.7 The Proposed System

The proposed system is a computerized commodity Exchange Information system. This system
reduces or eliminates the chances of inaccurate of information in commodity exchange. Enable
timely and easily accessed from the database system.
3.8 High Level Model of the Proposed System

Welcome

Authorization

Main Menu

File Display Print Help

Retrieve Record
Print All Print One
New Daily Exit
Record Complete Manual
d Job All Daily
Record record
About

Add User Change Delete Change

Password Password Admin.
Changeover
Password

Fig. 3.3 High Level Model of the Proposed System

 CHAPTER FOUR

SYSTEM DESIGN

Design is the process of defining the architecture, components, modules, interfaces and data for a

system to satisfy specified requirement. It can also be seen as the act of building a proposed

system from the fact collected through system investigation. System implementation is the

activity of proceeding from a given design of a system to a working version of that system, or the

specific way in which some part of the system is made to fulfill its function.

4.1 Objectives of the Design

1 To design a system that will detect malware.

2 To design a system that will identify and block known malicious software.
3 Enable timely and available of comparing its characteristics against a database of known
malware signatures.
4 Ensure retrieval of Information when needed.

4.1 Data Flow Diagram of the New System

S Database
0.0 D1
Data
Admin Filled Registration Registered Data
Form user

0.1

Detection

Approve

Fig 4.1 Data Flow Diagram of the New System

Signature
Malware
4.2.1 Expanded Dataflow Diagram

The Data Flow Diagram below (fig. 4.2) presents an expanded version of fig. 4.1 above. It shows

the complete entities, processes, data flows and data stores in the proposed computerized

student’s project topic allocation and monitoring system.

0.0 S Commodity
Data D1 Database
Admin Registered Data Database
Filled Registration user
Form

0.1

Detection

Approve

Signature
Malware
4.3 Database Specification

The Database: This is the collection of related data that work together for the sake of references.

The database use in the new system in MS-Access. This MS-ACCESS is an object oriented

database system that was used to link the program to the database.

This tool can also enhanced into MYSQL which its tables are unlimited unlike the access.

In the proposed system, there are many tools used in its planning design and implementation.

These are:

1. Database table: This is the collection of related fields that could reference for a specific

purpose. The main table is the table harboring the list of all registered students.

2. Query: This is a database confirming to particular selected criteria form a table. The

below are the few examples of the queries used in the proposed system.

a. List of all female students gotten from the main table.

b. List of all male students also gotten from the main table.

3. Visual Basic. NET program: This is object oriented programming language which

supports the use of enhanced graphical user interface to showcase the functional of an

online admission system. This programming language was chosen because of it general

accepted usability and efficiency.

4. Data flow diagram: This is a tool used to represent the flow of information in the new

system.

5. Internet connection tool: The web browser that automatically pops up when the

program runs is an internet tool that was embedded to the visual basic environment to

make it more efficient.

 6. Computer system: This is an electronic device that runs the written program and through

which the system was written.

Database Design

Field Data type Field size

User name Text 30

Password Text 30

Lastname Text 30

4.4 Program Modules Specification.

Login Form

Main Form

File Malware Report

Registration Form Detection Available

Detection
User Account

Add New User Signature

List of users Approval

Change User Password Total Malware

Fig 4.4 Program modules specification

Exit
4.5 Input and Output Specifications

4.5.1 Output Specifications

The output of a program determines the input and procedure format. It is necessary to consider

what is required from a system before deciding on how to set about producing it. The system

analyst will need to consider content, format, frequency of documents to be produced. Reports

generated by the system include;

4.5.2 Input Specifications

The program designed involved some input forms in order to achieve or derived some required

output. These forms designed in this system are expected to be used to capture program inputs.

The forms include: login form, main form, file form, transaction form and report form

Table 4.3.2 Registration Form Input Specification

Login Screen

FIELD NAME FIELD TYPE FIELD WIDTH

USER NAME CHARACTER 15

PASSWORD CHARACTER 10

4.6 Algorithms

According to Aguboshim, (2005) Algorithm as a step by step procedure organized into the

correct and logical sequence suitable for solving problem that can be transferred to computer.

There are many ways of representing an algorithm. They include;

i. Flowcharts

ii. Pseudo codes

iii. Decision table

 iv. Dataflow diagram (DFD)

Flowchart is a graphical representation of an algorithm. Therefore we will be using system

flowchart to represent the algorithm of this system.

4.7 SYSTEM FLOWCHART

FILE DOCUMENT

ERROR ONE
CORRECTED
CHECK FOR CORRECTION

DATA INPUT TO SYSTEM DATA STORED AWAY IN FILE

MASTER FILE
AND
TRANSACTION

PROGRAM
PROCESSING

RESULT STORED ON DISK

DISPLAY ON MONITOR
 Fig 4.3 System Flowchart

4.8 Program Flowchart

Start

Enter Password

Is password correct?
NO

YES

Register Exchange

Detection

Save Record

Display Report

Stop
Fig 4.2 Program Flowchart

4.9 Data Dictionary

Data dictionary is a traditional and a separate entity understood to contain the description of

items in the file or database.

Data dictionary contains the list of all files in the database, the number of records in each file and

the names and types each field contains.

In this new system, the data dictionary for each type of data record stored includes:

Table 4.4 Data Dictionary For Registration Form Database

Field Data type Field size

User name Text 30

Password Text 30

Lastname Text 30

CHAPTER FIVE
 SYSTEM IMPLEMENTATIONAND DOCUMENTATION

5.1. System implementation

Implementation, is the period, when the new system is put into use, the implementation begins
after management has accepted the new system, and before then every proposed computer
application should be subjected to a preliminary study to see if it is feasible before management
approval is given. The implementation consists of installation of new system and removal of
existing system. This is achieved by the actual purchase of the right equipments, staff, willing,
and testing of computer program routines or package as may be needed or specified in the
design, creation of files and change over to the new system.
5.2. Hardware requirements
By hardware, the researcher simply refers to the physical components of the computer for the
design and implementation of the system
The specification below is recommended for the project work.
At least a Pentium iv system with the following components
Main processor 3.0GHZ and more
Memory size 2.0GB of ram and more
Hard disk 200GB or more
Standard keyboard and mouse
DVD / CDROM
Printer (laser jet)
Keyboard
UPS (Uninterrupted Power Supply)

5.3. Software requirements

Software simply refers to program. This program constitute of a set of logical instruction that
controls the processor.
Software is further classified into system software and application software. Some of which will
be mentioned below are software that if not in the system. It will not function properly.
It include operating system (service pack and above) and word processing package i.e.
Microsoft office 2007.This program can work effectively on any of this operation system:
Window XP, Window vista, Window 7,8,10
5.4 Installation arrangement
To manipulate and operate the newly developed system, the following installation tasks should
be carried out:
1. Make sure that the power supply plug to the system is properly connected.
2. Check the power supply connections to and from the system for proper connections.
3. Switch on the power source.
4. Power on the computer system.
After these, the computer system is set and ready to be used to install the newly designed system.
5.5 Testing
It is the process of putting the program to test to make sure that the program is working
according to its specification. During the testing, errors were purposely introduced to see if the
old system would detect them but system was able to run freely with correct data and the system
was able to track error when incorrect data are used.
Before a system is made fully operated, it should be thoroughly tested because program may be
running without any form of a syntax error yet not producing the desired result so it is essential
that the user test the system with data from the company. Once the reliability of the system has
been tested, the user should run it with historical data. The computerized result can be checked
for accuracy and consistency against the known results.

5.5.1 Unit testing

Unit testing involves the running a particular part of the program individually in other to
ascertain that particular part of the program is efficiently working. This practice is used to
eradicate errors like semantic, logical, run-time, syntax errors and to see that the program is
working efficiently.

5.5.2 Test data

It is the process of putting the program to test to make sure that the program is working
according to its specification. During the testing, errors were purposely introduced to see if the
old system would detect them but system was able to run freely with correct data and the system
was able to track error when incorrect data are used
5.5.3 Test result
At the end of the testing the program testing was successful, every unit of the program worked
efficiently as a result of thorough unit testing on every part of the program. The program is ready
for use in organizations such as University of Nigeria Teaching Hospital, Enugu.
5.6 Training arrangements
The education and training on the use of computer system is vital, there are lots of benefits to be
obtained especial now we are in a computer age. The management should provide computer
training and personal development programs for everyone connected with the computer system,
so that they will be aware of its functions, its use and how to make the best of it.
5.7 Conversion arrangements
Change over plan (system change over) to electronic version of the new system. It also
involved the method in which the new system (i.e. The Computerized financial management
system) is being implemented in order to increase effective usability. This involves the
following;
 Direct change over.
 Parallel change over.
 Pilot run change over.

Direct change over

This is the instantaneous implementation of the new system and discarding the old system. It is
already accepted that the new system is better than the old system; therefore this new system is
involved where the old system is phased out totally.

Parallel change over

This is the simultaneous operation of the new system and the old system for comparison and
perfected implementation. Here, the operation of the old system and new system are been put in
use concurrently but the new system will finally involved totally.

Pilot run change over

A small portion of the new system is involved and implemented and allowed to run in some
phase of the old operation with a large portion still under evaluations. The system is monitored
and evaluated based on the parameters adopted such as seed, clarity, accuracy est. the result
obtained would establish if the whole system would be implemented or not. Therefore based on
this, the system we will be using the parallel system due to the nature of operation involved in
financial management system. The system will be manually inputted into the system and from
there computerized commence. The mode of change over adopted here is pilot run change over.

5.8 System documentation

System documentation is defined as the formalized details of a record containing the design of
the new system. Documentation serves as information media used by programmers, analysts, and
users to discover the content and objectives of a particular project program. It is kept for future
references on a specific project. The impact of documentation is that it provides a control,
complete and accurate maintenance of standard by programmers. It provides means of
communication with other concern with the program. It provides the technical knowledge of how
the program is designed.