COMP8045 - Project Report v.1.3

Encrypted Covert
Channel on
Mobile Devices
COMP8045 - Project Report
BCIT BTech Program:
Network Security
Administration Option
Soon Zoo Kwon
(James Kwon)

1
Table of Contents
EXECUTIVE SUMMARY ................................................................................................................................... 2
PROJECT BACKGROUND ................................................................................................................................ 4
PROBLEM STATEMENT.................................................................................................................................. 6
PROJECT OBJECTIVE....................................................................................................................................... 7
TECHNICAL DETAILS ..................................................................................................................................... 8
PROJECT PROCESS..........................................................................................................................................11
DATA STRUCTURE DESIGN ..........................................................................................................................12
SYSTEM ANALYSIS AND DESIGN – UML DIAGRAMS ...............................................................................14
PROJECT ACHIEVEMENT ............................................................................................................................ 25
IMPORTANT FINDINGS ................................................................................................................................ 28
INNOVATIONS ................................................................................................................................................ 29
FUTURE ENHANCEMENTS ......................................................................................................................... 30
UNACHIEVED PROJECT GOALS.................................................................................................................. 32
VULNERABILITY ANALYSIS OF PACKET FORGERY............................................................................... 33
TEST RESULT .................................................................................................................................................. 39
CONCLUSION.................................................................................................................................................. 43
REFERENCES .................................................................................................................................................. 44
APPENDICES.................................................................................................................................................... 45

2
Executive Summary
The main objective of this project is to implement encrypted covert channels on mobile devices
using secrete data camouflage in a UDP packet. While the implementation of the software on
mobile devices and a server, the project compares the packet networking and cryptographic
software developing environment of each mobile platform and the development frameworks for
UDP packet communication. In addition, the mobile apps and the server programming
techniques are applied to each packet level mobile framework.
In the end, this project will apply packet level network programming skills which have been
taught through the CST BTech program at BCIT.
Functionalities implemented
In order to complete the objectives of this project, the following functionalities are to be
integrated into the client module and the server module.
 Data encryption and decryption using cryptographic algorithms such as RSA (Rivest-
Shamir-Adleman cryptosystem) and AES (Advanced Encryption Standard).
 Design and implement a covert channel using forged packets between client mobile
devices and a server host.
 Splitting and hiding encrypted data bytes into a covert channel using forged DNS
packets.
 Background worker process mechanism to send the encrypted bytes secretly on mobile
devices.
 Acknowledgement mechanism of UDP packet transmission between client mobile
devices and a server module.
 Reassembling on server the data being received in the form of numerous packets with
each packet containing very small piece of the data.
 Real-time packet forgery and forwarding of the DNS query along with the DNS
response.

3
Figure 1 Encrypted Covert Channel using Mobile Phone
Development Methodology
This project adopts a model-driven software development methodology for design and agile
software development methodology to implement the server application. The exploration of this
project has two paths of software development:
1) Client mobile apps for three different mobile platforms are developed from a PIM
(Platform Independent Model) to the implementation of multiple PSMs (Platform
Specific Model) based on the PIM. To design the models, this project adopts rapid agile
methodology with UML (Unified Modeling Language).
2) Server application based on Windows platform is also developed using agile
methodology.

4
Project Background
As we know, mobile device technology varies across the mobile platforms. Each mobile
platform has different development environments that are updated on a regular basis. The
market share of the mobile device platforms is rapidly increasing. This project is primarily a
mobile covert channel using simple and fast packet encryption on various mobile platforms such
as Android, iOS, and Windows Phone. Packet encryption on laptops or desktops is very well
known with their cryptographic libraries; however, packet cryptography on mobile devices has
several limits to implement because mobile devices have limited resources such as CPU
performance, network speed, and memory. Nowadays, mobile communication using wireless
network is rapidly expanding. More and more apps on the mobile platforms require critical data
communication. Mobile banking and mobile financing markets are soaring, but mobile network
providers don’t guarantee network security. This project implements a customized Point-to-
Point Encryption (P2PE) to be used for the security purposes.
On the other hand, the customized Point-to-Point Encryption through a covert channel might
be needed for special purposes in specific fields. This project has implemented a covert channel
adopting this mobile packet cryptography.
Covert channel is a type of computer software attack that allows the communication of
information by secretly transferring data through existing information channels or networks. It
uses the structure of the existing medium to transmit the data in small parts. This technique
makes data transfer through a covert channel virtually undetectable by administrators or users.
Covert channels have been used to steal data from highly secure systems.
Covert channel can pass the undetected payload through most firewalls and IDS (Intrusion
Detection System) hiding its data in a packet header or payload. It camouflages its data as a part
of an ordinary packet header or a packet body so that packets pass most firewalls and IDSs.
However, it is possible for covert channels to be detected by an intelligent IDS or highly skilled
network administrators even though it can hide the data in Sequence number or ACK
(Acknowledge) of TCP/IP header reserved field or use a tool. The encrypted covert channel can
prevent extracting the encrypted payload in any case. This technique can be applied to both TCP
and UDP packets. This project implements a covert channel using the UDP protocol.
Covert channel is created by using some of the space available either within the padding or
within other parts of a network packet. Covert channels use any means where data can be added
to a data stream without affecting the main body of data being transmitted. This allows the
covert receiver to abstract data from a system without creating any type of data trail. A single

