(c) 20/5/2000 codex@bogus.net

Usage
-----
    receiving host: tool-a -i <device>
    sending host: tool-b [-a <src port>] [-b <dst port>] [-s <src address>] 
                  -t <target>


Description of TOOL-A and TOOL-B. 
---------------------------------

This is basically modified code from the sessionwall-3 project (see 
http://www.phate.net for details), put to good use here.

For sane two-way communication, both TOOLs must be running (in different 
windows), but one-way communications can easily be demonstrated by running
TOOL-A on the target computer (behind an "established" access-list), and TOOL-B
on an "attacking" computer.

TOOL-A is a receiving TOOL. Run this to see TOOL packets on your network.
TOOL-B is a sending TOOL. Run this to write packets to your communications 
partner.

TOOL was written using libpcap and libnet. Kudos to the people who wrote these
libraries.


A sample TOOL packet
--------------------

This description may vary from the paper issued with this tar file. There are
numerous reasons for this, but I will ignore them for now.

A TOOL packet consists of a standard TCP/IP packet which only has the ACK flag
set. As described in my paper, this is to allow penetration through certain
Cisco access-list configurations. For more info, read the paper.

The stuff below is for my reference as much as yours, actually. Skip this if 
you are bored. Incidentally, most of the fields in the data packet aren't 
actually in use in this proof-of-concept version of the code.

Sample packet:

--  +----+-----+-----+----------------+
    | VR | HDL | TOS | 16bit tot len  | VR: 4bit, HDL: 4bit, TOS: 8bit 
    +----------------+---+------------+
I   | 16bit ident    |FLG| frag offst | FLG: 3bit, 13bit frag offset
P   +--------+-------+----------------+
    |  TTL   | PROTO | 16bit checksum | TTL: 8bit, protocol: 8bit
H   +--------+-------+----------------+
D   |       32bit source address      |
R   +----------------+----------------+
    |    32bit destination address    |
--  +----------------+----------------+
    | 16bit src port | 16bit dst port |
T   +----------------+----------------+
C   |      32bit sequence number      |
P   +---------------------------------+
    |  32bit acknowledgement number   |
H   +-----+------+-+-+-+-+-+-+--------+
D   | HDL | RSVD |U|A|P|R|S|F|  WSZE  | 4bit HDL, 6bit RSVD, 16bit WSIZE
R   +-----+------+-+-+-+-+-+-+--------+
    | 16bit checksum | 16bit urg ptr  |
--  +----------+-----+----------------+
    | 32bit TOOL protocol identifier  | (the letters "TOOL")
T   +----------------+----------------+
C   | 16bit src ID   | 16bit dst ID   |
P   +----------------+----------------+
    |      32bit source address       |
D   +---------------------------------+
A   |    32bit destination address    |
T   +---------------------------------+
A   |         64bit (reserved)        | (set to zero!)
    +---------------------------------+
    | 160 byte message                |
--  +---------------------------------+


The interesting bits are of course in the TCP DATA section. For this proof of
concept code, the TOOL data is easily identifiable by the tell-tale word
"TOOL" at the beginning of the data.

Next follows TOOL source and destination station ID. This is conceivably used
for networks where clients don't really care what IP's they are on, but
you wish to distinguish where your packets are sent from and going to. [This
is not fully thought out yet, but I am sure some idiot would want to use it
in a DoS amplifier client, for example.]

We can also encode the 32 bit real IP source and destination addresses, just
incase future versions allow for two-way communications. The reason we encode
these, is that the source address could be fake, and the destination address
doesn't need to be the machine which the TOOL-B client is running on (e.g. in
a network environment without switches).

64 bits are reserved for future use.

Lastly, there are 160 bytes of message data. 

The only fields used for this demonstration is the protocol identifier
("TOOL"), and the 160 byte message. 

-codex@bogus.net 22/05/2000

Hi to Maelstrom, Fake, and the SPIES gang.