Packet Modification Question

So I recently made a simple game and was going to implement a multiplayer mode. I've been reading a lot on the subject of game networking and I'm hoping someone with game networking experience could answer this for me.

Now, what I've seen a few basic games do is assign a client (you, the player,) an ID and then whenever an action is preformed (up key pressed, etc.) a packet of data is sent to the server in the form of "ID, KEYPRESSED". Now, keep in mind this is just a really dumbed down example, but I'm sure many games implement this type of structure, albeit more advanced.

So, my idea is this: What if I made a custom client which let me send out fake packets for another player? More specifically, WASD would control your character and send packets with "MYID, DIRECTION" and the arrow keys would send out "YOURID, DIRECTION".

Now, taking a step away from my simple game example, how do games like League of Legends work? A player clicks on the map and their player is moved. I'm assuming that the client is just sending a more complicated version of what I described above, but dumbing it down I imagine the packet would look like "UNIQUEID, MOUSEX, MOUSEY". There has to be some way that the server identifies between you and another player, so isn't it possible that you could send spoofed packets to the LoL server for another player? I couldn't really find information on the LoL packet structure, but I just want to know if this would be possible and if not, why?

Also, if I wanted to learn about packet spoofing/modification, could someone point me to a good tutorial? I would like to see the LoL packets firsthand and try and see how they're structured.

For starters you should realize that stealing another's identity over IP/TCP is very hard. For the very simple reason that the IP address which started the stream and all the flags and offsets in his traffic are not know to the attacker, so you can never build a packet that the server would assume is coming from the victim.

If *somehow* you get all the offsets and flags correct and predict your victims TCP sequence there's another simple layer that would make it impossible to send information: Encryption, once you've logged into the game, the server can send you a random key that you can use to send safe data to the server. Only you use that key, and the server knows only to accept the key from the ip address that it was logged in on.

So those two things keep people from making your character attempt to solo baron at level one for example

Thank you for the reply!

So, in my mind what I actually wanted to do was mess with some friends - this idea I'm sharing wouldn't work in a random public game but it'd really be great to trick friends in a practice game.

Basically, all of my friends and I use a LoL Zoomhack which just lets you zoom out more than the normal amount. My plan was to create a "zoomhack", share it with friends, and they wouldn't really suspect anything's going on. The thing is, I'd program the zoomhack to also send me their IP details and their encryption key. With that, my computer would be able to successfully spoof packets I assume.

By the way, this is just wishful thinking. I've never programmed anything close to a zoomhack, let alone a client-side hack that retrieves information from other plays and then sends fake packets. Just saying that in case someone actually thinks I'd be doing this :P

Horrible idea, I swear to god the clients will lose sync.

A good idea is to send the event where the player has moved along with a delta in their current position. Occasionally, you should poll player positions and resync if required or kick that who is out of sync(A good anti-hack method) If the framework you're building over-top of supports serialization don't be afraid to use it - of course there is some overhead but the general rule of thumb is to design networking for your game and not vise-versa otherwise you'll end up destroying your games design. Also, don't worry about micro-optimization either, you only optimize when it needs to be done as usually it will be at the cost of the games design.

As for identifying yourself as someone else via TCP\IP connection, that's pretty difficult to do unless your communication layer is seriously corrupted. AFAIK, you could try spoofing the source address field in the packets - hmm its something I'd have to look more deeply into; but even then it'd be difficult to inject conversation into a tcp\ip stream without it being dropped because its invalid(i.e doesn't pass order checking etc..). If it really becomes a problem you can encrypt based on, i.e client number. Anyways, I think the OS overrides the value of source ip anyway so you might have to delve into the kernel to give it a shot.

The way I'm networking my game engine is I synced the physics engine & a couple user events, then occasionally poll the physical bodies of the players to ensure synchronization.

Jetamay, I've got a slew of questions. I'm really new to the whole network programming scene and I can't find much to help. I've been looking for tutorials on network games that are time-sensitive like the top-down shooter and all the examples I've found are turn based games like chess or puzzle games. If you'd be willing to answer a few questions, I'd be extremely grateful! But first, to reply to your comments,

I just found this out today (the synchronizing problem). Even though my opening post said I was going to turn my game into an networking game, I didn't actually start it until today (laziness/procrastination). Anyways, finished coding it today and it was really bumming to have coded an entire server/client game and then having nothing work at a usable level Luckily it's just one day that was wasted instead of one week (or worse!)

I remember learning that TCP carries a sequence number to make sure packets are coming in order. I never really thought about that issue but I can see how that could be a massive issue - totally didn't cross my mind. And I'll keep in mind that the OS overrides the source IP. (Couldn't an application catch all out-going packets and change the data in them? I remember reading an article saying that some hackers use "hack proxies" that modify packets without the client being modified.)

I've been looking up a lot of readable material on network games and one of the most interesting reads was this Valve Developer article on how the Source engine deals with multiplayer networking. The only issue is actually taking those concepts and putting them into practice. I've been familiar with programming for many years but it's been just recently that I've been dabbling in the more advanced topics.

My questions are:

• What resources would you recommend for learning network programming?
• Do you know a good community/forum for programming and game design/development? I really want a positive community where I could ask questions and build relationships with other programmers.
• Did you create your network game using concepts that you came up with on your own or did you get an idea from other games or reading material?

And just to throw this in because 1.) I just found it, 2.) it's cool, and 3.) it's somewhat relevant: this guy walked through the Quake engine's source code and explained it all. I just found this section on network programming so I'm going to read that and if it interests you, I recommend you read it as well!

Yes they can. If you sign them with a time-stamp it makes it a lot more difficult to do though. Also, one cannot use this method to identify themselves as another person for reasons already stated.

You won't need anything that complex for your game, though I suppose you could do something similar but in a smaller scale. Assuming you're going for a central server design, this is how I would do it:


I would have the server:

*I would have the client update the user position based off of what the server tells it and not what the client tells the server. So when you press the up key, change the Vy velocity to like 10m/s by sending a message to the server. Don't move the player on the client - just wait for a response from the server telling you & all the other players where you character has moved & move the player on the client according to the response. This will help you keep in sync with other clients.

*Instead of having players submit their exact location every time they move, have them submit their location and their velocity when they change velocity. To give an example:

*Resync player positions and other critical properties every couple of seconds\fractions of a second - play around with the resync frequency.

*Have players tell the server when they've shot a bullet - network the bullets similar to how you networked play movement(as described above.)

This will cause a little bit of jittering due to the constant resyncing and minor losses of accuracies so you may want to implement a method to "tween" the world objects\players to their new locations upon resyncing (so that such resyncing isn't noticeable) - only do this step if you have to - you might be able to skip it.

NPCs are a bit more difficult only because, I assume you implemented simple following code and not path-finding code using nodes etc. This means your NPCs constantly have a changing velocity so they are constant traveling in the direction of the player. So I would recode your NPC logic so that it travels to a player via particular nodes - take a look at A* path finding (there is a game-dev article on it.) When you have NPCs traveling to nodes to other nodes to players its easier to network (as their velocities aren't constantly changing.)

I can't link you to any external resources(its against the rules) but gamedev forums can help you quite a lot. My networking design is based off of researching like you had + some of my own ideas. Anyways, good luck.

Sorry it too so long to respond, I'm working on something w\ someone else and I lost track of the article.

Also, this is a flash game so I _assume_ you're using sockets or FMS - if I were you I would use FMS (or something similar but free) if I could. Also, it looks like you are sending raw data back and forth from the server - use serialization its much neater.