Let me try to explain to you how these packets work, and if you have understood this, there it shouldn't be hard for you to build your bot.
An online game has to communicate with a server, it does so via
. There are two types of sockets, Streaming sockets (which use TCP) and Packet/Datagram Sockets (using UDP) (technically theres also the option to implement your own protocol on top of IP raw, but I think no game is actually going for this).
A streaming socket treats the communication as a stream of data, meaning if you send something over this socket, it will always be received (i.e. retried on failure until it gets through) and it will arrive in the same order as it is sent. In order to do this a lot of control information has to be tracked, and with a high error probability the effective round trip time (i.e. the time from sending the data until you get the info your peer has received it) is going up. This is bad for most games, as they require low latency, but can often cope with loss of data (Not that there aren't any games that use streams, but most don't).
The other options is to use UDP, which is based on datagrams. The idea being, rather than sending a continous stream, you send discrete packets. If a packet arrives it will be correct (i.e. error detection), but you have absolutely no guarantees that the packet will arrive at the target, or that it will arrive at a certain time.
Due to it's flexible and lightwight nature most games use UDP, but you have to find out what your game uses. If it uses TCP than, in order to manipulate the stream, you need to be able to access all the information of the stream. As the data in the stream uses sequence numbers, if you send a packet that the game doesn't know about, the following sequence numbers will be out of sync, which could lead to funny side effect (i.e. acknowledging the next packet before it is sent), but mostly will break your connection (at least if you are doing it more often). Therefore to avoid this you need to use a proxy, which has it's own stream with the target server, as well as a stream to the game, so you can insert packets in your outgoing stream, without breaking the games stream. (Of course you also need to forward the packets send by the game)
With UDP this is much easier, as the protocol doesn't make any guarantees on when a packet comes, it also doesn't have any control structures that can be broken when sending additional packages. So with udp you can basically just send out your data, without breaking anything.
But by default most operating systems don't just let you create a new UDP socket on the same port as an exsisting UDP socket. So you have basically two possibilities, 1. Spoof your destination port, or 2. Write a proxy as you would for using TCP.
While the first option is by far more fun, the second option is easier, more flexible and overall better.
PS: I've just found out, you can even reuse the same socket for multiple processes on Windows and Linux (
) for TCP and UDP, which could work as long as you just want to send data. But if you want to also be able to read packets, you need to write a proxy
