This document describes the development of several tools for covert communication via network protocol modification. It begins with Timeshifter, which modifies the timing of ICMP packets at the network layer. Stegnet was then created to modify ICMP packet contents at the network layer. BitStegNet was finally developed to modify μTP packet headers within BitTorrent traffic at the transport layer, providing covert communication at a higher protocol level. The document outlines the implementation of each tool on virtual and physical test networks to successfully transmit hidden messages via timing or content modifications of network packets.

1. Covert Communications via Data Network Protocols
Robert Waziak Jr.
Illinois Institute of Technology
ABSTRACT
This project began with a proof of concept tool called Timeshifter,
which modified the timing of Internet Control Message Protocol
(ICMP) packets, and concluded with a custom developed tool
called BitStegNet that modified the content of BitTorrent packets
to communicate covertly through the Micro Torrent Transport
Protocol (µTP). Between Timeshifter and BitStegNet, another
custom developed tool, called Stegnet, was demonstrated as the
transition between modifying the timing of ICMP packets at the
Network Layer via Timeshifter and modifying the content of µTP
packets at the Transport Layer via BitStegNet. Stegnet, similar to
Timeshifter, modified how ICMP packets were transmitted and
received and operated only at the Network Layer. Ultimately,
BitStegNet verified the capability to route the transmission of
concealed information across active data networks at a higher
communication layer protocol.
Categories and Subject Descriptors
D.4.4 [Operating Systems]: Communications Management –
message sending, network communications.
General Terms
Algorithms, Measurement, Documentation, Performance,
Reliability, Experimentation, Human Factors, Standardization,
Languages.
Keywords
BitStegNet, BitTorrent, ICMP, iptables, libnetfilter_queue, Linux,
Network Analysis, Network Communication, Netfilter,
NFQUEUE, OSI, Packet Delay, Packet Modification, P2P,
qBitTorrent, Steganography, Stegnet, TCP, Timeshifter, UDP,
µTP.
1. INTRODUCTION
Steganography is a term generally described as the means of
concealing secret information, so that an uninformed party is
unaware of its existence, and extracting it at its destination.
Network Steganography is the process of utilizing active network
protocols as carriers to transmit a covert message, undetectable by
an uninformed party, from a host to its destination. Carriers can
include digital images, audio or video files, or in regards to this
project, an ICMP message from a ping command or a µTP
message by way of BitTorrent packet traffic.
1.1 ICMP
ICMP is the main IP datagram protocol that was focused on
throughout the Timeshifter and Stegnet portions of this project.
More specifically, the networking utility ping was utilized to
establish the ICMP packets necessary to act as a network
steganography carrier. ICMP Type 0 (Echo Reply) and ICMP
Type 8 (Echo) messages from the ping utility were the primary
focus during Stegnet’s packet modification test phase. Figure 1
illustrates the packet structure of a standard Type 0 or Type 8
ICMP message.
Figure 1. ICMP Packet Structure (Ping).
1.2 BitTorrent
BitTorrent is a peer-to-peer (P2P) protocol in which two or more
computers that are uploading or downloading the same torrent
transfer data amongst themselves without the need of a central
server. This server-less file sharing process is referred to as a
swarm. [2] A torrent is a BitTorrent file extension that is used by
BitTorrent clients and contains the files that are to be distributed
as well as the network location of trackers. Trackers are utilized
as servers that assist in connecting seeders--those who are utilized
as file download hosts, and leechers (or peers)--those who are
utilized as file-requesting clients. Trackers share the IP addresses
of seeders and leechers to establish a swarm. [2] Within a swarm,
BitTorrent breaks up and distributes files in hundreds of small
chunks. These chunks are often downloaded non-sequentially and
are rearranged into the correct order by the BitTorrent client while
it monitors which pieces is has acquired and which pieces it still
requires. When a leecher acquires file chunks or the complete
file, it remains connected to the swarm and begins to act as a
seeder; contributing bandwidth for other trackers. qBitTorrent
was the chosen BitTorrent client during the BitStegNet test phase
because of its utilization of µTP. Lastly, the popularity of
BitTorrent and its high-volume of data packets across the Internet,
makes it a highly desirable steganography carrier.
1.3 µTP
µTP is a transport protocol layered on top of the User Datagram
Protocol (UDP) and is utilized as an open standard variation of
UDP within BitTorrent’s P2P File Sharing Protocol. Specifically,
µTP traffic was the main focus towards packet content
modification, particularly in the Timestamp and
Timestamp_Difference fields, during the BitStegNet test phase.
Figure 2 illustrates the packet structure of a µTP message header.
Figure 2. µTP Message Header.
Bits%0'3 Bits%4'7
Type Version
SEQ%Number
Bits%16'31
Connection%ID
Timestamp%(μs)
Timestamp%Difference%(μs)
Window%Size
ACK%Number
Bits%8'15
Extension

