..-----------------------------..
..      Phoenix net proto      ..
.._____________________________..


  1.1  wtf?
  1.2    about warez

  2.1  protocol overview
  2.2    transport level
  2.3    how it works?
  2.4    features

  3.1  bugz and sux


 __     __
 __ 1.1 __   wtf?


   This technique was invented,  when one member of  ds had finded a  post
   about icw5  rebirth  in  some forum.  There also was  a url  to project
   SP0ofed LAN utility (spolan.sourceforge.com) by DarkK.  This idea seems
   to be very useful,  but imho it's  not so rationally  to pack  whole ip
   packets into transport-level's icmp or udp/dns packet, coz MTU (Maximal
   Transmission Unit) and other shit'll occures on this way.  Well, that's
   why we start development of new protocol, but with tiny  particularity:
   this writed specially for moscow isp MTU-intel.  In  a  few days we had
   done it and start debug.


 __     __
 __ 1.2 __   about warez


   Warez, which we wrote (./includez/freewaybbs_1.4/),  should work on any
   unix-like os with little-endian arch and bsd sockets system.  There are
   some bugs, but it works )).


 __     __
 __ 2.1 __   protocol overview


   Protocol's main requirements, which we used on development:

       - economical traffic usage

       - stability, cuz guest session limit - 10 minutes.  Network  has to
         be dynamically linked on any peer's hangup.

       - primary network usage: chatting and file transfering.

       - prog should work on any linux and *BSD.


 __     __
 __ 2.2 __   transport level


   By default, we use reverse icmp-tunnel as transport-level,  coz we have
   no time to debug also reverse dns-tunnel =) You can do it, if you wish.
   Anyway,  we  can  pass icmp packets  (dns also sure)  between  hosts in
   subnet, like it's imaged on this scheme:

            .=---> GATE (i.e. 195.34.32.26) --->=.
           ./"                                  "\.
          ./"                                    "\.
         ./" 192.168.10.1                         "\. 192.168.10.7

  out packet:                                    in packet:

  ip_src: 192.168.10.7                          ip_src: 195.34.32.26
  ip_dst: 195.34.32.26                          ip_dst: 192.168.10.7
  ip_proto: icmp                                ip_proto: icmp
  ...data....                                   ...data...


   On the transport-level basement, we developed some hi-level proto, more
   optimized then oxid in his article "transfering data via icmp",and sure
   faster). We called it phoenix_net. Now, take a look at packets headers:

  // phoenix_net header (based on icmp):


  0           8          16                   32
  +-----------+-----------+---------------------+       ICMP header
  i icmp_type i icmp_code i        chksum       i
  +-----------+-----------+----------+----------+
  i    src    i    uid    i    cmd   i   arg    i
  +-----------+-----------+----------+----------+

   And structure for it:

     // to use via ICMP_ECHO
    struct phoenix_proto {

      char type[1];  // icmp_type
      char code[1];  // icmp_code
      short  chksum;
      char  src[1];  // source addr
      char  uid[1];  // user id
      char  cmd[1];  // command
      char  arg[1];  // argument

    };


  // phoenix_net header vol.2 (based on udp+dns):

  0         8        16              32
  +---------+---------+-------+--------+       UDP header
  i   cmd   i   arg   i    dst_port    i
  +---------+---------+----------------+
  i      length       i    check sum   i
  +-------------------+----------------+

  +---------+---------+----------------+       DNS header
  i   src   i   uid   i      zeroed    i
  +---------+---------+----------------+
  i      htons(1)     i      zeroed    i
  +-------------------+----------------+
  i     zeroed        i      zeroed    i
  +---------+---------+----------------+
  i datalen i our MAD DATA!! ......... i
  +---------+-----------------+--------+
  i ......................... i  zero  i
  +-------------------+-------+--------+
  i     htons(1)      i   htons(1)     i
  +-------------------+----------------+

     // to use via DNS
    struct phoenix_proto {

      char cmd[1];    // 0x00 udp_src
      char arg[1];    // 0x01 udp_src
      short dst_port; // 53
      short len;
      short chksum;
      char src[1];    // 0x00 dns_id
      char uid[1];    // 0x01 dns_id
      short junk;   // this flags must be 0 in requests
      short qd_cnt; // == 1
      short an_cnt; // == 0
      short ns_cnt; // == 0
      short ar_cnt; // == 0
      char datalen[1];  // datalen
    };

   And end of dns-packet:

     char[1];   // == 0
     short a1;  // htons(1)
     short a2;  // htons(1)

   Now, some comments to phonix_proto fields:

  src (8 bits)  -  last octet of src_host's ip
  uid (8 bits)  -  sender's uid
  cmd (8 bits)  -  command index
  arg (8 bits)  -  command argument (if need)

   Here defined main commands:

  // server-side cmdz

  #define   SERV_MESG     0
  #define   SERV_PING     1
  #define   SERV_CON      2
  #define   SERV_FUCK     3
  #define   SERV_WHOZ     4
  #define   SERV_DATA     5
  #define   SERV_FILE     6

  // client-side cmdz

  #define   SERV_JOIN    16
  #define   SERV_PART    17
  #define   SERV_ERR     20
  #define   SERV_OK      21
  #define   SERV_BAK     22
  #define   SERV_PRP     23

  // SERV_ERR argz:

  #define   UPLOAD_DENY   1
  #define   UPLOAD_BUSY   2
  #define   UPLOAD_FLER   3
  #define   UPLOAD_DONE   4


 __     __
 __ 2.3 __   how it works?


   Okay, let's begin...

