1.

ABSTRACT
Steganography is a form of science that deals with cryptic information. It is
the art of writing in cryptic text that is unrecognizable to a person who doesnt
hold the key to decrypt it. Steganography is not a new form of science. In fact,
Steganography is derived from the Greek word steganos, which means hidden or
secret and graphy means writing or drawing. Thus steganography means secret
writing. In contemporary terms, steganography has evolved into a digital strategy
of hiding a file in any form of multimedia such as an image, an audio file or even a
video file.The project entitled Audio Steganography is the application developed
to embed a message in an audio signal. This system makes the Files more secure
by using the concepts Steganography and Cryptography.
Steganography, poor cousin of Cryptography is the art of hiding messages
inside other messages such that the very existence of the message is unknown to
third party. The goal of cryptography is to make data unreadable by a third party,
the goal of stenography is to hide the data from a third party Through the use of
advanced computer software, authors of images and software can place a hidden
trademark in their product, allowing them to keep a check on piracy. This is
commonly known as watermarking. Hiding serial numbers or a set of characters
that distinguishes an object from a similar object is known as finger printing.
Together, these two are intended to fight piracy. The latter is used to detect
copyright violators and the former is used to prosecute them. But these are only
examples of the much wider field of stenography.
The cover data should not be significantly degraded by the embedded data,
and the embedded data should be as imperceptible as possible. The embedded
data should be as immune as possible to modifications from intelligent attacks or
anticipated manipulations .Thus it is necessary that the hidden message should be
encrypted.

1. INTRODUCTION
When information is hidden inside audio in program or person hiding the information
will usually use the discrete cosine transform method. It works by slightly changing the each of
the bits in the audio, only so much though so it is not noticeable by the human ears.

1.1 Purpose
The main purpose for preparing this document is to give a general insight into the
analysis and requirements of the existing system or situation and for determining the operating
characteristics of the system. The main objective of this system is that to avoid drawing
suspicion to the transmission of hidden message. The goal of cryptography is to make data
unreadable by a third party, the goal of stenography is to hide the data from a third party through
the use of advanced computer software, authors of images and software can place a hidden
trademark in their product, allowing them to keep a check on piracy. This is commonly known as
watermarking. Hiding serial numbers or a set of characters that distinguishes an object from a
similar object is known as finger printing. Together, these two are intended to fight piracy. The
latter is used to detect copyright violators and the former is used to prosecute them. But these are
only examples of the much wider field of stenography.

1.2. Scope
This Document plays a vital role in the development life cycle (SDLC) .As it describes
the complete requirement of the system. It is meant for use by the developers and will be the
basic during testing phase. Any changes made to the requirements in the future will have to go
through formal change approval process. Actually computerized process in recent years have
contributed to augment security requirements both at the final user level and at the enterprise
level since the massive utilization of computers and the internet with global availability.
Throughout time computational security needs have been focused on different features, Secrecy
and confidentiality, identification, verification, non repudiation, integrity control and availability.
The cover data should not be significantly degraded by the embedded data, and the embedded
data should be as imperceptible as possible. The embedded data should be as immune as possible
to modifications from intelligent attacks or anticipated manipulations. Thus it is necessary that
the hidden message should be encrypted before stenography.

1.3 Advantages

Encryption software protects internet connected computers from crackers and

other online intruders.

The technology is widely used to encrypt credit card information, bank account

numbers and other type of financial records so they can send safely and securely across
the internet.

Protect much of the intellectual content thats marketed on the web, such as

music, Videos, articles, and software, restricting its availability to paying customers.

This system helps to hide the information while sending the important and

confidential documents in video files; it will be invisible for the third person.

This system is helpful for the defense and security departments sending and

receiving the confidential matters in emergency situations.

2. REQUIREMENT SPECIFICATION

2.1Software Requirements
A set of programs associated with the operation of a computer is called software.
Software is the part of the computer system which enables the user to interact with several
physical hardware devices.
The minimum software requirement specifications for developing this project are as
follows:

Operating System

Windows XP /2000

Technologies

JAVA 1.6

Web-Server

TOMCAT 7.0

2.2 Hardware Requirement Specification

The Collection of internal electronic circuits and external physical devices used in
building a computer is called Hardware.
The minimum hardware requirement specification for developing this project is as
follows:

Processor

Pentium IV

RAM

512MB RAM

Hard Disk

10GB

3. Software Requirements Analysis