5
packet might only contain one or two bytes of the covert data stream, making it difficult to
detect the unauthorized transmission.
Creating a covert channel takes some ingenious programming. Having access to the file system
at the source end of the communication is also essential. This means that a covert channel can
only be instigated by infecting system with a malicious program or through a programming
effort that has administrative or other authorized access to the system.
Covert channel analysis is one of the few ways to detect a covert channel. System performance
degradation can be used to show covert channel use, but as computers have advanced, the
degradation is insignificant compared to the amount of data processed. This makes detection
more difficult. The primary way of defending against covert channel attacks is to examine the
source code running on the source machine, as well as monitor resource use by the system in
question.
This data encryption is also useful to transmit packets through a covert channel on mobile
devices because the encrypted packets of the covert channel could not be suspicious even if the
forged packets were caught by IDS. This makes the covert channel detection be almost
impossible. Therefore, this project develops methods to detect the forged and encrypted covert
channel though studying the packet communication.

6
Problem statement
Packet communication on computer network is easily detected by network experts or spoofed
by hackers using advanced tools. Even covert channel delivering secret data can be detected and
even stolen. To avoid a detection of IDS or network administrators, a more advanced solution is
needed to hide and deliver secret data so that even the forged packets are caught avoiding
suspicion by network administrators.
This solution will require techniques such as collecting and decrypting the encrypted data from
DNS question query packets and how to reassemble the original camouflaged data at the
receive-side server host. These skills are needed to hide secret data into regular DNS question
and response of UDP packets after the data is encrypted.
On the other hand, defenders do not have a method to detect the forged DNS packets on
encrypted covert channel. Especially, network administrators who will need an advanced method
to detect and to block suspicious and forged packet communication.

7
Project Objective
The objective of this project is to deliver a running software using encrypted covert channel on
mobile devices and a server program including the achievements, lessons learned from failures,
and important findings during this project. In addition, the knowledge of CST BTech program
such as UML modeling, SDLC (Software Development Life Cycle), is applied to build the
software. The encrypted covert channel has three major functional requirements
The first functional requirement is that packets should be encrypted by RSA or AES
cryptography. This project focuses on RSA which uses two different keys at once - a
combination of a private key and a public key. The private key is known only to a device, while
the public key is given to any device or system that wants to communicate securely with it. To
decode an encrypted message, a device must use the public key, provided by the originating
device, and its own private key. Although a message sent from one device to another won't be
secure since the public key used for encryption is published and available to anyone, anyone who
picks it up can't read it without the private key. The key pair is based on prime numbers
(numbers that only have divisors of itself and one, such as 2, 3, 5, 7, 11 and so on) of long
length. This makes the system extremely secure, because there is essentially an infinite number of
prime numbers available, meaning there are nearly infinite possibilities for keys.
The second functional requirement is that the encrypted data should be hidden or camouflaged
in a part of the header or its payload which is designated by the covert channel server to avoid
any doubts when the packets are caught, the packet payloads are designed using very ordinary
DNS packets with a “standard domain name query” requesting IP addresses of well-known
websites. Thus, the covert channel server can extract the camouflaged and encrypted data from
the designated offset of the header or the payload.
The final functional requirement is that the client mobile device should control the transmission
interval to avoid suspicions of IDSs and network administrators. The packet transmission of
covert channel should be controlled with irregular or regular interval. The best method to avoid
a doubt from IDS or network administration is that the mobile device checks the packet traffic
in a Wi-Fi zone and sends its encrypted covert packets during peak time.

8
Technical Details
As described earlier, covert channel is one of the effective methods to transmit secret data using
ordinary packets. Not only a network attacker but also a network security defender, covert
channel could be an option for secure packet transmission because the forged packets of covert
channel are hidden critical data into ordinary packet such as DNS (Domain Name System)
question or ICMP (Internet Control Message Protocol). However, the hidden secret data could
be collected if it is detected and found by IDS or network administrators.
Therefore, to cover the weakness of covert channel, to make it harder to see the data being
transmitted over covert channel. Consequently, the encrypted covert channel can hide critical
data using encryption algorithm and deliver using seemingly ordinary packet format without any
suspicions of IDS and network administrators.
However, for an attacker, UDP packet communication is a challenging programming because
DNS request and response packets of UDP are connectionless packet transmission which means
the socket does not guarantee the packets reach to a receive-side server host and there is no
acknowledge signal for a sending-side client host.
Therefore, this project has implemented the following two critical techniques:
 Each encrypted covert packet should have an index number of the packet in its body
and the sequence number should have maximum 4 byte length. This 4 bytes can make
maximum 65535 index numbers which is enough to send large data.
 The sending host should get back a DNS response packet with the acknowledge bytes of
a DNS response packet.
The server which is a receiver collecting forged DNS queries should return DNS response
packets to the sender, or should forward the DNS response packets in the middle of the two
hosts, the sender and a real DNS. This is similar to a delegation between low-level DNS and
high-level DNS server. When a DNS server doesn't have the contents of a zone, but knows how
to find the owner, it's said to delegate service of that zone to another DNS server. Informally,
it's a pass-the-buck mechanism. This project develops a forwarding module with a real-time
forging technique of the response packets returned from a well-known the Global Top Level
Domain (GTLD) such as Google DNS server.
It is a very well-known fact that DNS request and response UDP packets can easily pass through
IDS and firewalls in any case because the packets are used frequently and regularly to access

9
websites. This is the reason why this project has chosen DNS request and response packets as
forged UDP packets to implement encrypted covert channel.
This project has used the following core technique to implement the client and server module.
 Cryptography ( Encryption and Decryption using RSA or AES algorithm)
 Real-time Packet Forgery ( UDP packet, DNS query and response )
 Parity Check Byte ( similar to parity check bit, but it is for acknowledge packet from the
server)
 DNS query forwarding and real-time camouflage the DNS response packet