* here  and  below  when i say "source address" i mean nor ip,  just  last
 octet, coz we got only one subnet class C.

   1. First user  dials to MTU,  and starts  freeway.  Prog  sends  packet
      SERV_CON to all hosts in subnet 192.168.10.x.

   2. Coz there is no primary server at the moment, first client goes into
      server  mode  (here  main  plus  of  peer-2-peer  networks  -  their
      flexibility).

   3. Now, for example, to MTU connects as guest another one jedi. He also
      starts freeway.

   4. Our server (aka first client) accepts his SERV_CON packet,and checks
      is registered a secondary server?  In this case no,  so server sends
      packet  SERV_BAK,  with argument,  equal ph->src of  request packet.
      Also,  server inserts  client's address in struct usr_list in  field
      with index == ph->uid (look users_tab.h).

   5. Client got reply  packet SERV_BAK with  own source addr in  argument
      field.  That means,  what on primary server's hangup  all  client'll
      reconnect to him.

   6. Now to MTU connects third hax0r. He also starts freeway and it scans
      subnet with SERV_CON packets.

   7. Server accepts his packet,then checks is this uid in usr_list struct
      used? If it's already used,it sends to client packet SERV_ERR. Else,
      it sends packet  SERV_OK with  argument equal source addr of  backup
      server (aka first client). Then, to other registered users  it sends
      packet SERV_JOIN with arg equal ph->uid (client's uid).

   8. When any client writes message, freeway packs it to packet SERV_MESG
      and sends to primary server.  Server displays it on own terminal and
      redirects it to all registered clients, except mesg author.  To mesg
      author server sends packet SERV_OK as confirmation.

   9. Other clients accepts message SERV_MESG and dispalys message text.

  10. If any client sends to server  packet SERV_WHOZ, server sends to him
      list of registered users in this order:

      0        8       16  bits
      +--------+--------+
      i  uid1  i  src1  i
      +--------+--------+
      i  uid2  i  src2  i
      +--------+--------+
      i  uid3  i  src3  i
      +--------+--------+
      ...


  11. If any client sends packet SERV_PING, server has to reply on it with
      packet SERV_OK.


  12. If  any  client  quits (command  "/quit"), his  client sends  packet
      SERV_FUCK. Then server'll accept it, it removes from usr_list struct
      record with this uid.To other clients server sends packets SERV_PART
      with argument, equal ph->uid.



   On main server's hangup:

   1. All  clients,  who had sended packets SERV_MESG or SERV_PING,  waits
      for a timeout,sends to backup (aka secondary) server packet SERV_PRP
      (aka server_prepare) and connects to it.

   2. Well,  when backup server gets packet  SERV_PPR it goes into  server
      mode. Now it's repeats cycle 1-12, discussed above.



   How works file-transfer:

   1. First  client  (sender) gets  receiver's source  address by  request
      SERV_WHOZ.

   2. Then he sends to receiver packet SERV_FILE.

   3. Receiver replys on it by packets SERV_FILE or SERV_ERR with argument
      UPLOAD_DENY in that case, is he accept to get file?

   4. Then sender gets packet SERV_FILE from receiver, reads  from  traget
      file blocks with size  MAX_FILE_SEGMENT (in bytes) and  sends it  to
      receiver in packets SERV_DATA.

   5. So, receiver reads from packet SERV_DATA payload and adds to  target
      file.

   6. Then upload is done, sender sends to receiver packet  SERV_ERR  with
      argument UPLOAD_DONE.After it recevier ignores all SERV_DATA packets
      until new download.


 __     __
 __ 2.4 __   features


   Well, there are a lot of ideas, how to use phoenix_proto,  but we don't
   care about it. In fact, it  was just nice  experiment.  Mess in icw5 is
   better, coz it's more safe,  and sure session longer on 5 mins ;P  Ppl,
   who'll debug dns-tunneling will  be able to use freeway  in many isp'z,
   i.e. icw5, ROL, Comstar,  and many-many-many others.  But  we let it to
   icw5-community =)


 __     __
 __ 3.1 __   bugz and sux


   Hmm.. really,  we don't care about any security issues of protocol  and
   client software, coz, as i told above,  it was just experiment.


