Security in ArmA 3 with a New API

[eddieck 10]

In ArmA 2, security has been massively improved by BattlEye's server-side event logging/blocking feature. Mission makers finally have the ability to develop secure missions, completely immune to all of the old hacks like carpet bombing, mass teleport, mass kill, lag scripts and other various annoyances. (Unfortunately, I'm not aware of any missions that can actually be played with these filters set to block/kick for all client actions, but it is certainly possible.)

While this is a major improvement from the previous situation, the core problem has not been fixed: the current architecture is flawed and not suitable for public MP gameplay. These filters are a band-aid fix to a flawed architecture.

With the possible introduction of a new scripting solution in ArmA 3, BIS has a chance to make a "clean break" from this architecture with a new API. (You can probably tell I'm referring to Java here, but I've chosen not to specifically mention that because these ideas are applicable to any language BIS could choose, including SQF if they wanted.)

• Clients should not be able to directly modify MP game state.
  
• Functions that modify MP game state, such as createVehicle, createUnit, createWeapon, setPos (on remote players), setDamage (on remote players) and several other functions (see the list of BattlEye filters for some other ones) should not be available to the client.
  
• It shouldn't be possible to send arbitrary code to be executed on another machine at all, as is currently possible with setVehicleInit.
  
• publicVariable should be replaced by an event mechanism that does not directly modify variables on other clients or the server. An RPC mechanism could also be useful for calling remote functions and receiving the return value, but this can be implemented fairly easily by the mission maker.
  
• Clients should not directly have the ability to communicate with other clients (such as with the current broadcast-to-all publicVariable).
  
• Clients would trigger events on the server. On the server, an event handler would be called that would perform the appropriate actions.
  

This would be equivalent to having all of the BattlEye filters set to block/kick for all client actions.

Sidenote: Although this topic is primarily about ArmA 3, check out a related DH ticket I opened about a month ago. The ability to obtain the sender of a PV update, in a PVEH, would be useful for creating more secure missions.

[maddogx 13]

+1 to all of the above.

I fear Arma2 will have to make do with its band-aid, since there are compatibility issues to consider, but there is still time to allow Arma3 to benefit from a better solution.

[dysta 10]

Well, why there's very few game developers decide to encrypt the whole game files and folders to minimize the potential of pirate and hack? I mean, take the example like DNA for Mass Effect PC Version as well as Some Ubisoft games with DRM, but more importantly is the stronger support to let player allow to modify the game, and it's really troublesome for security.

[MadMak 1]

Hacking is a game breaking thing. I can't play MP at all. Before DayZ it was kind of good, but for now MP it totally unplayable because of hackers.

[.kju 3245]

While I agree in general A3 needs better protection just like dayZ,

I think it is far more complicated than you imagine.

BI will try a new approach now with DZ at least. From the experience implementing

and seeing it tested upon release, they will be able to learn a lot.

A3 probably would need to have both the existing architecture, to maintain compatibility,

and the more secure one for public play in the long run.

(which is of course more work and hard to maintain)

[NeuroFunker 11]

sorry, BE kinda reminds me on this picture:

been playing dayz again, cause it's finally being ported to namalsk map, but bunch of hackers i met in just 2 days was to much. Many times, i met infinite health guys, u couldn't kill them no matter how many times u shoot them, they usually had custom skins, like "gorka" cpetsnaz camo, some weird 4 barrel shotgun or mg, i was teleported to another hacker guy, who did not kill me but were following me shooting zombies, and after i died, he simply spawned me right where he was.

It can't be, i met so many hackers just in 2 days, it ruins all the fun you had playing. Even servers with that "gotcha-antihack" thingy, did not help to protect against hackers.

I think, it would be best, if BIS would make their own anticheat protection. They do know their engine, better then any anti cheat software dev out there.

[.kju 3245]

NeuroFunker you have clearly now idea of the subject.

Which isnt meant in a negative way - you dont have to.

It is in the responsibility of the parties that matter to take care of that.

BI, BE, server admins (and to a degree MP mission designers).

What you experienced is the fail of the server admin side in the current situation.

PS: BE/$able knows a lot more about how to stop than cheats. It is his field of expertise.

It is naive to think BI could spend te needed time to acquire it themselves.

[noubernou 77]

Simple solution: don't play in non-moderated, public communities.

This game sucks even with out cheating if there isn't some decent overhead.

