I know any game is hackable, and the goal is to make it as difficult as possible to ward off interest. That said, my question is if this is the proper way to set variables.
In the player’s Character BP there is a “blocking?” variable that is checked when a player is attacked; obviously we wouldn’t want somebody to hack the game so this is always true. This variable is set on the client side, and then an RPC is called to tell the server so they are both on the same page. I know its a bad idea to use an input on the RPC event because that allows the client to feed an altered value to the server.
So, as you can see in my screen shot, the “True/False” value is no longer accessible/hackable by the client because it is being defined in the Server RPC logic, right?
ALTERNATIVELY - I could do something a little more complex but seemingly more airtight. Run an event on the player state from the character via server RPC, which runs another event on the client after defining the value in the player state on the server’s end. This is even better, yeah?
I haven’t done networking with unreal engine but the general rules are that you must never trust the data a client sends to a server and that the server’s role is to validate any input and must decide how to act on that.
Meaning that the server holds a valid state in which all network data from the clients has been processed and validated. If data reported by a client seems wrong, the server could send a new state to the client to sync to. Alternatively you could block the client if this points at hacking.
To mix up server / client logic on those blueprint nodes is rather messy, I don’t believe that is the right way but someone with networking experience for Unreal should join us to confirm. There is a replication system already.
You know what the chanches of finding the right memory address on a ue4 exe for a single boolean are?
Also, unless the variable is exposed or linked in some way, the memory address for it should be randomly defined any time you reaload the exe.
Network sniffing wise, that’s a little different.
Maybe you could find a single variable value to send to the server.
And if you could, maybe you could append that to every request.
The answer there is simple though. Ban anyone thats blocking constantly.
Well, you could easily scan for changing values and filter out addresses which are surely not the specific boolean. Eventually you end up with one or a few addresses. You shouldn’t worry about people hacking client side though, let them do that. Some people will cheat, mod textures or do other memory related “hacks” as well. The moment they sent wrong data to the server it may not pass through server validation, that filters out any problem on the network.
I’m saying client side can and will be hacked anyway and some “hacks” can be player mods or cheats. What you should worry about is that the server must not process hacks as valid data.
You need to figure out how to process data properly server side, which is the actual question of this post. I’d re open the post and see if an expert on that can join so you can get an actual answer ;).
I’m going to dump a few links here which are required for basic general understanding.
This link indeed shows how validation methods (WithValidation) for RPCs are used but to me this looks messy / confusing if done for every little method we have this would be unmanagable.
In your understanding you are missing the fact that cheating Client can just fire a Server RPC on his own whenever he wants. So this set up with circular Client/Server RPCs doesn’t really make sense.
You shouldn’t really care about the fact that there is a possibility of accessing and changing memory on Client side. This can happen no matter how obfuscated it is. Every critical state should be stored on Server, and then Clients won’t be able to easly access these.
What You should do is what Roy said in his first comment - a validation process.
Every Server RPC should perform multiple checks, validate the passed data, and ensure that the RPC should have been possible to call in the first place.
In your example there is no validation, so answearing the question - Yes - it is very easy to cheat with this setup.
If You want to make multiplayer code safe, better move it to C++.
In BPs, the RPC boilerplate spaghetti will grow very fast and became hard to manage.
C++ gives more ways to manage it, like for example WithValidation specifier
However, don’t really bother thinking about cheaters when you’re creating a small game. Belive me, they will appear no matter what
But be very careful if there are serious risks involved such as theft of personal data / accounts / banking information etc. If you do not set up validation and security you might just be able to retrieve those through client side hacking. You might also risk a hacker infecting other clients through the server (which could get other players banned, or get their entire system screwed.). Even the big guys screw that up sometimes, look at Dark Souls.
Unfortunately, I do not know C+ so my options/abilities are limited.
That said, let’s just pretend I actually made a game that managed to grow to a point it would actually need this thorough of security; it would probably be wise to hire a professional and do it properly.
So, I suppose I’ll cross that bridge when (and if) I get there.
Absolutely. For a first project you should consider not doing online multiplayer because besides the security concerns and added complexity they can also cost more money to maintain (server hosting etc.). When you feel comfortable scaling up to a bigger project I strongly recommend jumping into c++ and avoiding blueprint completely. Blueprint is a prototyping system with its own problems, it does not scale. If you do make a large project in blueprints and decide to translate it to c++ later, it will very much feel like starting over entirely.
The real question here is, what prevents a legit player from blocking all the time?
From the looks of it, there’s no logic preventing blocking here, so I could “cheat” with a keyboard macro or putting duct tape on keyboard. It’s not even cheat, it’s valid gameplay according to game code.
If there’s any logic to prevent blocking during gameplay, that logic should be verified on server-side, and the “SR Set Blocking” event is a good place to check that. The same logic can also be checked on client to prevent executing false predictions, but as others said you shouldn’t trust client with that check.
Input is pretty much the only thing you can trust the client with. If you don’t trust its inputs, you aren’t gonna do anything. Now, generally, you rarely end up sending raw inputs directly to server. Rather think of it as client requesting to do an action, and server validates that action or not.
There’s a whole stamina system it checks in order to allow a player to block. Player stats are all kept in the Player State BP for just this reason.
It’s more so once the server, say, determines the player’s stamina is depleted and can no longer block, there are still some booleans that are being checked that aren’t ran through the server that are influenced by that determination but I’m worried can be hacked after the fact.
I’ll probably end cutting out as many checks as possible and then migrating anything that’s left on the player character BP into the Player State.
That document describes that all data in there is sent to other clients. I’d be sure not to put anything in there I don’t want another computer to know.
A Player “Stat” such as stamina sounds more like a state you would have on a Pawn or a component on that Pawn.
Now, talking about spoofers, there’s a whole lot out there, and yeah, some folks use 'em to get around bans and whatnot. A permanent spoofer can change your hardware IDs so the system thinks you’re a different device entirely. But honestly, it’s a bit of a cat-and-mouse game with developers. They patch vulnerabilities, and hackers find new ones.