Three ways for packet camouflage
The main technique to implement a covert channel is UDP packet camouflage. The following
are three methods to achieve this technique:
1. IP Header camouflage
a. There are two different versions of IP headers which have been defined, IPv4
and IPv6.
b. This project adopts only IPv4 because of a camouflage issue of IPv6.
c. IPv4 Header consists of 13 fields and the final field “Option” can be modified by
socket methods in a raw packet library of Windows Phone and iOS platform.
2. UDP Header camouflage
a. It consists of four fields, source port, destination port, length and checksum. The
four fields are 4 bytes each. Source and destination ports are predefined by their
UDP socket. Therefore, port camouflage is not possible. Most well-known UDP
server ports are located under 1023 port. Length field is the number of bytes in
entire datagram including header. The three fields are used for correct
transmissions between hosts. However, the Checksum field is used to check the
payload parity check bytes.
3. UDP payload camouflage
a. UDP payload varies by the application protocol such as DHCP, DNS, or RIP
(Routing Information Protocol).
b. This project chooses DNS request and response headers because they are often
used in any case of the Internet access, especially, web browsing.
Unfortunately, it is found the fact that Android an iPhone platform doesn’t allow a raw socket
transmission unlike Windows Phone platform. Therefore, this project adopts the UDP payload
camouflage to implement.

10
Software modeling
This project adopts model-driven architecture approach for design and implement the
client modules.
Figure 2Model-driven approach - PIM and PSM
The model-driven architecture approach defines system functionality using a platform-
independent model using an appropriate domain-specific language (DSL). The PIM of this
project consists of six main UML diagrams such as Usecase, Sequence, Statechart, Activity,
Deployment, and Class diagram. The PIM is translated to the multiple platform-specific models
that mobile devices can be implemented. This requires mappings and transformations and
should be modeled too. The PSMs consist of Sequence, Deployment, and Class diagram for
each platform.
Through the PSMs, source codes are concretely designed for each mobile apps on each
platform. For instance, Java class diagram with specific methods are designed for Android
platform, Object-C class diagram with specific methods are designed for iOS 8, and C# class
diagram with specific methods are designed for Windows phone platform. The each source code
is implemented by the PSMs then.

11
Project Process
This project has been conducted since January, 2015 and took 8 months to finish and submit
the report. During the duration, this project has faced a lot of barriers and failures such as
obtaining device, applying the network and cryptographic API libraries of the platforms, and
setting up the development environments. Especially, the network and cryptographic API
libraries are very different on each platform even though the cryptographic algorithms are
same. In addition, the Appstore of Apple company requires a developer license to connect
an iPhone with the development tool, X-Code. They also do not allow debugging of a
mobile app on the iPhone device without the provisioning.
The detail process and the Gantt chart are attached on the appendices.
1. Researching and studying the mobile platforms and their network APIs
2. Analysis of the prototype for Android
3. Designing Data structure
4. Designing PIM( Platform Independent Model) using UML
5. Designing PSM( Platform Specific Model) using UML
6. Designing User Interface of mobile devices and server
7. Setting up the developing environment
8. Prototyping
9. Designing and Programming
10. Testing and Debugging
11. Documentation and Final Report

12
Data Structure Design
This project designs the data structure to be applied on the mobile apps.
 Target File (Any file type)
o The target file to send through the encrypted covert channel.
 Unencrypted Data (byte array)
o In-memory byte array data from the target file to be encrypted
 Encrypted Data(byte array)
o In-memory byte array data from unencrypted data by any cipher algorithms
 Decrypted Data(byte array)
o In-memory byte array data from encrypted data by any cipher algorithms
 DNS question query list ( Hexadecimal )
o Packet payload of DNS request for query various websites
o To generate forged DNS request packet, mobile devices read the list file and
insert encrypted data and its index number into packet header or payload.
Figure 3 DNSRequestQueryList.txt
 Forged DNS query (UDP packet)
o Made by mobile devices (clients) from the randomly selected forged DNS
request in the forged DNS request list.
 Forged DNS response (UDP packet)
o Made in real-time by the target server using the real DNS response packet.
 RSA key pair - private and public keys(Binary or XML)
e235010000010000000000000377777706676f6f676c650263610000010001
d3120100000100000000000003777777057961686f6f03636f6d0000010001
a4f701000001000000000000037777770766697265666f7803636f6d0000010001
992a010000010000000000000232370e636c69656e742d6368616e6e656c06676f6f676c6503636f6d0001
70d2010000010000000000000777696e646f777308706f6c6963696573046c697665036e657400001c0001
a66f01000001000000000000037777770362626302636f02756b0000010001
2532010000010000000000000773657276696365096d6178796d69736572036e65740000010001
7f3001000001000000000000056963686566046262636902636f02756b0000010001
ff9601000001000000000000037777770362626303636f6d0000010001
4a3f01000001000000000000056e6f64653106626263696d6702636f02756b0000010001
6bb7010000010000000000000473686f700362626303636f6d0000010001
b7e7010000010000000000000273610362626302636f02756b0000010001
9452010000010000000000000470696e6709636861727462656174036e65740000010001
d0ab0100000100000000000002676f096d6963726f736f667403636f6d0000010001
2100010000010000000000000377777703636e6e03636f6d0000010001

13
o Pre-generated and encoded binary byte data file or XML file to be used for RSA
algorithm by the server and installed into mobile device module (public key) and
the server module (private key).
Figure 4 public.key.xml
Figure 5private.key.xml
 AES(Advanced Encryption Standard) key (string)
