Lat Trick Bot

[AHB]

@iL

So I have setup a test environment to start the proof of concept. The first problems I am seeing:

1. My game host is listening on 6112. However, if I make an outbound connection to player 2, I dont know how to obtain the NAT translated port that was opened for that connection this can be solved using a STUN client and connecting to a free STUN server which will give me my external port and external IP. Here is a python library I am working with for this https://github.com/jtriley/pystun
2. Say that I figure out somehow that the outbound port opened to player 2 is port 49222, now how do I get that response traffic to go back to 6112 ... solve this by binding to port 6112 in the UDP python script


here is simple python code to send from each machine to open that connection between them (if we can figure out the above)

import socket

target_host = "1.1.1.1"
target_port = 6112

# create a socket object
client = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
client.bind(('0.0.0.0', 6112))

# send some data
client.sendto("AAABBBCCC",(target_host, target_port))

print "Done!"

[AHB]

This is the best summary of the problem that I have found yet http://resources.infosecinstitute.com/udp-hole-punching

[AHB]

Here is the code to get NAT info that we need using STUN:

First install pystun with pip install pystun, then:


import stun
interface = "0.0.0.0" # interface to listen on (all)
port = 6112 # port to listen on
nat_type, external_ip, external_port = stun.get_ip_info(interface, port)
print nat_type
print external_ip
print external_port

This will return:
Symmetric NAT
1.1.1.1
30738

[AHB]

Updated Design:

1. Client A wants to host a game but is behind NAT without port forward
2. Client A's War2Combat sends an HTTP GET to war2.ru to grab a list of all player external IPs and ports
3. Client A's War2Combat runs a script to get STUN info -> their nat_type, external_ip, external_port
4. Client A's War2Combat sends an HTTP POST to war.2ru sending its external_ip and external_port and war2.ru server receives this and adds it to the list in #2
5. Client A sends periodic UDP traffic to the ext_ip and ext_port of all other players
6. All other players send periodic traffic to the ext_ip and ext_port of Client A

[ TODO: Somehow client A needs to update PvPGN letting other war2 clients to know to join games using its external port identified in #3, if this occurs in the port setting of war2, my idea is that steps 1-6 take place before even launching war2, then war2 is launched binded to the ext_port discovered?

This is the biggest challenge right now
]

7. Now that Client A has connections opened to all other players, he is able to host and anyone can join



Update .. this STUN idea doesn't work for symetric NAT, which creates a different port mapping for every new connection. Getting a hell of an education on NAT right now, man this is harder than I thought it would be https://networkengineering.stackexchange.com/questions/7781/why-stun-doesnt-work-with-symmetric-nat

[Igognito]

Nice work AHB...

by the way, the \lattrick I was suggesting would do for all other users.
Thus the host does not need to know who will join the game, all users will be able to host.

It is just that I'm triggering it only for the one that is hosting.
Also theoretically you could first host the game and then do \lattrick when someone cant join.

We could modify the message that u receive that no one can join your game: to do: \lattrick

:-P

anyhow, I'm very busy these days until the 20th.

[iL]

Updated Design:

did you try that yourself? It is working for you?

Somehow client A needs to update PvPGN letting other war2 clients to know to join games using its external port identified in #3, if this occurs in the port setting of war2

Well, at least pvpgn knows everything about ports in realtime, also pvpgn shares that info to other parts of project, so there should not be a problem to request that info every moment we need.

Another question: if you host the game (war2 listening UDP on 6112 or w/e port) and then your script tries to bind/send something to that port on the same host. Will that work or returns error like "port is busy"?

this STUN idea doesn't work for symetric NAT

Not a big problem as for me. Maybe i'm wrong, but as understand, symmetric NAT is very rare thing. Even if such hole punching will not cover that several % of clients, other will be happy to have it working.

5. Client A sends periodic UDP traffic to the ext_ip and ext_port of all other players
6. All other players send periodic traffic to the ext_ip and ext_port of Client A

Do we really need both 5 and 6? As i understand, 5 is enough to let others connect to game hosted by client A.
I mean, P.6 requires started lat trick bot on all clients. But would be better if we require lat trick bot only on clients behind NAT.
Why i should start lat trick bot on my computer if my ports are open!

