With cheating always a large concern in modern gaming, can you share some information on the methods used to secure Blueprint execution both on the client and with interactions between a server and client?
asked Dec 15 '14 at 09:03 PM in Blueprint Scripting
We currently do our best to assert on bad content, but it's just really difficult to guarantee we catch everything, so the general rule is to treat content like an executable. If you don't know where it came from, or don't trust the source, you probably shouldn't load it.
That isn't to say we don't do what we can to sandbox this content, it's just really hard to make guarantees. We are constantly trying to get better at this though, and any issues you know about that we don't properly detect, please email email@example.com directly with your findings or concerns.
For server/client interactions, we've put a lot of effort in protecting the server and client.
From the perspective of the client sending packets to the server, we are pretty strict.
From the moment a packet arrives, we start inspecting it against known constraints and rules, and if we detect that a client is misbehaving, they are disconnected. Examples include strings larger than should be possible, impossible indices into replication tables, etc. We basically try and sandbox the client as much as possible.
For data that is passed to game code, this is a little tougher. For RPC's, we allow the game code to get a chance to look at the inputs before processing the call, and decide if the data is bad. As above, it a client is misbehaving, they are disconnected. This functionality isn't currently available for BP's, but we've added a task recently to make this possible.
For clients that process packets from the server, the above also applies, but we generally try and recover (rather than disconnect), since we assume clients only connect to trusted sources.
answered Dec 16 '14 at 05:02 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here