o Pre-generated a simple string data to be used for AES algorithm and installed
into mobile device module and the server module.
o The same strings are used to encrypt by the sender and to decrypt by the receiver
both.
o The length of the string does not matter because it is pointless if the string is
more than 100 bytes.
<RSAKeyValue>
<Modulus>gPWPquMFSu7XcBBZC9ulml3ifNpPe3RB4gcnH5ZBdNKxlm+Bza96ZsIWoQIcjdSl3mxDyqz
xxKFLSHPKuHZOzckhRuqOv+A6bvgS5KPXlFlwtQ491H7qhutMVMEsIBzXlecMK2b7beVirPRcuiNFkPQm+iDTOL
FrKd3TivcxHec= </Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
<RSAKeyValue>
<Modulus>gPWPquMFSu7XcBBZC9ulml3ifNpPe3RB4gcnH5ZBdNKxlm+Bza96ZsIWoQIcjdSl3mxDyq
zxxKFLSHPKuHZOzckhRuqOv+A6bvgS5KPXlFlwtQ491H7qhutMVMEsIBzXlecMK2b7beVirPRcuiNFkPQm+iDT
OLFrKd3TivcxHec=</Modulus>
<Exponent>AQAB</Exponent>
<P>ucjt4wW1baoPE5XVx6iMr0XonIXL4oedQL4/zl5yZVd8GGCQ+DzwUZnQeqo66lvtHIrBE9kmGYkd
tx34zgyP0w==</P>
<Q>sbKh4jCLwUGqxqmooHmFsH3jFuuCCWYQb0YMrg2hnWiU7Srzq/gSVZDOj6COFXPqX5riT6bXfkwD
++/nc9cBHQ==</Q>
<DP>k7gUlfb7C+g0tqDjay40NkTCsHmd5E9qFIlw2Fi2YqfN7uARRJ/HgUpovq/NynwvKwuUe4CkT5d
7fhchtku8qw==</DP>
<DQ>G77xqfi8iaNwP+7TxqLS7hjp8XU6a69FF6rPZgn41zQyNMoFHC/y5OtkZWbDaLQdv2nWtmstsKm
74YW3FQ5YPQ==</DQ>
<InverseQ>XQjfWmxsuGU8UbhX6cIITZBoHnoRtjMWlI48ZcyPh9nZo9k+wPfPL12BYA05EjQ7Yg4e5
wRtjF3KtmjiBnB+hQ==</InverseQ>
<D>VPNupL/QKMCVovjh7/HNcZcPL/gQC99V1zOnDiPJEtAItHTYKUrDcxXAGmhtrvC6I39mWQj8au9l
zGCa1lD5L58xHyi21x6uHpl7PQlwVCLJSR/LQ4tojSGEHg5MBKzbeWmjejcsxlDCVEgxcYxObNMk7qLhRTlhoB
etBvtQDuE=</D>
</RSAKeyValue>

14
System Analysis and Design – UML Diagrams
Through the analysis of encrypted covert channel usage, there are two types of users are defined
– sender and receiver. The followings are analysis and design diagrams using UML.
Analysis – Use case Diagram
A mobile device as a sender module consists of four use cases and target server consists of five
use cases based on the above scenario.
Figure 6Analysis – Use case Diagram
Basic scenario
If a sender chooses a file to send, then main Usecase includes a file reader module and an
encryption module.
Receiver side host waits the transmissions from a sender side host then receives the encrypted
packets. After receiving, the server extracts and collects the encrypted data, then decrypts the
data. Finally, the data is saved to a file.

15
Analysis – Activity Diagram
Activity Diagram shows the detail process of the mobile device and the target server.
Figure 7Analysis – Activity Diagram

16
Analysis – Sequence Diagram for Mobile Device (Platform Independent Model)
Mobile device module consists of three major modules:
 Encrypted Covert Channel Client: the main module to combine other module and to
make a forged DNS packets.
 Cipher module: includes encryption and decryption methods
 Socket UDP Packet Library: packet transmission API of a platform library
Figure 8Analysis – Sequence Diagram for Mobile Device (Platform Independent Model)

17
Analysis - Sequence Diagram for Android (Platform Specific Model)
Android platform specific model is designed based on the Platform Independent Model of
mobile device module.
 Encrypted Covert Channel Client: MainAcitivity contains the most of all the functions of
the PIM.
 Cipher module: includes encryption and decryption methods using Android API.
 Socket UDP Packet Library: packet transmission API of a platform library
Figure 9Analysis - Sequence Diagram for Android (Platform Specific Model)

18
Analysis - Sequence Diagram for Windows Phone (Platform Specific Model)
Figure 10Analysis - Sequence Diagram for Windows Phone (Platform Specific Model)
Analysis - Sequence Diagram for the Server (Platform Independent Model)
Figure 11Analysis - Sequence Diagram for the Server (Platform Independent Model)

19
Analysis - Sequence Diagram for Server (Platform Specific Model)
Figure 12Analysis - Sequence Diagram for Server (Platform Specific Model)
Analysis – State Chart Diagram
State Chart Diagram shows asynchronous communication between the mobile device and the
target server. When the mobile device is ready to send, the target server is waiting for the first
initial packet from the mobile device.
When the mobile device starts sending forged DNS question query packets to the target server,
the target server receives the packets then it sends response packets to the mobile devices. This
circular state continues until there is no more packets to send from the mobile device.

20
Design – Deployment Diagram
Deployment Diagram shows four nodes which are consisted of the system. Internal firewall is
between the mobile device and the target server opening DNS port 53. The internal firewall
could be a mobile firewall of each platform or an intranet firewall. Top-level DNS server is for
responding real DNS response packets.
Figure 13Design – Deployment Diagram

21
Design – Class Diagram for Android
During the design process, Exception Handler class is added to handle the exceptions and error
of classes. Most of the functions are located in the MainActivity1 class and only Crypto1 class
includes the encryption and decryption methods.
Figure 14Design – Class Diagram for Android

