Welcome!

Join our community of MMO enthusiasts and game developers! By registering, you'll gain access to discussions on the latest developments in MMO server files and collaborate with like-minded individuals. Join us today and unlock the potential of MMO server development!

Join Today!

[C++] "C++ by Example" - XTunnel

Ginger by design.
Loyal Member
Joined
Feb 15, 2007
Messages
2,340
Reaction score
653
So the project I'm going to start working on is essentially a TCP/IP tunnel.

The first step in developing the project is providing a purpose, a means to achieving that purpose, and then laying out exactly how this can be accomplished. Sitting down in front of a compiler and coding then compiling and adding features along the way rarely has positive results aside from speed. The opposite is also mistakenly considered a positive avenue. Sitting down and planning out every little trivial detail through multiple passes is a horrible idea, and should only be considered when the job is simply so large that it must be broken up into parts for a team where you need each interface completely designed so that work can proceed. Even in these situations it's a poor system, and that may be because it mimics the least efficient parallel algorithms humans have invented; we're simply naive in how to truly develop a project in parallel, but attempting to perform such a task deemed necessary for parallelization alone is only adding extra unneeded burden, slowing down the overall process.

So with that said, let's begin with the problem.


The need for a tunnel is self explanatory. It's well summed up by the introduction of RFC 1928 (SOCKS 5):

The use of network firewalls, systems that effectively isolate an organizations internal network structure from an exterior network, such as the INTERNET is becoming increasingly popular. These firewall systems typically act as application-layer gateways between networks, usually offering controlled TELNET, FTP, and SMTP access. With the emergence of more sophisticated application layer protocols designed to facilitate global information discovery, there exists a need to provide a general framework for these protocols to transparently and securely traverse a firewall.

Perhaps this hasn't happened to you but it's a situation which is becoming more and more common, and more and more treacherous. You're sitting in class one day on a computer you've paid to use, on a network as a student your tuition grants you access up to the limits of some AUP in place for legal purposes (after all, your school is technically an ISP to you). You want to connect a program you wrote to your home PC, or you want to RDP into your home computer to check on something, or some other benign task that involves the machine you're working on connecting to another machine, via "the internet". But what's this? You find your connection fails? After a quick telnet session or other debugging technique, you find that connections on certain ports are being blocked! What's the cause? Well of course, anyone with a little networking knowledge instantly knows the answer: that damn firewall. Some dupe in a position with a title "system administrator" or "network analyst" or something similar which is horribly inaccurate decides that an over-zealous "deny first, allow later" approach is an appropriate measure to "secure" a network which has no real intrinsic danger to the outside world. In turn, you realize the machine you're sitting at has a corporate antivirus, is re-imaged every semester, and has the most recent version of DeepFreeze installed, what could this idiot possibly believe would go wrong that such zeal should be applied to filtering outgoing traffic? So you have to do something silly like change your RDP port on your home PC or server to 80 so that you can access it.

But in doing this, you realize.. wow.. just changing the port gets around this $3500 device and the hours this idiot likely spent figuring out IOS and setting it up, reading his little guides online and book because he's almost certainly not certified to do this type of work. That's because it's not shaping traffic, as some hardware really can toss out traffic over port 80 that isn't HTTP (that will be addressed MUCH later as a project to anyone who cares to implement a circumvention, and believe you me, it is quite easy to do).

Or say you're at a LAN sponsored by someone, but the guy(s)/girl(s) who set up the network also decided the deny-first/never-unblock-common-ports-later approach was in some way appropriate, and now you can't telnet to your server, you can't RDP out, hell, you can't even connect steam to get updates or to go to offline mode. Again, the need is clear.

The SOCKS 5 protocol is intended for a user agent to connect, request access by providing an interest in destination and what address a connection from will be accepted. It generally is only supported by software that is compiled with SOCKS capable wrappers around networking API. This is a huge drawback from which this project will not suffer (yay! :thumbup:).

This connection is simply "hi, can I .. um get a connection to IP <ip_here> from this address <ip_here> on port <port_here> ?", to which the application implementing SOCKS provides a response and then binds to that port a listener that will pass through the traffic as requested, allowing circumvention of a firewall. This is a very broad swing of an axe. This is called a PROXY, as it really only bypasses restrictions from firewalls which specifically block data from specific hosts, and if you ask the SOCKS server to open a common port that should NEVER be blocked on a firewall (because it would kill the internet or a lot of other things, like port 80), it effectively bypasses simple port filtering.

But what about programs we want to redirect who's source code we don't have access to? Well what we want to do is tunnel connections through a single port. We want to be able to have everything we want connect to our tunnel on a specific port, and for our tunnel system to be intelligent enough (along with some special sauce thrown in) to be able to properly handle all of the traffic and route it out to the correct destinations. Then we can at-will (given we have sufficient permissions, or through a clever method of redirection that doesn't require permission elevation) force our web browser to go through our tunnel, completely circumventing a local firewall with what could amount to seconds of work! That's a lofty, but achievable goal. :drool:


So the purpose:
Bypassing firewalls. Specifically, we wish to write a tunneling system to bypass them.

The means:
We will write a server daemon that will implement an extension and amendment of the . Specifically, it must be able to perform the common proxy tasks, but also more advanced tunneling techniques and be modular, extensible, and scalable. We can easily imagine a single tunnel daemon being responsible for redirecting LOTS of traffic, possibly from hundreds of simultaneous connections.

The first step to achieving this goal will be to establish the exact functionality the project needs, along with the base protocol (which may be extended later on for unforeseen features we need). Once this and all modules have been produced, we can begin working towards completing the modules and producing a working product that works as expected.

This project will cover networking in windows, primarily asynchronous networking using IOCP. It will also be multithreaded to provide scalability and efficiency (we don't want our tunnel being the bottleneck or adding a lot of latency to connections due to slow throughput!). In addition, it will cover lots of tricks, techniques, and so forth in both areas. But it's not limited to this; there is nothing stopping you from porting the code to linux, unix, or osx, since epoll & kqueue operate very similarly to IOCP, and pthreads provide every bit of capability we need for the project.

The next post towards this project will contain the first step, the exact functionality required, the base protocol needed, and a list of the modules required to make this work. You shall find this won't be a simple project so it'll be a long time in the making and will grow to completion in stages on this board.
 
Last edited by a moderator:
Ginger by design.
Loyal Member
Joined
Feb 15, 2007
Messages
2,340
Reaction score
653
Re: C++ by Example - XTunnel

Gonna reserve this for the next post.

But I'd like to point out that this isn't only useful in bypassing firewalls. Its real strength lies in moving data through a controlled checkpoint. The part that's interesting is that YOU get control of that checkpoint.

So where it could be applied to emulator development or developing nefarious tools for games is in packet shaping. The tool we end up with will be easily modifiable to allow for plugins added as "filters" through which all data in connections defined by parameters they request are filtered. Then you can apply any number of packet dumping techniques (general ones) and voila, you have something which can allow you to sniff packets for *ANY* game and control their flow.

Combine that with TCP/IP stack fun and we can actually tunnel transparently anything and if we recognize the connection is from a game that we know, it can sniff packets or some other wizardry (launch a UI that allows interactive packet manipulation and logging?). Cool for a hands-free always-available tool, and the extensibility is unlimited. You can even write your own firewall :p.
 
Experienced Elementalist
Joined
Oct 1, 2007
Messages
210
Reaction score
26
This is brilliant, I love the idea, how's your progress?
 
Back
Top