Luigi Auriemma

I was how you would capture packets going outbound/inbound, read them, modify them, and finish sending.

Anything I find on google is just about monitoring outbound/inbound packets.

I have some example code that you can find probably enough useful, but at the moment the only one I remember is the code of lfscbof and soldatdos:

http://mirror.aluigi.org/poc/lfscbof.zip
http://mirror.aluigi.org/poc/soldatdos.zip

in the code you can find a function called miniproxy which does all the job but implements both TCP and UDP data so you must remove the TCP part before (the sockets used by UDP are sdu and sdul and the first SENDTO is used to connect the udp socket to the server).

Anyway usually when I want to modify UDP packets quickly I write a mini plugin for sudppipe like I did for the proof-of-concept of call of duty:

http://aluigi.org/mytoolz.htm#sudppipe
http://mirror.aluigi.org/poc/cod4statz_sudp.zip

Hope this helps

So what you do is bind the destination IP and port? So when it gets sent it actually gets send to the proxy. Then the proxy handles it and sends it to the destination?

in short there I have used two sockets, one which binds the local port and so handles all the incoming packets from the "client", and the other which instead handles the packets from the "server" to which you connect.

In reality is also possible to use only one socket and then handle the packets through their source IP address, probably this solution is more elegant (avoids to send the first empty packet to the server) but requires a better handling of the source informations in the packets.

in attachment there is the smallest UDP proxy I can write which uses only one socket.
you must only place your "modification code" before the sendto calls

Ok thanks.

I kinda don't get it?

Does using Bind make all data on that port direct to that socket instead of were it would normally go?

the bind() instruction gets a socket and assigns a local port to it, so if you bind the port 1234 other clients can connect to that port of your system and communicating with that socket.

So in that udpproxy tool I create the socket, bind it to the local port and then I tell the program to receive data from it.

Note that I use that peeru structure for receiving the data so I can keep the latest client's IP-port saved in peerl:

- peer is the structure of the server
- peerl is the structure of the client
- peeru is the temporary structure when you receive packets

the first packet you will receive is the one of the client so in the program I compare the IP/port of the peeru with peer (the server) and if it's the same means that I have received the packet from the server and so I need to send it to the client I have in memory (peerl) and then viceversa if peeru differs from peer.

In case you need to test the proxy quickly open 3 consoles:

proxy: udpproxy 127.0.0.1 1234 12345
server: nc -l -p 1234 -v -v -n -u
client: nc 127.0.0.1 12345 -v -v -n -u

Well what is confusing me is what stops the packet from just going past the proxy? Like with a packet monitor it goes.



so the monitoring program has no effect on the packet.

How does the packet go with the proxy?

Like this?

If thats how it goes why does the packet go to the Proxy program instead of just straight to the server. Does Bind cause that?

yes:

client -> proxy -> server

and viceversa for the reply

Is that because of Binding the socket?

ehmm... it's the job of proxies getting packets from one side and putting them to the other :)

Well like does Bind cause all outbound/inbound packets on that port to go to the proxy?

Also how would you do this with tcp?

bind() is the function needed to assign the local port to the proxy, it's a required function otherwise you can't connect to the proxy


with tcp this is a bit longer since you can't use one single socket as in the udpproxy example.
I don't have simple examples at the moment.

I am guessing you would, wait for a connection, add its socket to a list, loop through the list receiving and sending?

in short you need at least 3 sockets to use:
- a socket for bind+listen
- another one for accept
- another one for connect

and you must use select for knowing when one of the last two receive data.

this is what to do for supporting one client, if you want to support multiple clients it's enough to use a thread for each socket created by accept() and then handling the select() in the new thread.
It's also possible to make all threadless but all it's up to you.

ok, thanks for all the help.

Hmm I can't get TCP working.

I Bind a socket to address any, listen and try to accept but it never picks up the connection when I try to connect to something through the binded port.

Although lfscbof did the same thing.

I have updated the micro udp proxy attached to this thread since a friend of mine (Katz) saw that after some minutes the "if(len < 0) break;" terminated the program

Well I tried making my own.

Its all proxy programs dont seem to work on my computer.

So does this only proxy remote connections?

I can't get it to receive local packets.

a proxy can work with any IP, 127.0.0.1 too

the examples you gave don't work for me 0,o. They never receive any data.

maybe im missing something here, but how exactly you wanna recieve local packets ???
it has nothing to do with proxy, but when i wanna capture my local packets using commview, i have to open special adapter (127.0.0.1 - local ip). it doesn't exist in connections, but commview 6.x versions shows it as capture adapter. ..see what im saying ?!

I have tried ipany and localhost

a proxy and commview work on 2 completely different layers: socket the first and low level/raw the second one.