The first step in developing anything is to state the requirements. This applies just as
much to leading edge research as to simple programs and to personal programs, as well as to
large team efforts. Being vague about your objective only postpones decisions to a later stage
where changes are much more costly.
The problem statement should state what is to be done and not how it is to be done. It
should be a statement of needs, not a proposal for a solution. A user manual for the desired
system is a good problem statement. The requestor should indicate which features are mandatory
and which are optional, to avoid overly constraining design decisions. The requestor should
avoid describing system internals, as this restricts implementation flexibility. Performance
specifications and protocols for interaction with external systems are legitimate requirements.
Software engineering standards, such as modular construction, design for testability, and
provision for future extensions, are also proper.
Many problems statements, from individuals, companies, and government agencies,
mixture requirements with design decisions. There may sometimes be a compelling reason to
require a particular computer or language; there is rarely justification to specify the use of a
particular algorithm. The analyst must separate the true requirements from design and
implementation decisions disguised as requirements. The analyst should challenge such pseudo
requirements, as they restrict flexibility. There may be politics or organizational reasons for the
pseudo requirements, but at least the analyst should recognize that these externally imposed
design decisions are not essential features of the problem domain.
A problem statement may have more or less detail. A requirement for a conventional
product, such as a payroll program or a billing system, may have considerable detail. A
requirement for a research effort in a new area may lack many details, but presumably the
research has some objective, which should be clearly stated.
Most problem statements are ambiguous, incomplete, or even inconsistent. Some
requirements are just plain wrong. Some requirements, although precisely stated, have
unpleasant consequences on the system behavior or impose unreasonable implementation costs.
Some requirements seem reasonable at first but do not work out as well as the request or thought.

The problem statement is just a starting point for understanding the problem, not an immutable
document. The purpose of the subsequent analysis is to fully understand the problem and its
implications. There is no reasons to expect that a problem statement prepared without a fully
analysis will be correct.
The analyst must work with the requestor to refine the requirements so they represent the
requestors true intent. This involves challenging the requirements and probing for missing
information. The psychological, organizational, and political considerations of doing this are
beyond the scope of this book, except for the following piece of advice: If you do exactly what
the customer asked for, but the result does not meet the customers real needs, you will probably
be blamed anyway.

4. Software Design
4.1 General
The methodology used to develop this project is object-oriented methodology is based on
function and procedures. It can be said as the development of software by building self-contained
modules as objects that can be easily replaced, modified and reused. In this environment
software is a collection of discrete objects that encapsulate their data as well as the functionality
to model real world objects. Each object has attribute and methods. Objects are grouped into
classes. Here each object is responsible for itself.
This environment emphasizes its cooperative philosophy by allocating tasks among the
objects of the applications. Instead of writing a lot of code we can create a lot of code we can
create a lot of helps to take in an active role.
The main focus of the analysis phase of Software development is on What needs to be
done. The objects discovered during the analysis can serve as the framework or Design. The
classs attributes, methods and association identified during analysis must be designed for
implementation language. New classes must be introduced to store intermediate results during
the program execution.
Emphasis shifts from the application domain o implementation and computer such as user
interfaces or view layer and access layer. During analysis, we look at the physical entities or
business objects in the system, that is, which players and how they cooperate to do the work of
the application. These objects represent tangible elements of the business.
During the Design phase, we elevate the model into logical entities, some of which might
relate more to the computer domain as people or employees. Here his goal is to design the
classes that we need to implement the system the difference is that, at this level we focus on the
view and access classes, such as how to maintain information or the best way o interact with a
user or present information.

Design process:
During the design phase the classes identified in object-oriented analysis Must be
revisited with a shift focus to their implementation. New classes or attribute and Methods must
be an added for implementation purposes and user interfaces. The object-oriented design process
consists of the following activities:

1. Apply design axioms to design classes, their attributes, methods, associations, structure and
protocols Refine and complete the static UML class diagram by adding details to the UML
diagram. This step consists of following activities. *Refine attributes *Design methods and
protocols by utilizing a UML activity diagram to represent the methods algorithms.
*Refine associations between classes
*Refine class hierarchy and design with inheritance
*Iterate and refine again
2. Design the access layer

Create mirror classes: For every business class identified and created. For
example, if there are three business classes, create three access layer classes.

Identify access layer class relationships.

Simplify classes and their relationships: The main goal here is to eliminate
redundant classes and structures.
*Redundant classes: Do not keep two classes that perform similar translate results
activities. Simply select one and eliminate the other.
*Method classes: Revisit the classes that consist of only one or two methods to
see if they can be eliminated or combined with existing classes.