2. 1.4 TOOLS
The following information includes the main tools and their
implementations that were utilized to accommodate the packet
delay and packet modification phases of test.
1.4.1 Timeshifter
Timeshifter is an open-source tool, developed by Anfractuosity
[1], written in the C programming language that controls
transmission of data from source to destination. It was developed
to make possible the modification of ICMP packet time delays
and in result, send information from one terminal to another
within a shared virtual network. Timeshifter allows the adjustment
of two variables; x, the interval between two packets threshold –
below or equal to this value generates a zero bit of covert
information, and y, the delay added between two packets to
generate a one bit of covert information [1]. Figure 3 and Figure
4 illustrate Timeshifter’s basic operation within a virtual test
environment; it’s standalone functionality as designed.
Figure 3. Timeshifter on Transmitting Terminal.
Figure 4. Timeshifter on Receiving Terminal.
For this project, Timeshifter was implemented and utilized within
a point-to-point network topology at the Network Layer to send a
covert message from one host to another. Specific modifications
made to incorporate and utilize Timeshifter’s capabilities from its
virtual testing use towards a specifically defined Network Layer
communication protocol is discussed later within this document.
Timeshifter was utilized during timing modification tests.
1.4.2 Stegnet
Stegnet is a custom tool, written in the C programming language,
that is based on the structure and theory of Timeshifter. Stegnet
captures packets similarly to Timeshifter and remains at the
Network Layer in a point-to-point environment. The main
difference is that instead of delaying the packets like Timeshifter
does prior to releasing them, Stegnet modifies the packet’s
contents. To achieve successful packet modification, with regards
to network steganography, Stegnet was utilized to read the content
of a text file (string) and insert that content as plaintext into the
data field of the transmitted ICMP packet. Although effective,
this method of insertion resulted in an impractical approach of
concealment since ease of data detectability was considered high.
Stegnet was utilized during packet modification tests.
1.4.3 BitStegNet
BitStegNet is a custom tool, written in the C programming
language, that follows the same structure of Timeshifter and
Stegnet. Unlike Timeshifter and Stegnet, BitStegNet appropriates
its iptables rule to only forward µTP packets. Additionally,
BitStegNet contains modified scripting code to interpret and edit
the Least Significant Bit (LSB) of the Timestamp and
Timestamp_Difference header fields within those µTP packets to
generate a character to be covertly sent. Figure 5 illustrates the
logical process of modifying the least significant bit of these
header fields.
Figure 5. BitStegNet LSB Modification Flowchart.
BitStegNet was utilized at the Transport Layer, above UDP, and
at the Application Layer via BitTorrent. Figure 6 illustrates the
placement of µTP within the Transport Layer of a BitTorrent
Network stack.
Figure 6. µTP Placement within Transport Layer.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
Illinois Institute of Technology, April #–#, 2016, Chicago, United States
of America.
Copyright © 2016 ACM #-#####-###-#/##/#### …$##.00.
Transport
Layer

