EES Gateway 1.1

EES Gateway 1.1 by RaGe
-----------------------


New Feature for 1.1:
--------------------

Well, I was trying to determine whether or not to implement this functionality in the
first build and decided against it as it might be confusing. However after the inital
release I weighed the increased flexibility gained by adding it and decided that its
worth adding. So 1.1 has one new clientside implementation addition.

The ability to bind app-side sockets to a particular address. 

Ok, why is this important? Well, imagine that your reverse admin client is running on
a machine different from the system controlling the Main Gateway Client. By forcing
the app-side socket to bind to a specific IP address, you can now connect to reverse
admin tools running on any IP, not just the default loopback address! Even internet IPs.

In addition to binding your client app-sockets (reverse connection) to addresses of your
choosing, you can also bind your server app-sockets (forward connection) as well. So this
way, instead of having your forward connection based app always local (default loopback),
you can connect your apps from a remote location by binding the listening app-socket to
your internet ip.

Enjoy ;P

Side Note: Gateway 1.0 servers will not be editable with the 1.1 editor, due to a
modification of the server configuration to fix the 4 byte allotment for the sin port.
Its now 5 bytes as it should have been in the first place. Thanks to Digerati for 
pointing that out. However, the 1.0 servers are identical to 1.1 servers in functionality
so you can use either Gateway clients (1.0 or 1.1) to control any Gateway servers. That
basically means that the feature I just mentioned will work on old servers, as the new
feature is a completely client side modification.

-----------------------------------------------------------------------------------------


A little about EES Gateway and why it exists:

EES Gateway is a project aimed in response to the lack of anonymity inherent to reverse
connecting tools. This tool itself is in fact reverse connecting as well however using
it will allow you to decide where you want to control your RATs from. This tool acts as
a middleman for connections between an admin and his/her user. EES Gateway allows any
TCP based connection to be middleman'd in a sense as you can also realize forward based
connections as well as backward connections. In short, its a customizable socks/proxy
where you can tailor connections to your needs.


Installation:
-------------

The built in editor gives control over how your gateway server is configured with normal
options for installation including common registry methods and a newer method as well.
        

How it works:
-------------

Each Gateway server allows for "Gates" to be created, which allow for a connection of
type specified by the user. For example, Gate 0 (the first gate) created with settings:

outgoing ip:    your intended connection (ie: www.google.com or its IP)
outgoing port:  server port (for default webserver would be 80)
incoming port:  incoming communications port (aka 6767 for our first gate)
listen port:    your local port for your client (ie: 6001)
                Note: in this example we're using a browser to interface with our intended
                outgoing ip. You would point your browser to 127.0.0.1:6001 in this case.

Creating this Gate would make Gate 0 connect to google and relay google to your browser
via your local interface APP side using port
(6001).

You can also create Gates for managing reverse connections with reverse connecting tools.
To create such a Gate, check the Reverse Server checkbox and configure as needed. ex config:

outgoing ip:   NULL as its reverse connecting
outgoing port: server listen port. Set to whatever your reverse tool port is (ie: 5120)
incoming port: incoming communications port (aka 6768) Note: Use unique ports
connect port:  port you want to use to connect to your reverse tool's client with
               (ie 5120 or something else)

Creating this Gate would make Gate X listen for incoming connections from your reverse
tool and once connected, would start sending data to your reverse client app using port
Please Note that as there is no way to determine which Gate is ready for which client
at any given time, you will receive a notification that a change of remote STATE has
occured, so you can check the Gate status using the Retrieve Status button to tell if
the Gateway has received any new connections or has been disconnected from a host.

Gate Control:
-------------

Because Gates are redirecter sockets, you may need to disconnect a remote connect or
listen attempt thats taking too long etc. You may also need to disconnect or connect a
local app connection attempt as well. All the controls to do as such are on the
Main Gateway window. Using these to sync your connections will allow you to make your
connections work in the way you need them to. 


Known Issues:
-------------

Disconnecting from a Gateway server to say, connect to another etc causes an issue
I've come across due to incremental socket creation clientside. The many gateway servers
you might have will not have any problems, they will function as always. Its the client
that needs to maintain every socket created for every Gate in a Gateway, and by disconnecting
from a Gateway WITHOUT REMOVING ALL CREATED GATES will cause the Client to "forget" all
inside socket management pertaining to the newly disconnected Gate.

Basically what this means is that it WILL work, however if you come BACK to a Gateway
that already has Gates assigned to it when you connect to it the client will have NO idea
how to interact with those sockets. It will continue to function, however you cannot
use the Main Gateway window controls to manipulate them without error. For more depth
on why this is, refer to the Gateway Dev Logs included. 

The reason the client does NOT force you to remove all Gates when disconnecting is because
perhaps you wont WANT to go back and mess with them, you just want them to work while your
no longer connected to that particular Gateway so you can manage others for example. For
those interested in doing so, I've left that ability there as long as they are aware of
the problem of ever going back to that Gateway to manipulate it without first destroying
created Gates.

The concept of going back to a Gateway with gates already assigned to it, WELL after you've
lost the interface AND functionality by closing the client and re-opening it is called
a Dirty Gateway. Its gates are called Dirty Gates. If this is the case, and your client
has started up fresh (no gates are being redirected) then it will detect these Gates
and allow you to remove them via Remove Gate or Disconnect. 

EES CREW