Index of /~gif/covert-channel/src
Name Last modified Size Description
Parent Directory 14-Jun-2002 12:45 -
Makefile 14-Jun-2002 11:22 1k
common/ 14-Jun-2002 11:22 -
include/ 14-Jun-2002 11:22 -
ksender/ 14-Jun-2002 11:22 -
receiver/ 14-Jun-2002 11:22 -
sender/ 14-Jun-2002 11:22 -
DEVCC: A system for embedding covert messages in TCP time stamps
COMPILING
In order to successfully compile DEVCC, you will need to have the
following installed on your system:
- Linux 2.4.9 or greater
- Header files for the kernel you have installed
- libpcap (available from www.tcpdump.org)
You may also need to modify the files receiver/Makefile and
ksender/Makefile to point at your libpcap and kernel header files if
your system has them installed in a different place from mine.
At this point, you should be able to just type "make" in the top level
directory and all of the necessary files will be compiled.
Alternatively, you can make only a portion of the tree by changing to
a sub-directory and typing make from there.
INSTALLING
After the compilation finishes you will have 3 files to install:
ksender/ksender-module.o (the sender kernel module)
receiver/disect (the reciever program)
util/sethost (a utility to specify to which ip address messages should be sent)
disect and sethost are ordinary programs that can be run in place or
copied to a directory in your path (/usr/local/bin or some such).
ksender-module.o is the sender kernel module. It can be loaded into
the kernel with a command such as:
bash# insmod ./ksender-module.o
For this to work, you must be logged in as root and in the same
directory as the file. Note that the module will attempt to send
messages any time it is insmoded (and cause the host to suffer a
significant performance hit), so you probably want to load it only
when you need it. Also, the current version of the module works by
altering an existing net device driver, so you must a) have your net
driver loaded if it is modular and b) be careful to NOT unload it
before you rmmod ksender-module.
USE
To receive a message you use the disect program. This program must be
run as root because it must examine all incoming packets. It takes 4
arguments. The first argument is the number of packets to analyze for
covert data before exiting. Since it typically takes ~1400 packets to
get each message, you will probably want to choose a nice high value
like 2000 or 3000. The second argument is the filter to apply to
incoming packets to determine if they should be analyzed for secret
data. The syntax is the same as for tcpdump. In practice, you will
almost always want something like "tcp && scr host <hostname>" where
<hostname> is the host you are expecting a message from. The third
argument is the ascii string that you wish to use as the secret key.
This string can be anything you want but must be the same string that
the sender is using. The final argument is the length of the key
string in characters.
For example, if you want to receive a message from the host
foo.bar.org using the key string "mykey" you might type:
disect 3000 "tcp && src host foo.bar.org" mykey 5
To send a message you must load the ksender-module kernel module as
described above. This module will create the file /proc/cc whose
contents are the message to be sent. This file can be read/written
and seeked normally with the caveat that it will always be 28 bytes
long. If the contents are changed, the sender will immediately begin
sending the new message on outgoing packets.
Unfortunately, this version does not support dynamically changing the
key on the sender. Thus, the key must be set at compile time by
editing the definitions of the macros KEY and KEY_LENGTH in
ksender/kdevcc.c.
By default, secret data is encoded on all outgoing packets. It is
possible to restrict secret data to a single target host by issuing an
ioctl to /proc/cc with the ip address of the target host as the
argument or by running the sethost program from the util directory
with the hostname of the target host as an argument.
KNOWN BUGS
The current implementation delays packets using a busy waiting loop.
This means that if a packet must be delayed, the cpu is locked for the
duration of the delay and no other processes may run. Thus, sending
messages is extremely bad for the health of a hosed machine. However,
empirical evidence has shown that this performance hit is tolerable if
run on a machine that rarely attempts to run highly cpu intensive
tasks.
The current implementation assumes that the Ethernet driver that it
should modify is the second driver in the kernels driver list. This
is generally true for machines with only one network interface (the
first driver is the loopback device). However, for machines with
multiple interfaces it may be necessary to modify the code of
ksender.c to select the correct net driver.