3. 1.4.4 libnetfilter_queue
libnetfilter_queue is a userspace library that provides an
Application Program Interface (API) to packets which have be
queued by the kernel packet filter. [6]. It is a library that captures
packets and allows userspace code to interact with the packets and
allows userspace code to interact with the packets in a variation of
ways; the ability to delay packets and the ability to modify
packets being the primary focuses of this project. Packets should
be routed to the appropriate queue (NFQUEUE) in order to be
captured and modified. This is achieved through the modification
of the system’s routing tables via the command iptables.
1.5 Problem
Network steganography can be a very effective means of
embedding and concealing information. Typically, network
steganography can be attained by embedding information through
methods of modifying the timing of the communication’s data
packets or, more thoroughly, modifying the data packets
themselves. Currently, Timeshifter does not include the
capabilities to operate outside of a virtual test environment.
Furthermore, while Timeshifter is intended to modify the timing
of the packet delay, it has not been constructed to modify the
packets themselves, nor does it include the ability to perform at a
higher OSI layer protocol.
The goals of this project included successfully modify both the
timing and content of network packets to send a covert message
between two parties. To attain these goals, the project was
divided into three phases. Phase 1 included implementing and
utilizing Timeshifter on a single virtual test network with two
virtual machines to send a covert message through means of
packet delay modification. Phase 2 included implementing
Timeshifter on a physical test network with two physical
computers connected as point-to-point and modifying it to send a
covert message from one computer to the other through means of
packet delay modification. Phase 3 included the implementation
of Stegnet on a physical test network with two computers
connected point-to-point and sending a covert message from one
computer to the other through means of data packet modification.
Phase 3 demonstrated the ability to transmit a covert message at
the Network Layer through means of packet modification utilizing
Stegnet.
Upon successful results from Phases 1 through 3, the project
evolved into Phase 4. Phase 4 included the implementation of
BitStegNet to successfully send a covert message from one
computer to another at the Transport Layer through the
Application Layer, which verified the capability to successfully
transmit a covert message across an active data network.
1.5.1 Timing
Packet delay modification includes the time, in milliseconds, that
is altered through the use of the Timeshifter tool. This delay is
specified prior to transmission of data packets. The two
communicating parties will agree on the transmission packet delay
to successfully send the covert message. While the additional
delay is noticeable through network traffic analysis, it is intended
to be minimal enough that a monitoring or unauthorized party
would acknowledge it as a typical network delay occurrence.
1.5.2 Packet modification
In order to satisfy the method of network steganography via
packet modification through a ping command or BitTorrent, a
payload must be established to act as a carrier for the hidden
information. Stegnet was utilized to develop this payload by
capturing the packet from NFQUEUE, modifying that ICMP
packet’s Data field with a text string, recalculating the packet’s
checksum with the new data, and releasing the packet to its
destination. It was important to only have the Data field of the
ICMP packet modified. If any other content within the packet
was modified, the message would not have reached its desired
destination. Additionally, BitStegNet was be utilized to promote
the carrier payload by similarly relying on the theory and
operation of NFQUEUE, but instead capturing only µTP packets
and modifying their Timestamp and Timestamp_Difference fields.
2. RELATED WORK
Many researchers developed projects relating to steganography
and depended on the protocol functions associated with the OSI
reference model layers for classifications relating to network
steganography methods. It was revealed that the physical features
of the communication channels were relatively dependent on the
Physical and Network Layers.
Krzysztof Szczypiorski based his model on the insertion of hidden
data into the padding of transmitted symbols and introduced a data
link layer called HICCUPS (Hidden Communication System for
Corrupted Networks). The main focus for his method was to
utilize data transmission frames with intentionally wrong
checksums. Szczypiorski assumed that the terminals can “hear”
the data that was contained within the transmission medium
frames [5]. Generally, terminals would discard frames with
incorrect checksums. In retrospect, terminals that were aware of
this steganography method could read these frames and extract the
hidden data from its payload field.
Additional higher-layer protocol steganography research returned
information that assisted this project towards understanding trends
concerning accomplishment of this its goals. The first of which
included Covert_TCP and the second included a tool called
StegTorrent that also utilized BitTorrent packets.
Covert_TCP used covert channels that were exploited by an
information transfer process that purposely violated the system’s
security policy. The main focus relied on encoding ASCII values
into the packet’s header field, specifically the sequence number,
to pass data between hosts. These packets were intended to
appear as initial connection requests, established data streams, or
similar intermediary steps. Additionally, these packets would
either contain no data or data designed to appear innocent as well
as forged source IP addresses or forged source ports. These
modified packets were useful for tunneling information beyond
some packet filters. [4]
StegTorrent was a steganographic method developed by Pawel
Kopiczko, Wojciech Mazurczyk, and Krzysztof Szczypiorski that
utilized µTP packets within the BitTorrent protocol. It operates
by modifying the order of data packets, via their sequence
number, through the use of a covert channel. “StegTorrent takes
advantage of the facts that in BitTorrent there are usually many-
to-one transmissions and that the µTP header provides a means of
packet numbering and retrieval of their original sequence” [3]
3. IMPLEMENTATION
The following information includes the topologies and specific
implementation methods that were taken for Phase 1: Single
Machine Timing Modification, Phase 2: Network Layer Timing
Modification, Phase 3: Network Layer Packet Modification, and
Phase 4: Transport Layer Packet Modification.

