     ___
   '/ _ \        Version 2.4 - Remote access and
   | | | |  redirection services with strong encryption.
   | |_| |           (c) 1999-2001 by Mixter
   '\__\_\


IMPORTANT NOTES

The default RSA bit strength is 4096. On slower systems,
you may want to decrease it (minimum is 1536 bytes) in config.h
Remember to disable WANT_LOGGING if you don't want syslog
entries. Also, keep in mind, only qd and qs from the same
compilation will work with each other, because of hard-coded
random authenticity ID's generated by mkpasswd. If using a
different client, you'll have to use the -a flag.

CHANGES

2.4

Added issl-library support and iSSL-mode options.
Changed CSA authentication to SSL-style RSA
authentication and Rijndael encryption.
Fixed Libmix compatibility problems. More bugfixes.

2.2

Tunneling version release by zer0. Incorporated changes and
win32 compatibility fixes from zer0 <z00er0@hotmail.com>.

2.0

Various security improvements, challenge authentication, small
bugs fixed, encryption works more stable now, you can select your
algorithm easier, uses libmix, better portability, rewrote servers
and clients (easier usage).

INSTALLATION

1. If you haven't got libmix v1.07 or later installed:
   cd libmix-v1.07 ; ./configure ; make

2. Optionally, edit conf.h. If you dont want daemons to use
   syslog to record status info, or a pid file for self-checking,
   make sure to undefine the values there. At the bottom of q.h, you
   can chose your favorite AES encryption algorithm.

3. Type 'make' to create a client/server set. Select a good password, and
   remember it. Each compiled version of client and server will have a unique
   authentication number (in hash.h) on each build, which you need to remember
   in case you recompile your client and use it with a server you compiled
   before.

USAGE

1. Simple usage: Upload 'qd' to the system you want to access. Type 'qd' to
   start the server (root privileges necessary). From your local machine,
   call the client with 'q -S -l 123 server.com'. Replace server.com with the
   hostname or IP your server runs on. You can chose any port for the tcp
   session to connect to that isn't used. After you finish the session
   (type 'exit'), the temporary port will be closed again.

2. Server (qd) options: QD can act as a standalone server, which means it
   listens to a port, and doesn't need to be activated via rawIP. This is
   useful 1) For using Q encryption shells without root privileges 2) For
   running Q on systems that don't permit the free use of raw sockets. This
   is unfortunately the case on some flavors of BSD (just try it) and Solaris.
   qd -p 12345         - Binds an encrypted shell to port 12345.
                         Connect with: q -l 12345 server.com
   qd -b 12345:6667:us.undernet.org - Binds an encrypted bouncer to port 12345.
                         Connects will be relayed to us.undernet.org port 6667.

3. Client (q) options:
   q -a number - Custom authentication number. See INSTALL/3. Specify the auth
                 number that the server was compiled with (in hash.h) if
                 it is different from the client's build.
   q -s port - Local source port. E.G. you can bind to port 80, if the server
               you connect to uses a firewall that only permits outgoing tcp
               packets to destination port 80.
   q -S      - Run 'qs' automatically for you, activating the server to spawn
               an encrypted shell on the selected port before you connect.
   q -t      - TRANSD mode. That means q will go into the background instead
               of acting as a client. It binds to the local source port (-s).
               Local clients connecting to that port on 127.0.0.1 will be
               relayed to the encrypted session on the server. TRANSD will
               transparently handle encryption and decryption of the traffic,
               so that any clients using plaintext sessions can connect, while
               the shell or bouncer session is still fully encrypted. Example of
               a transparent encryption bouncer (qd running on server.com):
               
       [root@Q ~]# qs -p 500 -B "irc.concentric.net 6667" server.com
       [*] request: bouncer, listening port 500, dest ip irc.concentric.net, dest port 6667
       [root@Q ~]# q -s 123 -l 500 -t server.com
       Key:
       starting translation daemon, localhost:123 -> server.com:500
       [root@Q ~]# telnet localhost 123
       Trying 127.0.0.1...
       Connected to localhost.
       NOTICE AUTH :*** Looking up your hostname...

4. RawIP Server Controller (qs) options:
   qs -C "command" server.com   - Execute remote shell commands. The
                                  command can be any line that you could
                                  type on a shell, including system programs.
   qs -p port -S server.com     - Make the server open an encrypted shell
                                  that you connect to with 'q', listening on
                                  the port specified with -p.
   qs -p port -B "relay.com dport" server.com - Make the server open an
                                            encrypted bouncer on the specified
                                            port. If you connect to it, it will
                                            relay you to dport on relay.com.
   qs -U 99 server.com    - All bouncer processes will be run under user id 99.
   qs -P /sbin/sash server.com  - All encrypted shells will now use /sbin/sash
                                   as user shell instead of the default shell.
   qs -p port -       This option specifies the destination port that
                      a shell/bouncer server will listen on.
   qs -n      -       If you specify the -n option, the server will spawn a
                      *NORMAL* shell or bouncer, running without any encryption
                      at all, so that all clients can connect. These sessions
                      are depreceated, you should use TRANSD mode instead.
   qs -i I or U or T - Chose a protocol, ICMP UDP or TCP for the RawIP
                      activation packet. Only necessary if you need to use
                      a specific protocol to bypass a firewall.
   qs -a authid      - Same usage as q (both qs and q connections use CSA).
   qs -s source ip   - Specify your source IP, else it will be random
                       (only useful to bypass routing filters and firewalls).
   qs <command> targets - qs can message an unlimited amount of targets at once.
                       You specify the target hosts/ip as the last arguments.
                       Ex.: qs -C "shutdown -r now" fbi.gov cia.gov nsa.gov
             
SECURITY STATEMENT

The Q client/server suite is designed to provide a maximum of security,
especially confidentiality and anonymity. Control packets contain double
AES encrypted data and are authenticated with an authentication token that
is not sent over the network in plaintext. The server has the ability to log
all incoming queries to syslog. Care has been taken to eliminate all
potential security holes such as buffer overflows in the programs, to
guarantee stable and secure remote access.
Client/server sessions (encrypted redirection and interactive shells) are
AES encrypted and authenticated with both authentication and a password.
The Q program suite uses CSA, a password challenging method, which
determines the password out of a secure one-way hash, and the highly
secure RSA with for establishing longer shell/bouncer sessions. Temporary,
changing strong RSA keys ensure that connections cannot be eavesdropped easily.
In earlier versions of Q, the password could theoretically be gained by
reverse engineering the server binary. In this version, an attacker would
have to reverse engineer the binary, sniff at least one session, and decrypt
the one-way hash with brute force, to actually be able to run a session.
This is inevitable, since a symmetric encryption key has to be stored
somewhere in some form. However, Q still is one of the most secure encryption
solutions available. Anyways, if possible, the qd binary should not be
readable by anyone except root, to ensure real security.


Mixter <mixter@newyorkoffice.com>
http://1337.tsx.org