Also I can say that the OP has probably never done any serious work making content for this game, or they'd realize the how absurd some of their ideas are.

[maddogx 13]

Also I can say that the OP has probably never done any serious work making content for this game

No one has, except for BIS of course. Arma3 isn't out yet. ;)

or they'd realize the how absurd some of their ideas are.

Absurd by what measure? From the perspective of an Arma2 content designer, certainly, none of the above would work because it would break practically every single MP mod and mission in existence.

But from a general multiplayer game design perspective, everything mentioned by eddieck is solid.

[noubernou 77]

No one has, except for BIS of course. Arma3 isn't out yet. ;)

You know what I mean. :p

Absurd by what measure? From the perspective of an Arma2 content designer, certainly, none of the above would work because it would break practically every single MP mod and mission in existence.

But from a general multiplayer game design perspective, everything mentioned by eddieck is solid.

Yea, but thats the problem. It'd work for other games, but not this one. :p

A lot of what he wants to limit is what makes the game so powerful.

[NeuroFunker 11]

Simple solution: don't play in non-moderated, public communities.

that means - nowhere?

[noubernou 77]

Plenty of private and semi-private communities with dozens or hundreds of players where cheating is never a problem.

This isn't BF2/3. Domination isn't the be-all, end-all game mode.

[NeuroFunker 11]

i do prefer warfare instead. Pretty fluent there, had not rly probs with cheaters. Half a year ago, there been someone summoning bombs around the map, but nothing more.

[eddieck 10]

Absurd by what measure? From the perspective of an Arma2 content designer, certainly, none of the above would work because it would break practically every single MP mod and mission in existence.

SQF should definitely be kept as-is to avoid breaking backwards compatibility - too much excellent content out there to just go breaking things.

If BIS intends on introducing a new scripting environment, it would be easier to roll out something like this. The server would know what environment the current mission is using and could enable the appropriate functions.

Dealing with SQF mods + new missions would still be a problem.

A lot of what he wants to limit is what makes the game so powerful.

I'm curious what you're thinking of that would be impossible to do if these changes were made. It would just need to be done differently (i.e. on the server).

[PuFu 4600]

Simple solution: don't play in non-moderated, public communities.

That is not a solution, is a workaround, just like with most of what Arma means ;)

[neokika 62]

Hi,

Well, I'm guessing backward compatibility would be the last thing one would worry about anyway...

The problem here is that blocking global calls from a client machine is not the solution, unless it is done server or mission side, not limited by the game.

Something the OP seems to be forgetting is how sensitive the servers are nowadays when running large player numbers and/or large AI/objects numbers, and currently the only way to ease that is to run things parallel, using players machines. What is being suggested here is to remove this possibility.

Maybe the solution could be some kind of possibility to require a security token for each global call that a mission maker would generate.

Example:

//This would do nothing
publicVariable "VARIABLE";

//This would work, if token is valid
publicVariable ["VARIABLE", _secret];

Edited November 11, 2012 by neokika

[Tonci87 163]

That is not a solution, is a workaround, just like with most of what Arma means ;)

Well Pufu you can´t stop some public players from beeing dicks, the workaround is all that is left if you want to enjoy the game.

[PuFu 4600]

Well Pufu you can´t stop some public players from beeing dicks, the workaround is all that is left if you want to enjoy the game.

There are dicks in most if not all MP games. That doesn't mean this game should (as i have been for the last 6-7 years) be played solely in closed communities.

[noubernou 77]

But it shouldn't limit functionality either to enable "better" gameplay in communities where the caliber of play is never going to match a closed/semi-closed community.

[eddieck 10]

Something the OP seems to be forgetting is how sensitive the servers are nowadays when running large player numbers and/or large AI/objects numbers, and currently the only way to ease that is to run things parallel, using players machines. What is being suggested here is to remove this possibility.

With regards to AI specifically, it is possible to use setOwner to pass an AI off to a client. In addition, AI may scale to multiple cores soon.

If Java is used, that would also yield some performance improvements.

Maybe the solution could be some kind of possibility to require a security token for each global call that a mission maker would generate.

Example:

//This would do nothing
publicVariable "VARIABLE";

//This would work, if token is valid
publicVariable ["VARIABLE", _secret];

I'm not seeing how this would improve security (certainly not beyond what we currently have with the PV filters). Someone could still extract the PBO to get that secret.

But it shouldn't limit functionality either to enable "better" gameplay in communities where the caliber of play is never going to match a closed/semi-closed community.