22
Design – Class Diagram for Windows Phone
Encrypted Covert Channel on Windows Phone platform consists of five classes. MainPage and
Crypto Classes are same as Android version; however, Protocol Class contains the all raw IPv4
and IPv6 Protocol Header format. In addition, FileReader Class reads the data files. Creating a
socket client and sending and receiving packet classes is separated from the MainPage Class
unlike Android version.
Figure 15Design – Class Diagram for Windows Phone

23
Design – Class Diagram for iPhone
Figure 16 Class Diagram for iPhone

24
Design – Class Diagram for the Server on Windows
The server module is designed for Windows Platform to be implemented. It consists of six
classes.
Figure 17 Design – Class Diagram for the Server on Windows

25
Project Achievement
 Micro-Byte level packet manipulation
o This project has brought very useful experiences of micro level packet handling.
Especially, inserting encrypted data into ordinary IP header, UDP header and
UDP payload is the most critical programming because each mobile platform
and its library is very sensitive validation of the packets which pass through the
mobile networking modules.
o Unfortunately, there are not many explanations on the mobile platform APIs and
books about the packet validation.
o Therefore, the failures in this project have formed the lessons learned by
experience.
 Forging DNS query and response packets
o Making DNS query on mobile devices is one of critical problems because it
should be randomized and automatically generated by the module.
o This project makes a DNS query list file which contains DNS request query and
randomly fetches for each hexadecimal data of them.
o After fetching a hexadecimal data, forging logic inserts two following important
byte data: the first data is one byte size of encrypted data to be transmitted to the
server module, and the second one is 4 byte size of index number of the
encrypted data byte in the encrypted data array.
 Encryption and Decryption on mobile platforms
o RSA (Rivest-Shamir-Adleman cryptosystem) and AES (Advanced Encryption
Standard) algorithms are very well-known cryptographic algorithms; however,
each mobile platform adopts different implementations and APIs.
o For instance, Android platform using Java programming language adopts and
supports binary and XML key pair (pubic key and private key) both, while
Windows Phone only supports string based XML key pair.
o This project applies both, but AES algorithm with string based XML key pair has
given “invalid padding property value exception” on Windows platform when
Android client module sends encrypted bytes.
o The cause was the encrypted bytes are different between Java API and Windows
API.
o Therefore, this project applies RSA algorithms to implement both sides of the
client and server module cryptography.

26
 Real-time UDP packet forgery
o As it is mentioned, an important factor of UDP packet communication is a
connectionless transmission model with a minimum of protocol mechanism
unlike TCP. It doesn’t have a handshaking dialogues, and no guarantee of
delivery, ordering, or duplicate protection. It has checksums for data integrity.
o Because DNS packet communication is the most believable and unsuspicious
method to pass through firewall systems and IDS, this project chooses DNS
query and response packets which are UDP application protocol.
o However, the DNS packets should be transmitted asynchronously.
o This project uses a forged DNS server to fabricate the DNS response packet in
real-time.
o Following simple process describes the real-time UDP packet fabrication on the
target server.
 Acknowledge technique using connectionless packet transmissions.
o There is an IP identification field and DNS Query ID field to check the packet
delivery without loss; however, encrypted covert channel requires another
acknowledge methods to confirm safe delivery. Using the DNS request and
response packets does not guarantee it. Therefore, this project covers the issues
of no guarantee of delivery.
1. Receive a forged DNS query packet from a client module of a test
mobile device.
2. Fetch the specific camouflage bytes of the packets to reassemble an
encrypted data.
3. Keep the socket with the source port number of the sender client
module.
4. Forward the camouflage DNS packet to a well-known the Global
Top Level Domain (GTLD) DNS server such as Google DNS
server. ( IP address : 8.8.8.8 or 8.8.4.4 )
5. Wait and receive the DNS response packet from the top-level DNS
server.
6. Insert an index byte and parity check bytes to be used as a guarantee
of delivery and ordering of the whole encrypted packets in real-time.
7. Forward the camouflage packet to the client module of test mobile
device using the socket and the source port number which are kept at
step 3.

27
o Each DNS query packet delivers a specific value using reserved bytes such as
encrypted packet index number, and expects the value in the DNS response
packet from the forged DNS server module.
o A function in the client module of mobile device compares the two values and
decides to resend or decides to send next packet.
o However, to avoid a suspicion of IDS, the two values of DNS request and
response can be different during the acknowledge process. To implement the
acknowledge technique, it requires a simple f(x) = y formula to compare the two
acknowledge values. For instance, if the client sends x value, then the server
returns y value using the simple f(x) = y formula.
 Background worker process technique on mobile devices.
o During the forged DNS packet transmission process technique of the client apps
on mobile devices, the program allows that users can send the process to the
back of a touch screen.
o This background worker process technique supports the secret transmissions on
the mobile devices without intervention of a user.
o However, it also allows a user to stop the background process by touching the
“Cancel” button whenever the user wants.
o This background worker process technique can be applied for many purpose of
mobile applications such as machine-to-machine communication or data
buffering.

28
Important Findings
In the beginning of this project, the deep knowledge of each mobile platform and cryptography
API were required in advance. Especially, the low-level packet networking environment of each
mobile platform was analyzed very carefully. After the research, some important facts were
found.
 Android, Windows Phone and iPhone platform don’t allow the source IP address
forgery: IP packets are not sent if the source IP address of the packet is different from a
given host IP address by DHCP (Dynamic Host Configuration Protocol) server.
 Encryption and decryption APIs of each platform are not compatible: Windows Phone