4. 3.1 Phase 1: Single Machine Timing
Modification via Timeshifter
This phase was performed on a virtual Ubuntu network with two
active terminals. The first terminal acted as the transmitting
computer and the second acted as the receiving computer.
Timeshifter, NFQUEUE setup (iptables command), and the
libnetfilter_queue library were implemented, compiled, and
executed on both terminals.
Phase 1 was designed to execute Timeshifter within its intended
environment, a shared virtual network. Figure 3 and Figure 4 can
be referenced to understand the topology of this phase.
3.2 Phase 2: Network Layer Timing
Modification via Timeshifter
This phase was performed on a physical network that included
two computers connected point-to-point with an Ethernet cable.
Both computers were loaded with Ubuntu Linux. One computer
acted as the transmitting computer and the other as the receiving
computer. Figure 7 illustrates the network topology for this phase.
Figure 7. Phase 2 Point-to-Point Network Topology.
NFQUEUE setup (iptables command) and the libnetfilter_queue
library were implemented, compiled, and executed on both
terminals. Timeshifter’s configuration was slightly modified to
operate effectively on a non-virtual environment. The first
modification included changing a command line on the receiving
machine, which will be further discussed in section 4.2. The
second modification includes the transmitting computer not
sending a ping command to the localhost, but instead sending it to
the receiving computer.
Figure 8 and Figure 9 illustrate Timeshifter’s operation on the
Network Layer during Phase 2.
Figure 8. Phase 2 Timeshifter on Sending Computer.
Figure 9. Phase 2 Timeshifter on Receiving Computer.
3.3 Phase 3: Network Layer Packet
Modification via Stegnet
This phase was performed on the same physical network as Phase
2; two computers being connected point-to-point with an Ethernet
cable and both computers being loaded with Ubuntu Linux. One
computer continued to act as the transmitting computer and the
other as the receiving computer. Similar to Phase 2, NFQUEUE
configuration (iptables command) was implemented. To promote
Stegnet’s operation, the library libnetfilter_queue was modified to
allow input the plaintext prior to its compilation, and execution on
both terminals. This modification will be further discussed in
section 4.3.
3.4 Phase 4: Transport Layer Packet
Modification via BitStegNet
This phase was performed on the same physical network as Phase
2 and Phase 3; two computers being connected point-to-point with
an Ethernet cable and both computers being loaded with Ubuntu
Linux. Additionally, both computers were installed with the
BitTorrent client, qBitTorrent, and the sending computer acted as
the tracker. qBitTorrent was also configured on both computers to
be listening for a specific port. This isolated test environment was
intended for the sharing of a torrent using minimal bandwidth.
Figure 10 illustrates the network topology for this phase.
Figure 10. Phase 4 BitStegNet Network Topology.
Similar to Phase 2 and Phase 3, NFQUEUE configuration
(iptables command) was implemented. To promote BitStegNet’s
operation, the library libnetfilter_queue was modified to allow
interpretation and modification of the µTP packet Timestamp and
Timestamp_Difference headers. This modification will be further
discussed in section 4.4.
4. TESTING
The following information includes the testing, results, and
analysis data for Phase 1: Single Machine Timing Modification,
Phase 2: Point-to-Point Timing Modification, Phase 3: Point-to-