I'm still interested in knowing what would be impossible with the limited functionality.

[chortles 263]

A lot of what he wants to limit is what makes the game so powerful.

And here we have the fundamental (insurmountable?) problem with ARMA... " the workaround is all that is left if you want to enjoy the game", and the stuff that happened according to NeuroFunker? Infinite health, custom skins, specialized shotguns, teleporting? A custom mission I might be wanting to play might actually be using these. "Security vs. customizability", a zero sum equation in ARMA?

But it shouldn't limit functionality either to enable "better" gameplay in communities where the caliber of play is never going to match a closed/semi-closed community.

I believe what the other posters are trying to say is that the greater risk to "having fun with ARMA" isn't from "BF/COD trolls" who supposedly don't know how to play "properly" (i.e. tactics) but rather from hackers who come in to disrupt gameplay using more overt methods like the "cheats" that NeuroFunker described, and who have tools that already circumvent existing anti-cheat tools.

As it is, it seems like ARMA was previously protected mainly by sheer obscurity -- even with the DayZ standalone being announced, that "protection because we're not a big name enough for trolls to want to hack" is gone.

[noubernou 77]

I'm still interested in knowing what would be impossible with the limited functionality.

Quick example is publicVariable. It allows state to easily be kept with JIP clients, since they will all sync the current value. Now instead of getting rid of it, maybe doing something like declaring what variables are publicly changeable would be a better option. That way you can define what variables you expect external changes to come from and handle them accordingly. Just getting rid of it is not a solution though, because its a very powerful tool.

Don't count on Java either, it is not a priority. SQF will still be the scripting language with the most power, even in A3.

---------- Post added at 02:58 PM ---------- Previous post was at 02:56 PM ----------

And here we have the fundamental (insurmountable?) problem with ARMA... " the workaround is all that is left if you want to enjoy the game", and the stuff that happened according to NeuroFunker? Infinite health, custom skins, specialized shotguns, teleporting? A custom mission I might be wanting to play might actually be using these. "Security vs. customizability", a zero sum equation in ARMA?I believe what the other posters are trying to say is that the greater risk to "having fun with ARMA" isn't from "BF/COD trolls" who supposedly don't know how to play "properly" (i.e. tactics) but rather from hackers who come in to disrupt gameplay using more overt methods like the "cheats" that NeuroFunker described, and who have tools that already circumvent existing anti-cheat tools.

As it is, it seems like ARMA was previously protected mainly by sheer obscurity -- even with the DayZ standalone being announced, that "protection because we're not a big name enough for trolls to want to hack" is gone.

Yea, and moderation fixes all of that.

If you want to play this game like COD and have the servers be unmoderated then expect hackers. You have hackers in all those other games. Its going to happen if no one is babysitting.

On the other hand semi-open communities like UO, and closed communities like ST and other groups almost never have a hacking problem because there are admins available 24/7.

[eddieck 10]

Quick example is publicVariable. It allows state to easily be kept with JIP clients, since they will all sync the current value. Now instead of getting rid of it, maybe doing something like declaring what variables are publicly changeable would be a better option. That way you can define what variables you expect external changes to come from and handle them accordingly. Just getting rid of it is not a solution though, because its a very powerful tool.

We already have the ability to declare which variables can be changed with the BattlEye filters.

Another option could be to have a separate variable space for publicVariable. Clients just shouldn't be able to modify an arbitrary variable in the global variable space of other clients and the server.

There could also be an OnJIP event handler on the server, which would solve this problem with the event mechanism I suggested and allow the server to sync state to JIP clients.

Don't count on Java either, it is not a priority. SQF will still be the scripting language with the most power, even in A3.

No doubt. And of course, we don't even know for sure if Java support will be included. But if not, there's always hope in ArmA 4. :)

[On_Sabbatical 11]

What about limiting a bit the "editability" of this game to make it more controlable ?

I'm sure a lot of you won't like it :D

This is probably what everyone wants to say ...

Edited November 12, 2012 by On_Sabbatical

[gossamersolid 155]

What about limiting a bit the "editability" of this game to make it more controlable ?

I'm sure a lot of you won't like it :D

This is probably what everyone wants to say ...

Don't need to remove any functionality, just need to fix who can execute what.

The problem, which everybody knows, is that ArmA allows clients to basically control the state of the game, whereas servers should be solely responsible for that.