Iterate and refine again.

Define the view layer classes

Design the macro level user interface, identifying view layer objects.

Design the micro level user interface, which includes these activities:
* Design the view layer objects by applying the design axioms and
corollaries.
* Built a prototype of the view layer interface.

Test usability and user satisfaction

Iterate and refine.

3. Iterate refine the whole design process. From the class diagram, you can begin to extrapolate
which classes you will have to built and which existing classes you can reuse. As you do this,
also begin this; also begin thinking about the inheritance structure. If you have several classes
that seem relates but have specific differences.
Design also must be traceable across requirements, analysis, design from the Requirements
model.
DESIGN AXIOMS
Axioms are a fundamental truth that always is observed to be valid and for which there is
no counter example or exception. Such explains that axioms may be hypothesized form a large
number of observations by nothing the common phenomena shared by all cases; they cannot be
proven or derived, but they can be invalidated by counter examples or exceptions. A theorem is a
proposition that may not be self-evident but can be proven from accepted axioms. If therefore, is
equivalent to a law or principle. A corollary is a proposition that follows from an axioms or
another proposition that has been proven. Again, corollary is shown to be valid or not valid in the
same manner as a theorem. In the two important axioms axiom 1 deals with relationships
between system components and axiom 2 deals with the complexity of design.
The following the two important axioms:
Axiom 1: The independence axiom, which maintain the independence of the components.

Axiom 2: The information axioms that maintain the information content of the design.
Axioms1 states that, during the design process, as we go from requirement and use case to a
system component, each component must satisfy that requirement without affecting other
requirements.
An axiom 2 is concerned with simplicity. Scientific theoreticians often rely on a general rule
known as Occams razor, after William of Occam. He says, The best theory explains the known
facts with a minimum amount of complexity and maximum simplicity and straightforwardness.
The best designs usually involve the least complex code but not necessarily the fewest number of
classes or methods. Minimizing complexity should be the goal, because that produces the most
easily maintained and enhanced application. In an object-oriented system, the best way to
minimize complexity is to use inheritance and the systems built in classes and to add as little as
possible to what already is there.
From the two design axioms, many corollaries may be derived as a direct consequence of the
axioms. These corollaries may be more useful in marking specific design decisions, since they
can be applied to actual situations.
1. Uncoupled design with less information content: Highly cohesive objects can improve
coupling because only a minimal amount of essential information need be passed
between objects. The degree or strength of coupling between two components is
measured by the amount and complexity of information transmitted between them.
2.

Single purpose: Each class must have single, clearly defined purposes.

3.

Large number of simple classes: Keeping the classes simple allows reusability.

Large

and complex classes are too specialized to be reused.

4.

Strong mapping: There must be a strong association between the physical system and
logical design. During the design phase, we need to design this class, design its methods,
its association with other objects. So a strong mapping links classes should be identified.

5. Standardization: promote standardization by designing interchangeable and reusing

existing classes or components.
6. Design with inheritance: Common behavior must be moved to super classes. The super
class-sub class structure must make logical sense.

Refining attributes and methods:

Attributes identified in object oriented analyzed must be refined in the design phase. In the
analysis phase, the name of the attributes was sufficient. But in the design phase, detailed
information must be added to the model. The three basic types of attributes are:
1. Single valued attributes: This has only value or state.
2. Multiplicity or multivalue attributes: This has a collection of many values at any point in
time.
3. Instance connection attributes: This is required to provide the mapping needed by an
object to fulfill its responsibilities.

UML attribute presentation:

Visibility name: type-expression=initial-value
Visibility indicates either public visibility or protected visibility or private visibility. The
public visibility indicates that the attribute can be accessible to all classes. The protected
visibility indicates that the accessibility is given to the subclasses and operations of the class. The
private visibility indicates that the accessibility can be given only to the operations of the class
only.
Type expression is a language dependent specification of the implementation type of an
attribute. Initial value is a language dependent expression for the initial value is optional.
Object oriented methodology involves mainly
a. Analysis
b. Design
c. Prototyping and testing.

Analysis
There are 5 important steps in the analysis. They are
1. Identification of the users/actors.
2. Development a simple business process model.
3. Developing the use cases.
4. Developing the interaction diagrams.
5. Classifications.