doesn’t have any API to read encoded binary RSA key pairs (public and private keys);
however, Android doesn’t support XML based RSA key pairs. Therefore, this project
generated two different types of RSA key pairs for Windows Phone and Android
Platform.
 AES Encryption and decryption API using password are similar and easily compatible.
 Android and iPhone doesn’t allow mobile app developers to forge IP packet header, but
Windows Phone OS allows it. However, native code which is a binary module of mobile
OS can make it possible, if the native code can be installed into the mobile OS. Mobile
device producers modify and customize the mobile OS installing their own module into
the native code.

29
Innovations
During this project, three innovative skills have been developed and adopted.
 Byte-level packet fabrication
o This project implements packet camouflage replacing the ordinary bytes of the
typical DNS request and response to encrypted secret bytes.
 Real-time DNS packet fabrication
o DNS response packets from a real DNS server are forged by an encrypted covert
channel server and forwarded to a client mobile device in real-time.
o Of course, there is a slight time gap between request and response transmission
comparing to a normal transmission; however, the time gap can be overcome if
the server and network environment support higher speed to minimize the time
gap.
 Methodology of forged packet detection
o Through the research of the potential vulnerabilities of DNS packets and the
forging techniques, this project develops the methods to detect forged packets.
o This may be useful to develop and to improve an advanced IDS or a firewall.

30
Future Enhancements
 IPv6 packet fabrication and camouflage
o More and more devices and hosts has already adopted IPv6. This project
implements the client and server program using IPv4 only because there was a
camouflage issue and there was not much time to adopt IPv6. However, it is
easily implemented if the PIM (Platform Independent Model) of this project is
used for extending to IPv6.
 Multi-to-multi encrypted covert channel
o This project implements only one-to-one encrypted covert channel at one time.
The server and clients could create one channel at a time. However, if multi-
thread technique is adopted, the server and clients could create multiple
encrypted covert channels.
 Byte-level packet camouflage with the packet header and payload forging can be
extended to create the securest covert channel to transmit maximum secret data. It is
suitable for small and critical packet transmission between devices and a host, or
between devices such as IoT (Internet of Things) technology.
Figure 18 Multi-to-multi encrypted covert channel

31
 On the other hand, the detection technique of encrypted covert channel is useful to
improve IDS functionalities using detection algorithms which is implemented based on
the technique of byte-level camouflage and detection.
 In addition, mobile devices upgrading their network modules can be extended to validate
and block the packets which are forged by hackers.

32
Unachieved Project Goals
 A forged DNS server on Linux platform
o To implement the server module, this project chose Linux platform at the
beginning. However, this project changes to Windows platform after comparing
the development environment between Linux and Windows.
o Server programming on Windows using Visual Studio and C# is more effective
and productive than a server programming on Linux.
o However, the program can be easily converted to other platforms because this
project designs the PIM (Platform Independent Model) to transfer the
implementation.
 Two mobile client version on Tizen and FireOS platform
o This project had a plan to implement client modules on Tizen and FireOS
platforms; however, obtaining the devices was not easy, and the development
environment of socket communication are not stable yet because the platforms
are relatively new.

33
Vulnerability analysis of packet forgery
The other goal of this project is how to detect the forged and encrypted packets using covert
channel and prove that the covert channel packets contain critical data. As a network security
defender or a hacker, this goal is more difficult than the first goal because the attacker’s spear is
too strong and the defender’s shield cannot conduct its duty. On the other hand the spear, the
encrypted covert channel does perfectly conduct its duty; therefore, the shield, IDS might not
easily conduct its duty. The only way to detect the encrypted covert channel is by analyzing each
of the packets and finding the suspicious patterns of the forged packets.
Network administrators are concerned as a defender, worry about system security such as
potential data leaking or heart bleeding through the Internet. Advanced detection techniques or
solutions are required. Encrypted covert channel is an attack that is difficult to detect because
the packet is forged to look a typical DNS request query and response. However, there is are
some ways to detect the encrypted covert channel.
During the course of this project, it is found that there are many potential vulnerabilities through
packet forgery. This chapter explains the each forgery and camouflage detection method.
IP Header forgery and camouflage detection
Figure 19 IPv4 Header Structure
o IP header contains important information of IP version, source IP, destination IP, time-to-
live, etc.
o In the structure, The Internet Header Length (IHL) (4bits), Total Length (16 bits),
Identification (16 bits), Fragment Offset (13 bits) and Header Checksum (16 bits) have
possibilities of forgery to hide and to deliver secrete data passing an IDS and a firewall.

34
Internet Header Length (IHL) – 4 bits
o Internet Header Length of IPv4 header may contain a variable number of options, this
field specifies the size of the header. It can defines a minimum of 20byte size using 5
bits (5 bit×32bits = 160 bits = 20 bytes) to a maximum of 60 byte length of 15 words
(15×32 bits) or 480 bits. All mobile platforms already have the validation mechanism for
IHL field. Socket libraries of each platform assign the IHL value when the packet is
generated automatically. However, there is a small window to forge the IHL field using
native code for each platform.
o To detect the forgery of the field, IHL should be compared to the real length of a
header.
Total Length – 16 bits
o Total Length defines the total IP datagram length in bytes. Since the header length gives
the length of header and this field gives the total length, so the length of data and its
starting point can easily be calculated using these two fields. In addition, this is a 16 bit
field and it represents length of IP datagram; therefore, the maximum size of IP
datagram is 65535 bytes. When IP fragmentation takes place over the network then
value of this field also changes. There are cases when IP datagrams are very small in
length but some data links like Ethernet pad these small frames to be of a minimum
length, 46 bytes. To know the exact length of IP header in case of Ethernet padding, this
field is very useful.
o However, total length field also has a possibility of being forged into the same as IHL.
o To detect the forgery of Total Length, it should be compared to the total length of the
IP datagram.
Identification field – 16 bits
o Identification field is used for uniquely identifying the IP datagrams. This value is
incremented every-time an IP datagram is sent from source to the destination host. This
field is used while reassembling the fragmented IP data grams. However, this field is
easily forged to hide secret data bytes because it is hard to detect if the field contains a
fake fragmented IP data gram ID to reassemble them. Therefore, the field can easily be
used to deliver a secrete data.
o In order to detect the forgery of Identification field, it is needed that the value should be
traced while the packet has the same source IP address and destination IP address;
however, it is technically impossible because IDS should keep the source IP address and
destination IP address of each packet and check the Identification field value comparing
to the previous Identification field value while the packet is passing through the IDS.
Therefore, the Identification field forgery is the hardest one to detect.

