Anti-Hack CounterMeasures

[blazedd 18]

So one of the biggest, if not the biggest problem right now is hackers being able to control a server more than admins without any real work. What DayZ really needs is a better system to handle these problems and detect them and not at the client level. My suggestion is to analyse the inbound commands being sent. My suggestion assumes that basic script commands cannot be disabled (kill, change location, ect).

Detect Mass Deaths or Commands being issued

As a developer myself I would assume it would be fairly easy for The Hive to detect that most to all players in any given server just died from a non PvP interaction. In fact there actually should be a highly detailed log of death on each player (died from (killedby|lackofblood|bluntinpact|command|ect) by (zombie|player$PLAYERNAME]|command[COMMANDNAME] on [TIMESTAMP]. The Hive should be able to detect a unnormal percentage of the server just died (probably anything over 35% of a server with X amount of players. This policy would have to be adjusted by number of players. Seriously detection could be done at a server level, not just a client level. If Target can determine if someone is pregnant based off their purchases automatically, we can detect mass commands being issued on players. The only problem is detecting this and intervening with the death. My solution is the next solution. The other problem may be that hackers could then just slowly kill players rather than instantly kill all players in a server.

Purgatory in between life and death

Assuming we can detect that the players were killed by a command, we need to be able to restore their life back to their past location, condition, & with their loot. The problem, I assume, would be the ability to detect and handle these before a player reconnects or respawns. Rather than kill a player instantly and take them to the "You Are Dead" screen. There needs to be a passing of your life that lasts 10-20 seconds. In this timespan The Hive should have enough time to look for similar deaths in the same server, log how the death took place, ect. During this check it needs to make sure that it only finds players killed by the same cause (so if a hacker dies, they cannot just kill all the players to restore their player). If a determination was found that the player didn't die, it needs to either kick them from the game, show the death screen, or simply revive them before they pass to death. As long a the player is flagged to not be killed then there shouldn't be a need for any extra work to retain the player information that they may have died. They could be flagged as in purgatory as a seperate condition than alive/passed-out/dead.

[Tsyn 215]

Not some bad ideas there bud.

The 'Purgatory' shit sounds good.

[blazedd 18]

Beans are always appreciated if you can spare one ;)

[NsN 14]

yes

the only reason i die anymore is getting teleported and other stupid shit

[blazedd 18]

yes

the only reason i die anymore is getting teleported and other stupid shit

Yep, I logged into a server last night, my body wasn't even ingame yet and I died. Seriously upset. I found an ATV and was finishing repairs.

[Harette 5]

Im amazed there isn't Triggers/Stored Procs for this already, and to not commit the changes of the Player's Tables on the hive unless they pass some simple tests

Examples,

Check to see if a large percentage of players on a server die within 1 minute.

Also the same logic could be used to monitor Teleportation, if someone just moved 10KMs in 1 minute.

Or check if 10 people moved 2km to the same place.

I mean it could also be logic that requires the User to flag it.

IE In the process of aborting give them the option to flag that "Abort" saying it shouldnt be commited.

-Reply spomething like "Give us 5 minutes to verify and restore your account"

You run the procedures to check, if it failed one of the tests, then roll back the changes.

This way it requires the user to gtfo, and flag it and is something not run ever second.

Maybe put a time limit so that the player can only say once every hour that the changes shouldnt be committed.

Potentially there could be CPU/Useage savings, as the new logic use will be offset by less creatition of characters, commiting ficticious data, etc.

Or maybe make hourly roll back points for every person that they roll back to in the event of them flagging it.

As a C#.Net (3.5, 4.0 Frameworks) programmer with some experience in T-SQL and SQL Server SMS

I also have a 4 year BT from an accreditted instutition and 5 years of experience in my field.

Basically im trying to say im not talking out of my ass here, and that I do have some knowledge of this.

[blazedd 18]

Thanks for summarizing what I already said. I didn't have any schooling and I came up with this idea.

[Uncle Gapey 16]

Good ideas. Also need a distance check on kills.

[snip]

OnPlayerKilled (vars) {

if (calcDistance(killer.Location, victim.Location) > questionableDistance) {

haxWatch(killer.PlayerName)

}

[snip]

haxWatch can then keep track of how many times this happens in a pre-defined interval.

A 3rd-party anti-cheat that I somewhat helped to create for BFBC2/MoH/BF3 calculated shot angles and analysed them against time between kills and kill distance. It's a super effective method with the right tweaking.

All is for naught if Rocket/devs don't have access to the proper resources though.

[blazedd 18]

Always a great idea to have code in place to check this stuff. I wonder how much of this is arma2 server dependent and how much is actually able to be modified from Rocket's perspective.

[Harette 5]

As a C#.Net (3.5, 4.0 Frameworks) programmer with some experience in T-SQL and SQL Server SMS

I also have a 4 year BT from an accreditted instutition and 5 years of experience in my field.

Basically im trying to say im not talking out of my ass here, and that I do have some knowledge of this.

For the record, that was not meant as an insult but more of a "I have experience in this exact area that idea is very feasible, and good"

Thanks for summarizing what I already said. I didn't have any schooling and I came up with this idea.

Actually, we did have different points of how the same issue(s) should be addressed.

I just think it would make more sense to have roll back points that get updated every hour on the hour through backup scripting, and requring the user to flag that death/abort as bad death/location/etc information.

That would take away requiring checking everytime someone dies, moves, logs out, etc. Which I should assume would be pretty load intensive on the server not to mention a lot of events to keep track of.

Also it potentional could require not having to add Tables/Fields to the Database/Tables.

But would require a more aggressive backup plan, and some Menu/GUI modifications client side.

haxWatch can then keep track of how many times this happens in a pre-defined interval.

A 3rd-party anti-cheat that I somewhat helped to create for BFBC2/MoH/BF3 calculated shot angles and analysed them against time between kills and kill distance. It's a super effective method with the right tweaking.

All is for naught if Rocket/devs don't have access to the proper resources though.

I wonder if Rocket and the Dev team would allow server Admins to install (pre-approve of course) other vendor anti-cheat.

Could potentially save them a lot of dev time on their part.

[blazedd 18]

I don't know that it would require a backup plan as much as a system to sort through the deaths as they come in and flag them as they go. So rather than saying Oh, they are dead, mark them as dead and them if they need to go back and set them to alive (during the purgatory phase) it can do so without wiping the player's current data row.

[Harette 5]

I do wonder if they keep a log of your character's lives, or if they reset a single data row when you die with default Items/Location/etc

Your method would definitely be easier to implement if they keep your "old lives" as they could just roll that life back to "alive" or restore your old location.

Either way, no matter how it is "attacked" i agree with you 100% that this should be a focus in the near future.

Right behind getting inventory/vehicles to save correctly and consistently.

[jackcrow 129]

I could care less about getting items restored, I just want these fools caught and globally banned.

[Valec 55]

This all sounds great in theory. Except that it sounds more like things that need to be addressed within the ArmA 2 engine, not DayZ. Rocket is a mod maker. He can't tinker with the DayZ engine itself. So you need to figure out what's doable within the scope of a modification. These might be good ideas to consider for the standalone release, though.

[blazedd 18]

Good point, how are these not issues with Arma2 multiplayer as well? If they are, is this just a display of the problems that can easily exist on their platform?

[blazedd 18]

I could care less about getting items restored, I just want these fools caught and globally banned.

Yes, this would definately be part of this but we, as players, still need a way to continue playing without ragequiting.

[Uncle Gapey 16]

This all sounds great in theory. Except that it sounds more like things that need to be addressed within the ArmA 2 engine, not DayZ. Rocket is a mod maker. He can't tinker with the DayZ engine itself. So you need to figure out what's doable within the scope of a modification. These might be good ideas to consider for the standalone release, though.

Many of the ideas we are discussing would only require a text log file. I think you're likely correct. Thing is, Rocket is currently the #1 reason people are buying this old game. DayZ might've sold more copies of the game than the original content did - I have no idea. The point I'm getting at is Rocket has constant interaction with the Arma team (according to his interviews, etc.). I would (perhaps erroneously) assume that his opinion and requests carry a certain amount of weight. The Radio Chatter is constantly full of hax reports. You can see where I'm going with this.

Can't wait to hear the final word on Rocket's engine choice.

[KDRiLLER 1]

The way the restore method should work is that every time you die, the server should take a snapshot of your character. Also, maybe save a general snapshot of everyone every 10 minutes or so (saved onto and by the server not the hive). As long as the server isn't running with 50 people, this snapshot shouldn't put to much pressure on the CPU and storage medium of the server.

In terms of how flagging should happen, it might just be easier to allow the users to report when they have been unlawfully killed and also report hackers on death. It might also be a good idea to allow players to report players while they are still alive.