    Copyright (c)  2007  Mark D. Collier
    Permission is granted to copy, distribute and/or modify this document
    under the terms of the GNU Free Documentation License, Version 1.2
    or any later version published by the Free Software Foundation;
    with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
    A copy of the license is included in the section entitled "GNU
    Free Documentation License".

Author: Mark D. Collier - 12/01/2006   v1.1
        Mark D. Collier - 04/26/2004   v1.0
        www.securelogix.com - mark.collier@securelogix.com
        www.hackingexposedvoip.com

This tool was produced with honorable intentions, which are:

  o To aid owners of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in their deployments.

  o To aid 3rd parties to test, audit, and uncover security vulnerabilities
    in the VoIP infrastructure of owners of said infrastructure who contract
    with or otherwise expressly approve said 3rd parties to assess said
    VoIP infrastructure.

  o To aid producers of VoIP infrastructure to test, audit, and uncover security
    vulnerabilities in the VoIP hardware/software/systems they produce.

  o For use in collective educational endeavors or use by individuals for
    their own intellectual curiosity, amusement, or aggrandizement - absent
    nefarious intent.
   
Unlawful use of this tool is strictly prohibited.

sip_rogue is a hacker tool that continues to evolve. It should not be
considered "production" code in any sense of the word. As such, short-cuts 
have been taken with respect to data synchronization and memory management.
By short-cut is often meant: "There ain't any."

You may interpret this declaration as:

      "Don't be surprised if you observe sip_rogue to segfault
       and piss memory on a a regular basis".

(i.e. USE AT YOUR OWN RISK!)

Nonetheless, sip_rogue might still offer you substantial opportunity to smirk.

sip_rogue was tested on Red Hat 9 and Red Hat Fedora Core 4 distributions.
It requires several notable libraries to be installed upon its host, among
them:

libpthread
libnet
libpcap

libjrtp (i.e. specifically version 2.8 - it's included with the sip_rogue
              distribution)
              
g711conversions (i.e. this is a library available on the www.voiphacking.com
                      webpage. The Makefile for sip_rogue presumes that the
                      g711conversions library is built and resides at
                      ../g711conversions relative to the sip_rogue Makefile)


sip_rogue supports G.711 u-law audio (rtp packets) only. The behavior
is undefined if it is presented with audio that does not comply with the
G.711 u-law codec. The G.711 u-law codec must be the first codec option
offered in a SDP message carried within a SIP message during session
negotiation. 

sip_rogue does not understand re-INVITE's pertain to an existing call.
It processes a re-INVITE as if it is were a new and distinct call. For
example, sip_rogue does not presently terminate the media stream it
is might be producing for the original session. Note that re-INVITE's
are common to the B2BUA operation of the Asterisk IP PBX when SIP
phones are provisioned in the sip.conf file as being able to exchange
RTP directly.

sip_rogue is not presently capable of producing or responding to 
authentication challenges.

sip_rogue was tested using the ser proxy/registrar (i.e. v0.9.6).

Despite the fact that much of the structure of sip_rogue remains to be
implemented, in its present form it may be used as a degenerate
rogue User Agent, a rogue Back-To-Back User Agent (B2BUA), and as a
rogue SIP Proxy/Registrar. By "degenerate" is meant that the functionality
of each personality falls far short of an IETF RFC 3261 compliant 
implementation.

If you are using the 3rd party tap capabilility, the least probability 
of a segfault occurs if you follow this sequence:

Originating the call:

1) Dial the legitimate destination
2) The legitimate destination phone and the 3rd party tap phone ring
   simultaneously
3) Answer the legitimate destination phone
4) Count two Mississippi and answer the 3rd party tap phone

Terminating the 3rd party tap:

1) Hang up the 3rd party tap phone first before the call being tapped
   terminates.
   
Audio attacks (i.e. inserting or mixing audio targeting the caller or callee)
of a call being relayed by sip_rogue) is driven by the reception of RTP packets
at sip_rogue. Suppose phone A and phone B are in a call being relayed by
sip_rogue. If you intend to insert and mix audio to target phone A, then
sip_rouge must be periodically receiving RTP packets from phone B. If phone B
has sent an RTP packet for the "silence" codec and has ceased transmission of
RTP until the microphone at phone B detects audio, then any audio attack
against phone A is suspended until RTP packets once again begin to be received
from phone B.
