So i have been wondering if it is at all possible to mix send() and wsasend()? Meaning if i had a client that connects to a server with WSAConnect() and sends/recvs packets with WSARecv() and WSASend() would it at all be possible to use Send() to send a packet on that socket also or no?

A certain game client is using these API functions and i was wondering if i could just send a packet without using those ones to the same socket...

Can you point me in a direction to learn about this?

It sounds to me like you want to take an existing socket and inject new packets, which is significantly more difficult than you might think, and requires a huge amount of platform-specific work. (I have quite a bit of experience with writing code that injects data into existing sockets, and believe me, you don't want to try it.)


This...

Quote:Original post by lilj2005
So i have been wondering if it is at all possible to mix send() and wsasend()? Meaning if i had a client that connects to a server with WSAConnect() and sends/recvs packets with WSARecv() and WSASend() would it at all be possible to use Send() to send a packet on that socket also or no?

In general, you shouldn't be doing that or even trying. There are too many unknowns for us to describe the reasons, as ApochPiQ has mentioned. The main reason a client uses WSASend and WSARecv is to get Win32 performance benefits from overlapped operations, completion routines, or input output completion ports. If the client is using either of those two methods, you can mess something up internally and that may be impossible to track it down.

If your client is not using overlapped operations, completion routines, or input output completion ports, then the calls to WSASend and WSARecv will behave just like send/recv. However, the issue then is Winsock is not thread safe. Calling any Winsock functions in multiple threads on the same socket is undefined behavior. That means you have to execute such calls in the thread context that the client originally does, which would seemingly defeat the purpose of what you are trying to do.

So once again, using WSASend/send and WSARecv/recv is 'fine' if it were your own program since you'd know the design, but in your problem context, who knows what will happen internally.

You basically have three choices:

1. Modify the client to hook the sending routine so you can arbitrarily call that to send packets on the original socket. Assuming the data you have to send on the socket will be obtained in another thread, you will have to add in the necessary code to make the calls thread safe, which can get very messy if you do not know what you are doing, but is possible. Then, you'd hook the recv'ing code so that you have access to it and can do what you want with it. For this, if you are only interested in reading data, you can use a codecave, pipe, perhaps even a Windows message. If you are interested in writing data, then you have to use a codecave. The obvious disadvantage of this approach is you are destablizing the client, have to understand how the client works, and is not a permanent solution if the client were to change.

2. Write a proxy DLL for Winsock, a kernel level device driver, or a Winsock LSP driver so you have real time access to the data that is sent and received. This is the hardest thing to do and the most complex, but for the sake of completion, I'll mention it anyways.

3. This is my favorite and preferred method. Write your own proxy server so the client connects to the proxy and the proxy connects to the remote server. You are basically doing a local man in the middle on your own computer/connections so you will have full access to all data sent and received. In addition, you will be able to arbitrarily edit packets, drop packets, and add new packets on demand. Since everything is self contained, you do not have to destabilize the original client and muck around with the code. In addition, this approach is way more customizable than using Wireshark or that other commonly used packet sniffer program for obvious reasons of being able to customize the interpretation of the data.

If your client uses TCP, I'd suggest you go the #3 route as that is the most flexible. If you invest the time in learning how TCP works internally and get down all the odds and ends of it, you can actually create a generic reusable framework that is invaluable for trouble shooting and testing network programs in different ways then what you can with Wireshark and other utilities on Windows. If the client uses UDP, then I'm not sure how well #3 works out. I'm working on my own UDP code right now and I'll be able to see eventually, but that won't be for months so it won't be of much help now. My final project utilizing that stuff will be a customizable security auditing tool. I don't plan on getting back to that and finishing it up until later this year though..

GameDev has a Multiplayer and Network Programming forum that has a great FAQ of Winsock resources. I'd suggest you go through them as they are pretty useful for getting started on writing your own networking code! Good luck.

Thnx for that and i think i will go with method 3 seeing how i think it will fit in with what i am trying to do which is inject my dll into the client and read/send packets back and forth from the game server and client. Sorry about the lack of information but i thought asking about general game hacking on this forum wasnt allowed...