35
Fragment Offset – 12 bits
o Fragment Offset field, measured in units of eight-byte blocks (64 bits), is 13 bits long
and specifies the offset of a particular fragment relative to the beginning of the original
none-fragmented IP datagram. The first fragment has an offset of zero. This allows a
maximum offset of (213 – 1) × 8 = 65,528 bytes, which would exceed the maximum IP
packet length of 65,535 bytes with the header length included (65,528 + 20 = 65,548
bytes).
o This field has a possibility to be forged delivering secrete bytes instead of Fragment
Offset of datagram because it is hard to detect the field calculating the offset of each
packet datagram.
o To detect the field forged, IDS should trace the offsets of the each datagram for the
same source IP address and same destination IP address of each packet.
Header Checksum – 16 bits
o Header Checksum (16bits) represents a value that is calculated using an algorithm
covering all the fields in header (assuming this very field to be zero). This value is
calculated and stored in the header when IP data gram is sent from source to destination
and at the destination side this checksum is again calculated and verified against the
checksum present in the header. If the value is same then the datagram was not
corrupted else it’s assumed that datagram was received corrupted. So this field is used to
check the integrity of an IP datagram.
o However, the Header Checksum can be forged to deliver a secrete data if the source and
destination host determine the field as a covert channel field.
o To detect the Header Checksum forgery, IDS should calculate and verify against the
checksum present in the header. It is easy to calculate, but it might occur packet
transmission delay.
Options field – variable
o Options has a variable length and represents a list of options that are active for a
particular IP datagram. This is an optional field that may or may not be used. If any
option is present in the header then the first byte is represented as follows :
class number length description
0 0 – end of option list
0 1 – no operation
0 2 11 security
0 3 var. loose source routing
0 9 var. strict source routing
0 7 var. record route
0 8 4 stream id
2 4 var. INTERNET time stamp
Figure 20Options Table

36
o Options field is easily forged if the field is not used for the original purpose, and it is
hard to detect the field is forged because there are a lot of possibilities to be used.
o Only way to detect the forgery is the option number and its length should be compared
and matched.
UDP Header forgery and camouflage detection
Figure 21 UDP Header Structure
o UDP Header represents 4 default fields: Source Port (2bytes), Destination Port (16bits),
Length (16bits), and UDP Checksum (16bits); however, Java and iPhone platform do not
allow UDP packet header forgery.
o Among the fields, UDP Length (16bits) and UDP Checksum (16bits) have possibilities to be
forged and to deliver secure data bytes.
UDP Length – 16 bits
o UDP Length represents the length of UDP Header and payload data in bytes. This
means the minimum value of the length is the UDP Header size, 8 bytes and maximum
value is 65,535 bytes.
o To detect UDP Length forgery, the real length of the UDP should be compared to
UDP Length value.
UDP Checksum – 16 bits
o UDP Checksum is computed as the 16-bit one's complement of the one's complement
sum of a pseudo header of information from the IP header, the UDP header, and the
data, padded as needed with zero bytes at the end to make a multiple of two bytes. If the
checksum is cleared to zero, then it is disabled.
o UDP Checksum forgery is similar to UDP Length forgery. It is easily forged but should
be checked to see if the validation is detected.

37
UDP Payload forgery and camouflage detection
o Numerous key Internet applications use UDP, including: the Domain Name System (DNS),
where queries must be fast and only consist of a single request followed by a single reply
packet, the Simple Network Management Protocol (SNMP), the Routing Information
Protocol (RIP) and the Dynamic Host Configuration Protocol (DHCP).
o This project deals with DNS payload which consists of 14 fields.
DNS Query ID – 16 bits
o DNS Query ID is a 16bits and unique identifier created in the query packet and left
intact by the server sending the reply; it allows the server making the request to associate
the answer with the question. A DNS server might have many queries outstanding at
one time. Even multiple queries to the same server; therefore, this Query ID helps
match the answers with the awaiting questions. This is also sometimes called the
Transaction ID (TXID). This project forges the field to deliver an encrypted byte
because it is easily forged using ordinary socket API on mobile platforms and almost
impossible to detect the forgery.
o Query ID is only related a client host and a DNS server; therefore, an IDS doesn’t have
any method to detect if it is forged or not.
Figure 22 DNS query packet and Payload Structure

38
Question Record Count – 16 bits
o Question Record Count is filled by the client host in the next section with a single
"question" record that specifies what it's looking for: it includes the name (www.bcit.ca),
the type (A, NS, MX, etc.), and the class (virtually always IN=Internet). The server
repeats the question in the response packet, so the question count is almost always 1. It
is a major barrier to forge the field.
o Question Record Count forgery is easily detected by checking the value. It should be 1.
DNS Question/Answer – variable
o DNS Question/Answer data is the field that holds the question/answer data referenced
by the count fields above. This field is the most vulnerable to be forged by the client and
the DNS server host because the payloads are varied by the DNS query and the
response answer.
o There is no way to detect if the field is forged or not because there is no fixed pattern to
detect the forgery.