5. Point Packet Modification, and Phase 4: Transport Layer Packet
Modification.
4.1 Phase 1: Single Machine Timing
Modification Test via Timeshifter
The following information includes the testing, results, and
analysis data for the Phase 1: Single Machine Timing
Modification test. Timeshifter, NFQUEUE configuration
(iptables command), and the library libnetfilter_queue have been
compiled and initiated on both the transmitting and receiving
terminals. Prior to executing the iptables command, existing
routing tables were flushed. Next, the sending terminal processed
an icmp-type echo-request output rule with a queue number of 0
and the receiving terminal processed an icmp-type echo-reply
input rule with a queue number of 1. These rules were necessary
for the libnetfilter_queue library to be able to capture the modified
time delay packets and send them out afterwards.
4.1.1 Testing
The transmitting terminal initiated a command to send the
message “Hello World” using the command echo “Hello World” |
./timeshifter 0 x y, where x and y substituted for a numerical
value. As referenced earlier, x refers to the packet threshold, or in
milliseconds and the y refers to the added packet delay in
milliseconds. The 0 refers to the queue number initiated in
iptables NFQUEUE. Additionally, the transmitting terminal
initiated a localhost ping command that continuously processed.
In order to receive the message sent by the transmitting terminal,
the receiving terminal executed the command ./timeshifter 1 x y,
where x and y are substituted for the same values initiated by the
transmitting terminal. It is necessary for the values of x and y on
the receiving terminal to match those executed on the transmitting
terminal in order to effectively receive the sent packets. The 0
refers to the queue number initiated in iptables NFQUEUE. At
this point, the receiving terminal begins to receive packets sent by
the transmitting terminal. Various tests were made using
differentiating values of x and y until either the message was not
received intact or the transmission failed entirely.
4.1.2 Results
Table 1 represents several tests that were taken for this phase.
Variations of variables x and y, to include the length of the
transmission time and if the message was received successfully,
are included.
Table 1. Phase 1 Test Results.
4.1.3 Analysis
During Phase 1, it was noted that while the receiving terminal
received a successful message from the transmitting terminal, if
the values for x were too high, the transmission time was elevated.
It was also noted that when the values for y were too low, the
message would return broken and the message was received
unsuccessfully. Phase 1 revealed noticeable variations when the
values of x and y were changed which resulted in a focus of
sending a successful message as quickly as possible. The main
takeaway from these results included the understanding that the
lower the packet threshold and packet delay variables were, the
quicker the transmission time, but utilizing too low values for
either resulted in an increase of errors. These value observations
would be taken into consideration and carried into the Point-to-
Point Timing Modification and Point-to-Point Packet
Modification tests. Ultimately, Timeshifter operated as intended
and effectively modified the timing of packets in order to
successfully pass a covert message between two terminals in a
virtual test environment.
4.2 Phase 2: Network Layer Timing
Modification Test via Timeshifter
The following information includes the testing, results, and
analysis data for the Phase 2: Network Layer Timing Modification
test. Timeshifter, NFQUEUE configuration (iptables command),
and the libnetfilter_queue have been compiled and initiated on
both the transmitting and receiving computers. Prior to executing
the iptables command, existing routing tables were flushed. Next,
the sending terminal processed an icmp-type echo-request output
rule with a queue number of 0. Differentiating from Phase 1, and
its virtual test environment, it was understood that the receiving
terminal would also require process an icmp-type echo-request
input rule with a queue number of 1 in order to communicate in a
point-to-point test environment. These rules are necessary for
NFQUEUE to capture the modified time delay packets.
4.2.1 Testing
Identical to the Phase 1 test, the transmitting computer initiated a
command to send the message “Hello World” using the command
echo “Hello World” | .timeshifter 0 x y and the receiving
computer executed the command ./5imeshifter 1 x y.
Differentiating from Phase 1, instead of the transmitting computer
sending a ping command to the localhost, it pings the receiving
computer. An additional modification necessary to send a
message from one computer to the other on an ICMP Layer 3
network include the way that the receiving computer’s iptables
NFQUEUE module was loaded and compiled. Various tests were
made using differentiating values of x and y until either the
message was not received intact or the transmission failed
entirely. Observed values from Phase 1 were considered and
carried into the Point-to-Point Timing Modification and Point-to-
Point Packet Modification tests.
4.2.2 Results
Table 2 represents several tests that were taken for this phase.
Variations of variables x and y, to include the length of the
transmission time and if the message was received successfully,
are included.
Table 2. Phase 2 Test Results.
Packet
Threshold
in
milliseconds
(x)
Added
Delay
in
milliseconds
(y)
Transmission
Time
in
Seconds
Message
Successful?
1000 1300 82.097 Yes
1000 1200 81.129 Yes
1000 1100 81.124 Yes
1000 1025 80.131 Yes
1000 1000 N/A No