Another problem is potential vulnerability: we have to discover everyones' ip addresses to everyone. Now you can discover someone's ip only if he hosts the game or joins the game (tell me if i'm wrong).

[iL]

Also theoretically you could first host the game and then do \lattrick when someone cant join.

Yes, that was my idea: I'd attach \lattrick instead of that message "your port is closed..." Then it will work automatically and only for clients and at the moment when it's really needed.

What i see as the 1-st step: to try that any way, at least like that python scripts, make sure it works, realise the required timeouts and other technical moments. Then we could think what our next step will be.
I also very busy permanently, so if someone test this, that would be great.

[iL]

Well, installed python under windows on my side, checked by stun via random stun server, got  Nat type: Restric NAT, my real external ip and some kind of port.
Next step: i know my game data port, it's 6112.
My plan, and i need someone's help to test:
1. i start war2 with no uPNP, make sure port is closed
2. you try to join, get error
3. you give me your ip and game data port (most likely 6112)
4. i try udp_client.py or my own script with client.bind to your ip and your port
5. you try to join again.

If i understand steps properly, it should let you join my game.

[AHB]

Hi @iL

A couple things that you said:

1 - Is it a vulnerability to expose IPs?

Well no I dont think it is a problem, you already get everyones IP when you join a game with them, the only difference is now you can get everyones IP without joining a game

2 - Symmetric NAT is rare

I didnt know, I have a pfSense firewall. I will try a new firewall with another type of NAT and see if I can defeat that

3 - Step 5/6 - why do all other players need to respond to UDP?

They don't, I was just imagining a world where no one port forwards anymore and we all host games using the new NAT hosting fix

4 - Will your udp_client.py script work as you said?

No, I dont think so, the problem is that port 6112 isn't going to be opened, 49123 or something like that will be opened publicly and translated to 6112 on the LAN. Your friend will try to join <your-external-ip>:6112 and it will be closed... we have to somehow let PvPGN know to tell other players to join on <your-external-ip>:49123

Possibly this is a Symmetric NAT thing though and maybe your router will rewrite <internal-ip>:6112 -> <external-ip>:6112, in which case I think youd be good


more reading http://www.think-like-a-computer.com/2011/09/16/types-of-nat/

[iL]

2 - Symmetric NAT is rare

I didnt know, I have a pfSense firewall. I will try a new firewall with another type of NAT and see if I can defeat that

Something like pf on -BSD systems? Maybe symmetric NAT implemented there by default, i don't know, but it's quite possible. Also some small/medium business uses such type of NAT. We should try.
I meant small hardware home routers all-in-one, as i understand, most of them uses other types of NAT.

Anyways, if we start that UDP hole punching thing we should check how many people uses symmetric NAT or other types.

I have an idea: i'll just try to host the game and then send UDP to server:6112. If i will NOT get a message (port is closed), that means hole punching works fine.

Possibly this is a Symmetric NAT thing though and maybe your router will rewrite <internal-ip>:6112 -> <external-ip>:6112, in which case I think youd be good

Definitely it is. Symmetric NAT is the only type changes outgoing port. At least all other types try to do everything to translate outgoing 6112 to 6112 when NATing.

They don't, I was just imagining a world where no one port forwards anymore and we all host games using the new NAT hosting fix

As i understood, the concept is to do everything to forward existing ports. We should use hole punching ONLY if other ways are not possible.

[Igognito]

1 - Is it a vulnerability to expose IPs?

Well no I dont think it is a problem, you already get everyones IP when you join a game with them, the only difference is now you can get everyones IP without joining a game

Yes it is a vulnerability. Generally, having someone's ip you can try to do several nasty stuff.
Some are easy, others require technical knowledge which probably nobody in this community has.

I would suggest that we encrypt the ips for safety. Our encryption doesn't need to be something special. Just a XOR filter with a random series of numbers. Enough, for the casual malicious user to not be able to get the ip.

The pro hackers, probably wont target us. In general we just need to be protected by DOS attacks etc.

Yes, that was my idea: I'd attach \lattrick instead of that message "your port is closed..." Then it will work automatically and only for clients and at the moment when it's really needed.

You mean to hook it automatically? Run the command to the server and send the data to the client?
That is okay, just keep the message as is so that people that do not have the lattrick utility to know to install it.

maybe using something like this can tell us exactly what happens when we do the lat trick:
https://www.pcwdld.com/best-network-monitoring-tools-and-software

Cheerios

[Delete mine too]

1 - Is it a vulnerability to expose IPs?

Well no I dont think it is a problem, you already get everyones IP when you join a game with them, the only difference is now you can get everyones IP without joining a game

Yes it is a vulnerability. Generally, having someone's ip you can try to do several nasty stuff.
Some are easy, others require technical knowledge which probably nobody in this community has.

I would suggest that we encrypt the ips for safety. Our encryption doesn't need to be something special. Just a XOR filter with a random series of numbers. Enough, for the casual malicious user to not be able to get the ip.

The pro hackers, probably wont target us. In general we just need to be protected by DOS attacks etc.

Yes, that was my idea: I'd attach \lattrick instead of that message "your port is closed..." Then it will work automatically and only for clients and at the moment when it's really needed.

You mean to hook it automatically? Run the command to the server and send the data to the client?
That is okay, just keep the message as is so that people that do not have the lattrick utility to know to install it.

maybe using something like this can tell us exactly what happens when we do the lat trick:
https://www.pcwdld.com/best-network-monitoring-tools-and-software

Cheerios

No point in encrypting the IP address... anyone can sniff it while hosting or joining a game.

[iL]

No point in encrypting the IP address... anyone can sniff it while hosting or joining a game.

Not for those who just idle in chat with no games playing.

BTW, if you join the game, can anybody get your ip not being joined to that game?

[AHB]

@iL @tupac

Tupac is right, there is no point @iL, no, currently regular users cant get IP of players while idle/chat (admins can with /conn I believe)

But theres a million ways to get people's IP address (play a game with them, get them to click a link in your profile etc), knowing which is not a security issue itself.

Even AES256 encrypted IPs would never be secure because the CLIENT has to decrypt it, so the decryption key is sitting in the binary easily extractable by the user who wants to find out the IPs. Its like doing password checking in javascript (the web user can change to do whatever he wants), you just never do security things in client side code because it would just be a waste of your time.

[Igognito]

Hosting/joining should only expose ip among Host/Joiner.

Don't really know how war2 handles this. But when u join a game I guess your ip is exposed to the host and vice versa.
Also your ip might be exposed to the other players that joined, but technically speaking that might not be necessary. But desirable in case the host drops.

Having a command that exposes all channel's ips is something different.
One could write a utility to use that command and launch a DOS attack against each single ip.
Or even better attempt to take remote control of each single PC behind. While 90% of those would be protected a malicious person might find one open...
And suddenly your PC is at the hands of someone...

Quantity is important here. This is the reason why Blizzard and others hid the ip addresses.
For mass attacks not single directed ones.

At the time of Kali, we would do several form of attacks against other players. Exactly, because we could see the ip.
So I would say it is advisable to protect that...

Is it crucial? Well in most cases people in the community wont bother to look up for it, thus I would say it is not crucial and having a simple strategy should be enough.