Security in MTA

[Maggi]

Hi community.

I'm going to write anticheat system for my server but I have some questions about security (anticheats):

1) Is it possible for MTA clients to rewrite their scripts?

2) What will happend if I shoot to cheater wich has GodMode? (who can explain in-depth what will be in this case)

3) (the same question about speedhacks)

4) if client changes his element data (health, money,...) will server believe him?

[Castillo]

1) no.

2) i don't know

3) i don't know

4) i don't know

[Thehookerkiller01]

1. no

2. nothing

3. what are speedhacks?

4. health: yes, money: no

[Arran]

If a player tries to change their health or armour, the MTA inbuilt anticheat will detect that and kick them. If a player tries to change their money it will not work either.

It is said that element data is not secure because a player would be able to change the element data and it would update with the server and other clients. (I am talking about setElementData here and not something like health)

People new to scripting will overuse element data in their scripts but most of the time you can replace it with tables. Element data is only required when something has to be synched with everybody like for keeping dxscoreboard up-to-date. If only the server needs to know something then use a table which prevents any of this security problem as well as being bandwidth efficient.

If you shoot a player with health cheats then the onClientPlayerWeaponFire event would have triggered but not the onClientPlayerDamage, if there was something like onClientPlayerShouldTakeDamage then maybe we could end health cheaters.

There are various ways to detect cheating, they just need to be found. There are some anticheats on the community which should help.

[Maggi]

I'm tired of creating anticheats in samp...))...anyway, anticheats takes a lot of time for doing checks...

speedhack anticheat must test prev and curr positions of element every second.. also elements must be stored in the table (this takes additional memory)

I already thought about cheats and I want to write here my ideas..

current model:

network abstraction layer of GTA is MTA (layer 1)... game world of player is running at client side and is being synced with other streamed clients by MTA .. what it means? it means that client can easily change his memory (layer NULL) and hack it...

ideal model:

client give us possibility to make "basic" atomic actions - aiming, shooting, jumping, driving... but this is only requests - client sends requests to server (packets) like this ACTION_AIMING + aiming data, etc... and server gets this packets from all players, make calculations, and then send back to all clients. This model means that server will take all calculations in his core...yes) this also includes phisics...

[eAi]

We have attempted to do server side physics before, but it's a big task. There's a branch on google code that was for this.

Obviously what you suggest is the preferable way to design a server-client multiplayer game, but clearly much harder in the case of GTA, where we basically need to rewrite GTA if we want the server to be aware of the physical world. At a minimum you'd need the server to be able to load the GTA world collision plus the collision for any custom objects. It'd also need to be able to simulate the movement of client's players and vehicles exactly (which would be an issue with the effect the player's framerate has on game speed).

So, yes, it would be nice, but I don't think we have the manpower to implement it. You're welcome to try of course!

[Maggi]

Of course, "core" phisics on server side means tons of calculations, aslo it sets a few more conditions on resources...

therefore:

what means phisics? it is luxury.. of course main phisics must be at client side. As of server: he is only do approximated simple tasks (speed check, shooting check - test for godmode)...

Ex:

if player A speed.channel X > player A pedtype.maxspeed_channel X then -> speedhack on X channel

or in general:

if object A speed.channel X > object A objtype.maxspeed_channel X then -> speedhack on X channel for object A

of course this simple model of phisics is more faster.. but still has disadvantages:

1) server can''t detect drift cheats. (or something like). They may be detected if some player spectates cheater.

2) speedhacks still be possible but with low speed

3) player can jump and freeze himself

this disadvantages still may be removed with way of adding new params to server's phisics model: derivatives (from math=))

they can detect fast acceleration/deceleration... (x, y, z, dx, dy, dz, d2x, d2y, d2z)

I think that approximated tasks model is the best for our current mta model.

Edited December 17, 2010 by Guest

[dzek (varez)]

Maggi, notice that car falling from the sky can move with around 500 units/s

[Oz.]

If I'm understanding you correctly, those sorts of security features are entirely possible and practical, as we have had them implemented on the DKR server for over a year now. The horizontal velocity that a player is travelling at in a vehicle is compared against an 'expected' velocity, anyone exceeding that value by a certain threshold is sent to 'Hell' for a short period of time. It also detects acceleration. One of our scripters may choose to explain in more detail at their own discretion.

It is still subject to the disadvantages you've listed, as well as additional 'unforseen' circumstances (for example people using the lean glitch on a motorbike, certain surfaces or conditions in specific map areas allowing vehicles to travel faster than they are supposed to, etc. In those cases we simply increase our threshold to compensate). On the whole it is extremely effective.

[Maggi]

Maggi, notice that car falling from the sky can move with around 500 units/s

But I'm talked about this already) about speed on certain channels (x, y, z)

In my SA:MP speedhack anticheat implementation we have these type of checks: SPEED_PL_XY, SPEED_PL_Z_UP, SPEED_PL_Z_DOWN, SPEED_VEH_XY, SPEED_VEH_Z_UP, SPEED_VEH_Z_DOWN - this is more effecient than calculating distance and comparing it with MAX_DISTANCE per second.