Software Methodology
Jacobson Methodologies is used to develop the proposed system.
Introduction
In 1986 BOOCH developed the Object Oriented Design concept is called as BOOCH
METHOD. It covers both analysis and Design phases of the Object Oriented System, The
BOOCH METHOD consists of following diagrams:
Class diagrams
Object diagrams
State transition diagram
Module diagram
Process diagram
Interaction diagram
BOOCH used the large set of symbols. Even though BOOCH defines a lot of symbols to
document almost every design decision, if we work with his method, you will notice that you
never use all these symbols and diagrams; this is this main drawback of the BOOCH METHOD.
In 1991 Jim Raumbaugh develop the OMT (Object Modeling Technique) with the help of
his team It covers analysis, Design and implementation of the system.

OMT separates Modeling into three different parts:

Object Model
Presented by the Object Model and the data dictionary.
Dynamic model
Presented by the State diagrams and Event flow diagrams.
Functional Model
Presented by Data flow and constraints.
There is no traceability in the different phases, both forward and back ward; this is the
main disadvantage of the OMT.
In order to avoid the problems faced in the above two models JACOBSON invented the
one model called as the JACOBSON METHDOLOGIES (Object Oriented Software
Engineering). It will cover the entire life cycle and stress tractability between different phases,
0both forward and back ward, Additionally he invented the Use case diagrams, these diagrams
are necessary to understanding system requirement. It captures the goal of the system. It is used
to identify the Use cases and External users (external users are the users who interact with our
system to complete the task) .
The Jacobson ET Al. Methodologies
JACOBSON METHDOLOGIES (Object Oriented Software Engineering) OOSE cover
the Entire life cycle and stress trace ability between the different phases, both forward and
backward. And Use case diagrams, these diagrams are necessary to understanding system
requirement. It captures the goal of the system. It is used to identify the USE CASES and
External users (external users are the users who interact with our system to complete the task)
The Use case Description must contain
HOW and WHEN the use case begins and ends.
The interaction between the use case and its actors, including WHEN the
interaction occurs and WHAT is exchanged.

 HOW and WHEN the use case will need data stored in the system or will store
data in the system.
EXCEPTION TO THE flow of events.
HOW and WHEN concepts of the problem domain are handled.

By using the use case model we will find the External users, External users are the users
who will interact with our system to complete the task. Every single use case should describe one
main flow of events. An exceptional additional flow of events could be added.
4.2 Data Flow Report
There are two types of DFDs they are
1. Context Level DFD
2. Top Level DFD and
Context Level DFD:
In the Context Level the whole system is shown as a single process.

No data stores are shown.

Inputs to the overall system are shown together with data sources (as External
entities).

Outputs from the overall system are shown together with their destinations (as
External entities).

Top Level DFD:

The Top Level DFD gives the overview of the whole system identifying the major
system processes and data flow. This level focuses on the single process that is drawn in the
context diagram by Zooming in on its contents and illustrates what it does in more detail.

OBJECT ORIENTED SOFTEWARE ENGINEERING

Object oriented software engineering also called, as the objectory. It is build around several
models:

USE CASE MODEL: The use-case model defines the outside (actor) and
inside (use case) of the systems behavior.

DOMAIN OBJECT MODEL: The objects of the real world are

mapped in to the main object model.

ANALYSS OBJECT MODEL: The analysis object model presents how

the source code (implementation) is carried out and written.

IMPLIMENTATON MODEL: The implementation model represents the

implementation of the system.

TEST MODEL: The test model constitutes the test plan, specification
and reports.

JACOBSON METHDOLOGY consists of following diagrams:

Use case Diagrams
UML activity diagram
UML use Case Diagram
Sequence diagrams
Class diagrams
Business class diagrams
USE CASE DIAGRAMS

A use case describes a sequence of actions that provide something of measurable value to
an actor and is drawn as a horizontal ellipse an actor is a person, organization, or external system
that plays a role in one or more interactions with your system.
ACTIVITY DIAGRAM
Activity diagrams are used to document workflows in a system, from the business level
down to the operational level. When looking at an Activity diagram, you'll notice elements from
state diagram, the Activity diagram is a variation of the state diagram where the "states"
represent operations, and the transitions represent the activities that happen when the operation is
complete. The general purpose of Activity diagrams is to focus on flows driven by internal
processing vs. external events.
SEQUENCE DIAGRAMS
UML sequence diagrams model the flow of logic within your system in a visual manner,
enabling you both to document and validate your logic, and are commonly used for both analysis
and design purposes. Sequence diagrams are the most popular UML artifacts for dynamic
modeling, which focuses on identifying the behavior within your system.