39
Test result
In order to test the mobile apps and the server, testing is conducted in two phases:
1. Module test is conducted in data encryption module, covert channel module and server
module.
1) Encryption module is tested on each platform
a. Encryption module on Android
b. Encryption module on Windows phone
c. Encryption module on iOS
2) The covert channel module is tested on each platform
3) Decryption server module is tested on Windows 8.
2. Integration test is conducted the developed apps with the server.
1) Integration test in Wi-Fi zone by the developer, myself, and a third party tester
2) Integration test in 3G/4G cellphone zone by the developer, myself, and a third party
tester
During the integration test, the testers conduct following steps:
1) Tester installs the developed encrypted covert channel app on each mobile device in
advance.
2) Tester works in a Wi-Fi-zone, 3G/4G and LTE zone that are distant from the
designated covert channel server.
3) Tester chooses the data file that is a normal plain text or binary/media contents (image,
sound, video) in the mobile device.
4) Tester touches the “send” button of the covert channel app.
5) The app irregularly or regularly sends the generated packets using the encryption module
to the designated covert channel server.
6) During the data transmission, an IDS and a packet capture application which is installed
in advance for the test, capture and analyze the packets.
7) The covert channel server receives the encrypted packets from the mobile devices and
extracts the encrypted data from the packets.
8) The server decrypts the extracted data and writes it to a local file.
9) The receiver opens the saved file.

40
Module Test
 Encrypted Covert Channel – Android Client
Functions Tested Comments
Installing successful Download from Playstore
Encrypting successful
File selecting successful
Packet sending on Covert Channel successful
Job canceling successful Response time 2.5 seconds
 Encrypted Covert Channel – Windows Phone Client
Installing successful Download from Windows
store
Encrypting successful
Job canceling successful Response time1.5 seconds
 Encrypted Covert Channel – Target Server on Windows Platform
Installing successful
Decrypting successful
File saving successful
Server Starting successful
Server Stopping successful
Integration Test
 WiFi – Zone Test
Encryption successful
Decryption successful

41
 3G, 4G and LTE Zone Test
Encryption successful
Decryption successful
 Packets captured
Figure 23 Captured DNS packets
The above picture shows the DNS packet transmission between the target server (IP address:
142.232.129.48) and the mobile device (IP address: 142.232.129.137). The target server forwards
the DNS queries from the mobile device to the top-level DNS server of Google (IP Address:
8.8.4.4).

42
Figure 24 Encrypted covert Channel Packet Transmission
Each set of the transmission consists of four packets:
①. Sending a DNS question query from the mobile device to the target server
②. Forwarding a DNS question query from the target server to the Google DNS server
③. Responding a DNS answer for the query from Google DNS server to the target server
④. Forwarding a DNS answer from the target server to the mobile device
In any case, the packets look ordinary DNS question query and answer packets; therefore, the
internal firewall between the mobile device and the target server lets the packets pass through.

43
Conclusion
As described earlier, Encrypted Covert Channel is the most secure method to transmit critical
data using ordinary packets. This project has implemented encrypted covert channels on mobile
devices using secrete data camouflage in UDP packets. Through the implementation of the
software on mobile devices and the server, this project conducted a comparative study of the
packet networking and cryptographic software developing environment of each mobile platform
and the development frameworks for UDP packet communication. Furthermore, the mobile
apps and the server programming techniques have been applied to each packet level mobile
framework. Consequently, this project adopts packet level software development skills which
have been taught through the CST BTech program.
Last but not least, this project recommends further actions or skills with the encrypted covert
channel attack and countermeasures against it.
For Ethical attacker or Network security software developer
To make a perfect encrypted covert channel, ethical attackers or network security software
developers can transmit the packets during the peak time of an intranet or LAN adding a
module which checks packet I/O amount. Hiding the covert packets among ordinary packets is
a good strategy that make the suspicious packets harder to detect.
Sniffing and sending a password after installing the module into a target device is another useful
way to use encrypted covert channel because a firewall would not block port 53 being used for
DNS. It could be a perfect crime.
For Defender or Network security administrator
To prevent an attack using an encrypted covert channel and to prevent critical data leaks,
network security administrators as defenders should operate a local delegation DNS server
between intranet clients and higher-level DNS server in the LAN, which means only a local
delegation DNS server could go through port 53(DNS request port). Eventually, all other client
hosts in an Intranet should query the local delegation DNS server to obtain IP addresses of
domain names. However, if attacker’s mobile devices connect to a 3G or 4G wireless
connection, the local delegation DNS server may be useless because the local delegation DNS
server influences the hosts which are accessing the DNS server in the LAN.

44
References
 Sean Petterson (2013) “Mobile Encryption Market to Hit $230 Million This Year”,
WebProNews. Retrieved from
http://www.webpronews.com/mobile-encryption-market-to-hit-230-million-this-year-
2013-10
 Vanessa Pegueros (2011) “Security of Mobile Banking and Payments,” SANS Institute.
 Jim Tanous (2012) “iSuppli Predicts Windows Phone’s Edge Over iOS by 2015”, the
MacObserver.com

45
ProjectProcessandScheduleGanttChart
Appendices

46
Screen Capture – Server Module
Screen Capture – Android version

47
Screen Capture – Windows Phone version
Screen Capture – iPhone version

COMP8045 - Project Report v.1.3

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (16)

Similar to COMP8045 - Project Report v.1.3

Similar to COMP8045 - Project Report v.1.3 (20)

COMP8045 - Project Report v.1.3