Distribution

[Taehl]

The best way to do that is to make your game with a totally authoritative server model. Clients may do as little as send player controls to the server, receive updates, and draw graphics.

Of course, that means that people could edit their server to change the game, but really, it's impossible to avoid that problem.

[Robin]

Also, if it's only friends playing among each other, you can consider some risk of cheating acceptable. Somehow, people seem less inclined to cheat on their friends, than on strangers. Those that have friends to play with, anyway.

[thetree]

Yeah, I'll probably just obfuscate and add a few things to make it harder to hack.

I was thinking of generating a hash of the server Lua and sending that to all clients, if it differs to your server code then disconnect. Although this will kick/disconnect legit players, it will also stop someone from hosting an edited server and being able to play with others. The only way this would be circumvented is if two or more people had the same edited server file, or if they acquired the hash through packet inspection and hard coded it into their client/server code.

Does that seem a good idea or... ?

Thanks

tree

[bartbes]

Of course the hash code can be run on valid code once and dumped, then that hash can always be sent, personally I'd worry about the clients being unedited, not the server. If the server's 'hacked' you're basically fucked anyway, random players cheating is way worse.

[T-Bone]

Yeah, I'll probably just obfuscate and add a few things to make it harder to hack.

I was thinking of generating a hash of the server Lua and sending that to all clients, if it differs to your server code then disconnect. Although this will kick/disconnect legit players, it will also stop someone from hosting an edited server and being able to play with others. The only way this would be circumvented is if two or more people had the same edited server file, or if they acquired the hash through packet inspection and hard coded it into their client/server code.

Does that seem a good idea or... ?

Thanks

tree

That seems pretty good, but since you have to create a hash locally, a potential hacker/cheater/whatever can always see how you did it, and simply return the value it's supposed to have instead of actually going through the hashing. But I doubt anyobody will go that far unless you make a game that people would consider it worth cheating in.

[thetree]

That seems pretty good, but since you have to create a hash locally, a potential hacker/cheater/whatever can always see how you did it, and simply return the value it's supposed to have instead of actually going through the hashing. But I doubt anyobody will go that far unless you make a game that people would consider it worth cheating in.

Hashing will be 100% effective as long as the hacker doesn't own a packet inspector, otherwise yeah, they'd just be able to hard code the actual number in instead of the hashing function. I was planning on using the MD5 hashing algorithm.

Just thought actually, the server could send the client a unique ID (which would be necessary anyway) and the client hash could be salted with that unique ID. That would mean the hacker would need to generate trillions of hashes based on each unique ID. If that ID was say... 40 digits long. They'll be generating for a while...
Its still hackable, but you'd reeeaaally need to be determined to break it. Unless anyone can see a glaring hole in that, I may have overlooked something?

[bartbes]

Well, you know.. your code is still executable, if the hashing algorithm is intact, it can be fed the (false) input data and hash correctly.
Similar to this: The problem with encryption is that you always have to ship the way to decrypt too.

[thetree]

Well, you know.. your code is still executable, if the hashing algorithm is intact, it can be fed the (false) input data and hash correctly.
Similar to this: The problem with encryption is that you always have to ship the way to decrypt too.

So you're saying they could just hash a copy of the correct code, and use that in a modified one? Damn, I hadn't thought of that.

Going on the basis of what was previously said about security of client vs security of server, I could either work out collisions and movement etc on the client and verify it with the server OR let the server do the lot. I'm wary of letting the server do too much as it might put strain on some peoples PCs, though not having used LOVE before I don't know what kind memory usage it has.

As you can probably tell I'm new to making multi-player games, how do other people get around this problem?

[slime]

https://developer.valvesoftware.com/wik ... Networking

[T-Bone]

Well, you know.. your code is still executable, if the hashing algorithm is intact, it can be fed the (false) input data and hash correctly.
Similar to this: The problem with encryption is that you always have to ship the way to decrypt too.

So you're saying they could just hash a copy of the correct code, and use that in a modified one? Damn, I hadn't thought of that.

Going on the basis of what was previously said about security of client vs security of server, I could either work out collisions and movement etc on the client and verify it with the server OR let the server do the lot. I'm wary of letting the server do too much as it might put strain on some peoples PCs, though not having used LOVE before I don't know what kind memory usage it has.

As you can probably tell I'm new to making multi-player games, how do other people get around this problem?

I don't really get this. If most of the work is done server side, that puts less strain on the player's computer. And that's what matters, isn't it? The ones hosting servers can worry about having a powerful enough computer.

What I'd worry about in that case is connection speeds. Depending on what kind of game you are trying to make, this might not be an issue (for example, a classic RPG).