4.3 UML Diagrams

4.3.1 Use Case Diagram
A use case diagram is a diagram that shows a set of use cases and actors and
relationships.
Contents
Use case commonly contain
Use cases
Actors
Dependency, generalization and association relationships

User Use Case

Process Flow

4.3.2 Activity Diagrams:

An activity diagram shows the flow from activity to activity. An activity is an ongoing nonatomic execution within a state machine.
Activities ultimately result in some action, which is made up of executable atomic
computations that result in a change in state of the system or the return of a value.
Activity diagrams commonly contain
Activity states and action states
Transitions
Objects

Like all other diagrams, activity diagrams may contain notes and constrains

Encryption Process

Decryption Process

4.3.3 Sequence and collaboration diagrams

An interaction diagram shows an interaction, consisting of a set of objects and their

relationships, including the messages that may be dispatched among them.

A sequence diagram is an interaction diagram that emphasizes the time ordering of

messages.

Graphically, a sequence diagram is a table that shows objects arranged along x-axis and
messages, ordered in increasing time, along the y-axis.

Contents

Sequence diagrams commonly contain the following:

Objects
Links
Messages

Like all other diagrams, sequence diagrams may contain notes and constrains
User Sequence

4.3.4 Collaboration Diagram

-

Collaboration is a society of classes, interfaces, and other elements that work together to

provide some cooperative behavior thats bigger than the sum of all its parts.
-

Collaboration is also the specification of how an element, such as a classifier or an operation,

is realized by a set of classifiers and associations playing specific roles used in a specific way
Contents
Collaboration diagrams commonly contain the following:

Objects

Links

Messages

Like all other diagrams, sequence diagrams may contain notes and constrains.

Component Diagram:

5.

CODING/CODE TEMPLATES

5.1 General
A programming tool or software tool is a program or application that software developers
use to create, debug, maintain, or otherwise support other programs and applications. The term
usually refers to relatively simple programs that can be combined together to accomplish a task.
The Chapter describes about the software tool that is used in our project.
5.2 Java Technology
Initially the language was called as oak but it was renamed as Java in 1995. The primary
motivation of this language was the need for a platform-independent (i.e., architecture neutral)
language that could be used to create software to be embedded in various consumer electronic
devices.
Java is a programmers language.
Java is cohesive and consistent.

 Except for those constraints imposed by the Internet environment, Java gives the
programmer, full control.
Finally, Java is to Internet programming where C was to system programming.

5.2.1 Importance of Java to the Internet

Java has had a profound effect on the Internet. This is because; Java expands the Universe of
objects that can move about freely in Cyberspace. In a network, two categories of objects are
transmitted between the Server and the Personal computer. They are: Passive information and
Dynamic active programs. The Dynamic, Self-executing programs cause serious problems in the
areas of Security and probability. But, Java addresses those concerns and by doing so, has
opened the door to an exciting new form of program called the Applet.

6. TESTING AND IMPLEMENTATION

6.1 Testing

Testing Methodologies
o Black box Testing:
o White box Testing.
o Gray Box Testing.

Levels of Testing
o Unit Testing.
o Module Testing.
o Integration Testing.
o System Testing.
o User Acceptance Testing.

Types Of Testing
o Smoke Testing.
o Sanitary Testing.

o Regression Testing.
o Re-Testing.
o Static Testing.
o Dynamic Testing.
o Alpha-Testing.
o Beta-Testing.
o Monkey Testing.
o Compatibility Testing.
o Installation Testing.
o Adhoc Testing.
o Ext.

TCD (Test Case Documentation)

STLC
o Test Planning.
o Test Development.
o Test Execution.
o Result Analysis.
o Bug-Tracing.
o Reporting.

Microsoft Windows Standards

Manual Testing

Automation Testing (Tools)

o Win Runner.
o Test Director

Testing:

The process of executing a system with the intent of finding an error.

Testing is defined as the process in which defects are identified, isolated, subjected for
rectification and ensured that product is defect free in order to produce the quality
product and hence customer satisfaction.

Quality is defined as justification of the requirements

Defect is nothing but deviation from the requirements

Defect is nothing but bug.

Testing --- The presence of bugs

Testing can demonstrate the presence of bugs, but not their absence

Debugging and Testing are not the same thing!

Testing is a systematic attempt to break a program or the AUT

