Author Topic: Problem with receiving sf::Packet (Read 6332 times)

l0ud · « **on:** September 01, 2009, 05:35:07 pm »

Hello, I found a problem with the sf::SocketTCP::Receive(sf::Packet) function. When I send data, that is not sf::Packet, and try to recieve it with above mentioned function, the code freeze until the client disconnected.

My English is poor, so I'm not sure if anyone will understand my post. :oops: So, I'll try to explain how to reproduce the problem with simple steps:

1. Download and compile example from selectors tutorial:
http://www.sfml-dev.org/tutorials/1.5/network-selector.php

2. Start the program as server

3. (In windows) run "telnet.exe 127.0.0.1 2435"

4. Press any key

The server is no longer responding, until I close the telnet window.

It's a really easy way to "hack" the server. Using a Receive (char *Data, std::size_t MaxSize, std::size_t &SizeReceived) function works, but I'm getting only raw data, not a sf::Packet.

Laurent · « **Reply #1 on:** September 01, 2009, 06:21:08 pm »

Of course you can receive a sf::Packet only if you sent a sf::Packet...

That's because a sf::Packet has its own internal structure, it's not just raw data.

l0ud · « **Reply #2 on:** September 01, 2009, 06:48:23 pm »

Yes, of course, but it's totally useless when every player can stop server by sending 'incomplete' packet. Is there any way to verify data before receiving as packet?

Laurent · « **Reply #3 on:** September 01, 2009, 07:02:53 pm »

Quote

it's totally useless when every player can stop server by sending 'incomplete' packet

How would it happen? You just have to make sure that your client only sends sf::Packets.
Unless you only write the server and allow external clients to connect to it?

l0ud · « **Reply #4 on:** September 01, 2009, 07:56:57 pm »

I'm writing the client also. But I don't have any guarantee if anyone doesn't use his own client (for example telnet.exe).
It looks like creating the web application without any protection

Who rational will enter ' or 1=1 -- instead of his login?

Laurent · « **Reply #5 on:** September 01, 2009, 08:35:32 pm »

Quote

But I don't have any guarantee if anyone doesn't use his own client (for example telnet.exe)

Then in this case, is it really a problem if the application freezes or behaves incorrectly?

l0ud · « **Reply #6 on:** September 01, 2009, 09:12:58 pm »

Yes, because it's the server freeze, not the unoffical client problem. In this case, the other (normal) players can't play anymore. Server is dead, until the unoffical client disconnected.

phear- · « **Reply #7 on:** September 01, 2009, 09:29:11 pm »

He's basically saying a malicious player can telnet into the server and crash it, which means the server is down for other non-malicious players. Exploit

Laurent · « **Reply #8 on:** September 01, 2009, 10:49:23 pm »

Understood.

I'm afraid I can't help much in this case. Even if I implement something in SFML, a malicious player could still easily read the sources and adapt its client.

The only solution for you is to use raw data and implement your own secured layer over it.

phear- · « **Reply #9 on:** September 01, 2009, 11:51:13 pm »

I think it should be up to the developer to provide his own layer of security otherwise Laurent would have to do a LOT of extra coding just to make some things secure.

Manux · « **Reply #10 on:** December 30, 2009, 05:37:39 am »

Wouldn't setting an (optional) timeout resolve the problem?

Laurent · « **Reply #11 on:** December 30, 2009, 10:58:59 am »

That's a solution. You may also use non-blocking sockets or threads to prevent the application from freezing.

BoingBoing · « **Reply #12 on:** January 10, 2010, 10:42:58 pm »

Code: [Select]


	char Message[128] = "";
	std::size_t Received;
	Client.Receive(Message, sizeof(Message), Received);

Also crashes my application. This seems to happen only when I create an SFML window, my server seems fine as a console.