6. 4.2.3 Analysis
Similar to the testing results of Phase 1, the adjustment of the x
and y variables returned noticeable results. It was revealed that a
packet threshold value of 1000ms, or 1s, was the lowest that
would yield a transmission. Any x value lower than 1s would
result in the system not acknowledging it and the message not
being sent. It was currently assumed that Timeshifter could not
compute a threshold of less than 1s. While this limited the
opportunity to encourage testing with smaller values, the focus
remained on the fact that a covert message was being received
successfully at lower values, and quicker times, than those from
Phase 1. In a point-to-point isolated network, the computers did
not require the additional time necessary to respond to ping
requests. Since the transmitting computer was sending a ping
command to its connected receiving computer, no noticeable
delay had occurred. Ultimately, Timeshifter had the ability to
operate effectively on an isolated point-to-point network with the
modification of the receiving computer’s iptables NFQUEUE rule
and in result, the ability to send a covert message over the
Network Layer was possible.
4.3 Phase 3: Network Layer Packet
Modification Test via Stegnet
The following information includes the testing, results, and
analysis data for the Phase 3: Network Layer Packet Modification
test. Identical iptables rules from Phase 2 regarding the
NFQUEUE are required as well as the inclusion of the library
libnetfilter_queue within the code. Phase 3 introduces the
utilization of Stegnet.
4.3.1 Testing
The transmitting computer initiated Stegnet with the command
sh/stegnet_transmitter.sh <filename.txt> with <filename.txt>
being substituted with the name of the text file that is to be sent
covertly to the receiving computer. The receiving computer
initiated Stegnet with the command sh/stegnet_receiver.sh.
Similar to how Timeshifter was utilized in Phase 2, the
transmitting computer initiated a ping command with the
receiving computer. Differentiating from Phase 1 and Phase 2,
only one ping command was needed to be sent since Stegnet
compiled the text file as a complete string and not bit-by-bit like
Timeshifter. It was noted that one Stegnet limitation included the
capability of only being able to insert a string of 48-bytes. Due to
Stegnet being only transient phase towards higher-level packet
content modification, no variables other than sending a .txt file
were modified. Therefore, testing parameters were standardized
and simply yielded only a successful or unsuccessful result with
no value of deviation.
4.3.2 Results
During Phase 3 testing, the receiving computer successfully
received the hidden plaintext message within the ICMP message
payload. The successful result verified that Stegnet was capable
of inserting a plaintext string into the ICMP message payload via
the ping utility. Concurrently, the successful result also verified
that Stegnet was capable of recalculating the ICMP message
checksum to maintain the integrity of the packet being sent;
allowing receipt of transmission by the receiving computer.
4.3.3 Analysis
The insertion of plaintext was still an entry-level solution to
network steganography. Possible mitigation could have included
protecting the covert information, in the event it is revealed,
through means of encryption. String fragmentation and sending of
a covert message containing several ICMP packets could also be
possible. Further testing of Stegnet was not performed since
ultimately, Stegnet performed as it was intended and revealed that
the objective of modifying transmission packets to send a covert
message is attainable.
4.4 Phase 4: Transport Layer Packet
Modification Test via BitStegNet
The following information includes the testing, results, and
analysis data for the Phase 4: Transport Layer Packet
Modification test. BitStegNet, NFQUEUE configuration (iptables
command), and the library libnetfilter_queue have been compiled
and initiated on both the transmitting and receiving computers.
Prior to executing the iptables command, existing routing tables
were flushed. Next, the sending computer processed a UDP port
8989 output rule with a queue number of 0 and the receiving
terminal processed an UDP port 8989 input rule with a queue
number of 1. Other ports could have been used and would have
only required reconfiguration of both computers’ listening ports
through qBitTorrent. These rules were necessary for the
libnetfilter_queue library to be able to capture the modified µTP
packets and send them out afterwards. Lastly, a torrent file was
added to the default location (~/Downloads) of the transmitting
computer.
4.4.1 Testing
Prior to initiating BitStegNet, the transmitting computer double-
clicked its torrent file, which added it to its qBitTorrent client and
began uploading it. This process established the transmitting
computer as a tracker. Upon completion of the torrent upload, the
transmitting computer paused the torrent through qBitTorrent.
Next, the transmitting computer initiated BitStegNet with the
command echo <message> | sh/bitstegnet_setup_transmitter.sh
with <message> being substituted with the string of text to be
covertly sent. The receiving computer initiated BitStegNet with
the command sh/bitstegnet_setup_transmitter.sh. Lastly,
qBitTorrent was run on both computers by first resuming the
torrent file on the receiving computer and then resuming the
torrent file on the transmitting computer. At this point, the
receiving computer automatically downloaded the torrent and
simultaneously received the covert message.
4.4.2 Results
During Phase 4 testing, the receiving computer successfully
downloaded the torrent from the transmitting computer (tracker)
and received the covert message. The successful result verified
that BitStegNet is capable of interpreting and manipulating the
Timestamp and Timestamp_Difference fields within the header of
µTP packets and route them across a swarm. Ultimately, the
successful results verified that BitStegNet is an effective tool at
modifying packets at a higher level protocol.
4.4.3 Analysis
The results of Phase 4 yielded remarkably positive results. The
desired function of BitStegNet as a packet content modification
tool at the Transport and Application Layers via BitTorrent was
met. It was noted that a 180-chracter string within a 1.9 MiB file
was passed from the transmitting computer to the receiving
computer almost instantly. BitTorrent, and its µTP packets, were
the ideal carrier of steganography. Detection of this
steganography medium is considered extremely low due to the
common nature of BitTorrent traffic on a network. Additionally,
detection relating to the manipulation of µTP Timestamp and
Timestamp_Difference header fields is not practical due to the
natural high-variation of microseconds. Although it was tested
within an isolated environment, it is believed that BitStegNet