Debugging is the art or method of uncovering why the script /program did not execute
properly.
Testing Methodologies:

Black box Testing: is the testing process in which tester can perform testing on an
application without having any internal structural knowledge of application.
Usually Test Engineers are involved in the black box testing.

White box Testing: is the testing process in which tester can perform testing on an
application with having internal structural knowledge.
Usually The Developers are involved in white box testing.

Gray Box Testing: is the process in which the combination of black box and white box
techniques are used.

Levels of Testing:

Module1

Module2

Module3

Units

Units

Units

Integration o/p i/p

Integration o/p

i/p

System Testing: Presentation + business +Databases

UAT: user acceptance testing

STLC (SOFTWARE TESTING LIFE CYCLE)

Test Planning:
1.Test Plan is defined as a strategic document which describes the
procedure how to perform various testing on the total application in the most
efficient way.
2. Objective of testing,
3. Areas that need to be tested,
4. Areas that should not be tested,
5. Scheduling Resource Planning,
7. Areas to be automated, various testing tools used

Test Development:

1. Test case Development (check list)

2. Test Procedure preparation. (Description of the test cases)

Test Execution:

1. Implementation of test cases. Observing the result.

Result Analysis:

1. Expected value: is nothing but expected behavior

Of application.
2. Actual value: is nothing but actual behavior of the
application

Bug Tracing:
Reporting:

Collect all the failed cases, prepare documents.

Prepare document (status of the application)

Types Of Testing:

Smoke Testing: is the process of initial testing in which tester looks for the availability of all the
functionality of the application in order to perform detailed testing on them. (Main check is for
available forms)

Sanity Testing: is a type of testing that is conducted on an application initially to check for the
proper behavior of an application that is to check all the functionality are available before the
detailed testing is conducted by on them.

Regression Testing: is one of the best and important testing. Regression testing is the process in
which the functionality, which is already tested before, is once again tested whenever some new
change is added in order to check whether the existing functionality remains same.

Re-Testing: is the process in which testing is performed on some functionality which is already
tested before to make sure that the defects are reproducible and to rule out the environments
issues if at all any defects are there.

Static Testing: is the testing, which is performed on an application when it is not been executed.
ex: GUI, Document Testing

Dynamic Testing: is the testing which is performed on an application when it is being executed.
ex: Functional testing.

Alpha Testing: it is a type of user acceptance testing, which is conducted on an application when
it is just before released to the customer.

Beta-Testing: it is a type of UAT that is conducted on an application when it is released to the

customer, when deployed in to the real time environment and being accessed by the real time
users.

Monkey Testing: is the process in which abnormal operations, beyond capacity operations are
done on the application to check the stability of it in spite of the users abnormal behavior.

Compatibility testing: it is the testing process in which usually the products are tested on the
environments with different combinations of databases (application servers, browsersetc) In
order to check how far the product is compatible with all these environments platform
combination.

Installation Testing: it is the process of testing in which the tester try to install or try to deploy
the module into the corresponding environment by following the guidelines produced in the
deployment document and check whether the installation is successful or not.

Adhoc Testing: Adhoc Testing is the process of testing in which unlike the

formal testing

where in test case document is used, with out that test case document testing can be done of an
application, to cover that testing of the future which are not covered in that test case document.
Also it is intended to perform GUI testing which may involve the cosmotic issues.

7. OUT-PUT RESULTS
7.1 Screens

Audio Steganography: Home Page

Write Your Text Here

Give the path of wav file here

Now click Embed

We can view status of operation as follows

Now to Decode change URL as given in below screen:

Hit Enter below screen will appear

Give the path of encoded file name with path in the above highlighted screen
Then click on get message button to get the message.

8. CONCLUSION
Steganography especially combined with cryptography, is a powerful tool which enables people
to communicate without possible eavesdroppers even knowing there is a form of communication
in the first place. These methods used in the science of steganography have advanced a lot over
the past centuries, especially with the rise of computer era. Although the techniques are still not
used very often, the possibilities are endless. Many different techniques exist and continue to be
developed, while the ways of detecting hidden messages also advance quickly.

9. FUTURE ENHANCEMENTS
In near future, the most important use of steganographic techniques will probably lie in the field
of digital watermarking. Content providers are eager to protect their copyrighted works against
illegal distribution and watermarks provide a way of tracking the owners of these materials.
Although it will not prevent the distribution itself, it will enable the content provider to start legal
actions against the violators of the copyrights as they can now be tracked down.