7. would be as reliable on an active public network for these same
reasons.
5. CONCLUSION
This project began with a proof of concept tool called Timeshifter,
which modified the timing of ICMP packets, and concluded with
a custom developed tool called BitStegNet that modified the
content of BitTorrent packets to communicate covertly through
µTP. Between Timeshifter and BitStegNet, another custom
developed tool, called Stegnet, was demonstrated as the transition
between modifying the timing of ICMP packets at the Network
Layer via Timeshifter and modifying the content of µTP packets
at the Transport Layer via BitStegNet. Stegnet, similar to
Timeshifter, modified how ICMP packets were transmitted and
received and operated only at the Network Layer. Ultimately,
BitStegNet verified the capability to route the transmission of
concealed information across active data networks at a higher
communication layer protocol, all while maintaining a minimal
possibility of detection.
6. ACKNOWLEDGMENTS
The results of this project, and the research involved, would not
have been made possible if it were not for the assistance of several
individuals. We would like to thank Dawid Broda for making
available our test network platform, Donald Nelson and David
Stacey for guiding us along the way and providing exceptional
advice, and Bill Lidinsky for facilitating our project from
beginning to end. Lastly, we would like to thank the Illinois
Institute of Technology and its Rice Campus for letting us use its
Forensic Security Lab and other associated facilities during the
Fall 2015 and Spring 2016 semesters.
7. REFERENCES
[1] Anfractuosity. 2015. Timeshifter: Transmissions of data
through time based covert channels across a network.
Retrieved October 2, 2015 from
https://www.anfractuosity.com/projects/timeshifter/.
[2] Hoffman, C. 2013. HTG Explains: How does BitTorrent
work? Retrieved March 29, 2016 from
http://www.howtogeek.com/141257/htg-explains-how-does-
bittorrent-work/.
[3] Kopiczko, P., Mazurczyk, W., and Szczypiorski, K. 2013.
StegTorrent: a Steganographic Method for the P2P File
Sharing Service. DOI: 10.1109/SPW.2013.11.
[4] Rowland, C. 1996. Covert channel file transfer for Linux.
Retrieved February 19, 2016 from http://www-
scf.usc.edu/~csci530l/downloads/covert_tcp.c.
[5] Szczypiorski, K. HICCUPS: Hidden Communication System
for Corrupted Networks. Warsaw University of Technology,
Institute of Telecommunications. ul. Nowowiejska 15/19, 00-
665. Warsaw, Poland.
[6] Welte, H., and Ayuso, P. N. 2014. The netfilter.org
“libnetfilter_queue” project. Retrieved October 11, 2015
from
http://netfilter.org/projects/libnetfilter_queue/index.html.