Introducing Server-side Event Logging/Blocking

[$able 2]

BE Server v1.156 in combination with the latest OA 1.62 beta server now provides new powerful features for server admins. Keep in mind that this is work-in-progress, so these features will be improved and more will be added over time. Special thanks go out to Ondřej Španěl / Suma without whom this wouldn't have been possible.

1.) Log and/or block all vehicle and unit spawns via "createvehicle.txt"

By creating this file in your BE working directory and adding rules/filters to it, you can now log and/or block all calls of the "createVehicle" and "createUnit" scripting commands. Logging is done to "createvehicle.log". The filters look exactly the same as in the scripts.txt file, see here for more information: http://forums.bistudio.com/showthread.php?131759-New-BattlEye-features-for-server-admins. Note that each command is automatically blocked if the corresponding filter has kicking enabled (type "4").

See the following examples:

1 ""

This simply causes all vehicle/unit spawns to be logged to createvehicle.log.

1 !"WeaponHolder" !"TinCan" !"Rabbit" !"Goat" !"WildBoar" !"Sheep" !"Hen" !"Cow01" !"Cow02" !"Cow03" !"Cow04" !"zZombie_Base" !"z_hunter" !"z_teacher" !"z_suit1" !"z_suit2" !"z_worker1" !"z_worker2" !"z_worker3" !"z_villager1" !"z_villager2" !"z_villager3" !"z_soldier" !"z_soldier_heavy" !"z_policeman" !"z_priest" !"BoltSteelF" !"Land_Fire_DZ" !"SodaCan" !"JackDaniels" !"RoadFlare" !"ChemRed" !"ChemBlue" !"ChemGreen" !"Survivor1_DZ" !"Survivor2_DZ" !"SurvivorW2_DZ" !"Bandit1_DZ" !"CZ_VestPouch_EP1" !"DZ_Patrol_Pack_EP1" !"DZ_CivilBackpack_EP1" !"DZ_ALICE_Pack_EP1" !"SmokeShell" !"SmokeShell" !"SmokeShellRed" !"SmokeShellGreen" 
5 "SeaGull"

This was created by Dwarden for DayZ. The first line causes everything but the listed vehicle/unit types to be logged to createvehicle.log. The second line causes all "SeaGull" spawns to be logged, blocked and kicked for.

A typical createvehicle.log entry looks like this:

12.08.2012 14:20:26: SomePlayer (95.7.111.10:2304) d3dcf429c679f9af82eb9a3b31c4df44 - #0 "MedBox0" 92:4 [-18594,25833,369]

#0 is the number of the filter/restriction in createvehicle.txt, usually line number - 1, "MedBox0" is the type of the vehicle/unit being created, 92:4 is the network ID ([client ID]:[object ID]) and [-18594,25833,369] is the spawn position.

2.) Log and/or block all remote code executions via "remoteexec.txt"

By creating this file in your BE working directory and adding rules/filters to it, you can now log and/or block all attempts to execute code remotely on the server or other clients (usually done via "setVehicleInit"). Logging is done to "remoteexec.log". The filters look exactly the same as in the scripts.txt file, see here for more information: http://forums.bistudio.com/showthread.php?131759-New-BattlEye-features-for-server-admins. Note that each command is automatically blocked if the corresponding filter has kicking enabled (type "4").

See the following examples:

1 ""

This simply causes all remote code executions to be logged to remoteexec.log.

1 !"this enableSimulation false;this allowDammage false;this disableAI 'FSM';this disableAI 'ANIM';this disableAI 'MOVE';"
5 "dayz_serverObjectMonitor set [count dayz_serverObjectMonitor, _object];"
5 _xcompiled
5 loadFile
5 removeAllWeapons
5 removeAllItems
5 disableUserInput
5 serverCommand

This was created by Dwarden for DayZ. The first line causes everything but the listed script/code to be logged to remoteexec.log. The other lines cause code containing the listed strings/commands to be logged, blocked and kicked for. I'd like to point out that "5 loadFile" entirely prevents the exploit allowing hackers to steal files from your server.

Typical remoteexec.log entries look like this:

12.08.2012 19:13:23: SomeCheater (101.200.55.117:2304) 9d1e49be7ef3b16519bf66c400cc6cdd - #0 "{ if((getPlayerUID _x) == '5230977') then { _x hideObject true; }; } forEach playableUnits;"
12.08.2012 21:18:25: AnotherCheater (77.109.3.18:2304) 29ff7be2045eea48db69e249baf2ffbd - #0 "if (name player == "SomePlayer") then { player setpos mypos;player setVariable["lastPos",0, true];};"
12.08.2012 21:32:37: YetAnotherCheater (210.133.66.11:2304) 65be87266db9e5d78624a4d9c780a878- #0 "if (name player == "SomePlayer") then { removeAllWeapons player;removeAllItems player;[dayz_playerUID,dayz_characterID,"Goat"] spawn player_humanityMorph;player addWeapon "NVGoggles"; };"

3.) Log and/or block all public variable events via "publicvariable.txt"

By creating this file in your BE working directory and adding rules/filters to it, you can now log and/or block all public variable events (triggered via "publicVariable" and its variants) that are often exploited to execute code remotely on the server or other clients by overwriting certain game variables/functions/symbols. Logging is done to "publicvariable.log". The filters are applied on the name of the public variable and look exactly the same as in the scripts.txt file, see here for more information: http://forums.bistudio.com/showthread.php?131759-New-BattlEye-features-for-server-admins. Note that each command is automatically blocked if the corresponding filter has kicking enabled (type "4").

See the following example:

1 ""
5 BIS_Effects
5 player_medMorphine

The first line causes all public variable events to be logged to publicvariable.log. The other lines cause public variable names containing the listed strings (function names that are typically exploited at the moment) to be logged, blocked and kicked for.

Note that you can use the new loadEvents RCon command to (re-)load createvehicle.txt, remoteexec.txt and publicvariable.txt while the server is running.

Ok, that's all for now. As a final note, these features cannot be circumvented with a client-side hack. ;)

Edited September 5, 2012 by $able

[Dwarden 1125]

finally revealed ;)

this space reserved for my ranting or important info

>

^

[cm. 10]

Amazing changes, been using this for a few days and already seeing massive improvements in detection and prevention!

[zyklone 1]

While this is alot better than what we had settings like this should really be moved into the mission config.

Only the mission author can know what kind of commands the mission will execute.

Hard to accomplish from BE ofcourse...

[Dwarden 1125]

While this is alot better than what we had settings like this should really be moved into the mission config.

Only the mission author can know what kind of commands the mission will execute.

Hard to accomplish from BE ofcourse...

you do realize this covers

1. engine stuff

2. mod stuff

3. mission stuff

so mission author can't cover everything either, only server owner

[chus 0]

Dwarden do I understand it correctly createvehicle.txt only works for vehicles spawns?

I got this in the createvehicle.log.

14.08.2012 05:27:41: Playername (78.53.xx.xx:62249) xxxxxxxxxxxxxxxxxxxxx - #0 "DZ_Backpack_EP1" 533:6 [0,0,0]

BTW.

I know its dayz but, as you posted the tool here I wanted to ask you here.

[simple69 1]

14.08.2012 09:35:31: XXXXX (XX.XX.XX.XX:2304) GUID - #0 "

if (isServer) then {

_object = createVehicle ['Old_bike_TK_CIV_EP1', [10419.3, 2260.61, 0], [], 0, 'CAN_COLLIDE'];

_object setVariable ['ObjectID', 5901.4, true];

dayz_serverObjectMonitor set [count dayz_serverObjectMonitor, _object];

_uid = _object call"

14.08.2012 09:48:01: XXXXX (XX.XX.XX.XX:2304) GUID - #0 "

if (isServer) then {

_object = createVehicle ['UH1H_DZ', [6724.05, 2902.51, 0], [], 0, 'CAN_COLLIDE'];

_object setVariable ['ObjectID', 10989.5, true];

dayz_serverObjectMonitor set [count dayz_serverObjectMonitor, _object];

_uid = _object call dayz_objec"

Is this someone summoning a vehicle?

[semipr0 1]

Well this should make life slightly less painful, least in regards to parsing logs.

Oddly after installing these files to my server, two regulars on my server respawned in Cherno and Elektro with no items, as if they'd died...but they had not.

Trying to figure out why this would have occurred.

---------- Post added at 09:30 ---------- Previous post was at 08:50 ----------

My previous post doesn't seem related to this at all. Seems they didn't heed the five minute warning that the server was going down so I could install and load the files. Though why they got reset is confusing still.

Edited August 14, 2012 by semipr0

[noubernou 77]

you do realize this covers

1. engine stuff

2. mod stuff

3. mission stuff

so mission author can't cover everything either, only server owner

Actually in communities where there are dedicated mission makers, or they play multiple types and kinds of missions they would be the ones who cover everything.

[falcon911 1]

Wonderful news!!! But looking over this and then having the server admins to determine right from wrong....So your saying that anything that turns up in the Log files will determine that that person is a hacker?

Can you give some more examples on just what exactly we are looking for?

Here is something to go by. One of my logs.

Creatvehicle.log

14.08.2012 07:25:04: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "Survivor2_DZ" 296:4 [1,0,0]
14.08.2012 07:25:04: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_ALICE_Pack_EP1" 296:6 [0,0,0]
14.08.2012 07:32:45: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_ALICE_Pack_EP1" 296:212 [12272,9483,20]
14.08.2012 07:35:32: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_ALICE_Pack_EP1" 296:233 [12220,9518,27]
14.08.2012 07:42:22: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_CivilBackpack_EP1" 296:261 [12277,9471,20]
14.08.2012 07:51:03: Jak (75.186.91.39:2304) ffe234d702b3a4ab262046f8896bbffa - #0 "Survivor1_DZ" 293:1119 [-18688,25929,376]
14.08.2012 07:51:13: Night specops (66.68.48.133:2304) 1e1aacfe73d2a44d0303af62b2a187a3 - #0 "Survivor2_DZ" 300:4 [1,0,0]
14.08.2012 07:51:13: Night specops (66.68.48.133:2304) 1e1aacfe73d2a44d0303af62b2a187a3 - #0 "DZ_Patrol_Pack_EP1" 300:6 [0,0,0]
14.08.2012 07:51:18: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 296:343 [11965,9134,54]
14.08.2012 07:51:48: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_CivilBackpack_EP1" 296:388 [12054,9100,62]
14.08.2012 07:51:52: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "DZ_CivilBackpack_EP1" 296:394 [12037,9161,53]
14.08.2012 10:43:23: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:68 [11955,9120,54]
14.08.2012 10:43:23: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:69 [11959,9127,54]
14.08.2012 10:43:23: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:70 [11965,9134,54]
14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:73 [11958,9123,54]
14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:74 [11946,9114,54]
14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:75 [11942,9110,54]
14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:77 [11948,9110,75]

Remoteexec.log

14.08.2012 05:13:39: Noct (96.54.238.60:2304) cb98dbb4e26001b07e16f0a84c43773c - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 05:17:12: Noct (96.54.238.60:2304) cb98dbb4e26001b07e16f0a84c43773c - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 05:19:22: Noct (96.54.238.60:2304) cb98dbb4e26001b07e16f0a84c43773c - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 06:19:22: Jak (75.186.91.39:2304) ffe234d702b3a4ab262046f8896bbffa - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 07:25:00: Jak (75.186.91.39:2304) ffe234d702b3a4ab262046f8896bbffa - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 07:51:03: Jak (75.186.91.39:2304) ffe234d702b3a4ab262046f8896bbffa - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 10:42:30: FroZzeN (94.211.247.77:2304) a628ce407cf562d58e34a9b1027338a9 - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 10:42:32: FroZzeN (94.211.247.77:2304) a628ce407cf562d58e34a9b1027338a9 - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 10:44:03: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 10:46:02: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 10:51:37: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 11:07:29: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "mpi=[]execVM "playerinit.sqf""
14.08.2012 11:12:01: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "mpi=[]execVM "playerinit.sqf""

[kylania 568]

Actually in communities where there are dedicated mission makers, or they play multiple types and kinds of missions they would be the ones who cover everything.

You musta missed all the "for DayZ" mentions in the OP. ;) There are no mission makers in DayZ, only server operators.

[semipr0 1]

You musta missed all the "for DayZ" mentions in the OP. ;) There are no mission makers in DayZ, only server operators.

A bunch of really frustrated ones. Be thankful DayZ is getting so much attention. It makes other great mods like Wasteland less apt to be constantly disrupted by script kids.

[Paintface 10]

very happy about this update, though what if there are server owners who are basicly cheaters? will their servers behave as before?

[semipr0 1]

very happy about this update, though what if there are server owners who are basicly cheaters? will their servers behave as before?

If you're dealing with a server admin that isn't legit then its obvious that they'll either not implement these two features or they'll simply ignore anything in them that pertains to their own activities.

Would be nice if these were required files and the DayZ team could remotely pull their data if they suspect a server is not legit.

[DayZDeadmeat 1]

So what is MedBox0? Is that a valid hack?

My only ARMA experience is playing/hosting DayZ.

[semipr0 1]

I'm assuming since Dwarden just recently did all this up that this is actually functional on BE 1.62. Course the post says it is...so it must be.

Just wondering cause I've got the text files in my working BE directory on my server but they haven't generated any logs yet.

Course we're not all that busy atm either due to the extreme script disruption the server has seen over the last couple weeks so it might take me awhile to pick up anything for a log to be generated from.

[simple69 1]

So what is MedBox0? Is that a valid hack?

My only ARMA experience is playing/hosting DayZ.

From my understaing this

14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:77 [11948,9110,75]

Just means someone accessed a medbox. Clan mate showed up in the log file with this and he was at hospital looting the medboxes.. I guess if it says # 1 "MedBox0" it would mean someone added a MedBox

Edited August 14, 2012 by simple69

[DayZDeadmeat 1]

From my understaing this

14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:77 [11948,9110,75]

Just means someone accessed a medbox. Clan mate showed up in the log file with this and he was at hospital looting the medboxes.. I guess if it says # 1 "MedBox0" it would mean someone added a MedBox

Not so sure about that. #0 is just the line number of the filter file. Looks like it fires on the spawn/creation of any item except for zomebies, animals, players, packs, chemlights, smoke grenades, bolts and junk. :confused:

A typical createvehicle.log entry looks like this:

12.08.2012 14:20:26: SomePlayer (95.7.111.10:2304) d3dcf429c679f9af82eb9a3b31c4df44 - #0 "MedBox0" 92:4 [-18594,25833,369]

#0 is the number of the filter/restriction in createvehicle.txt, usually line number - 1, "MedBox0" is the type of the vehicle/unit being created, 92:4 is the network ID ([client ID]:[object ID]) and [-18594,25833,369] is the spawn position.

[semipr0 1]

From my understaing this

14.08.2012 10:43:24: Louie (86.177.83.249:2304) 2995ebc5c4ae87c342d3aabe40fe5d0f - #0 "MedBox0" 4:77 [11948,9110,75]

Just means someone accessed a medbox. Clan mate showed up in the log file with this and he was at hospital looting the medboxes.. I guess if it says # 1 "MedBox0" it would mean someone added a MedBox

Seems like we're going to need a FAQ in relation to what is legitmate and what isn't, though thats hardly a difference from scripts.log. Hard to tell whats going on in there unless its just blatantly obvious.

---------- Post added at 13:20 ---------- Previous post was at 12:27 ----------

Overall so far what I seem to be getting in createvehicle.log is people actually doing completely legitimate things and using completely legitimate items.

Mostly seems to be logging backpacks and ghillie suits, with one Medbox entry that was a legitimate player accessing a medical supplies box in the Cherno med tents.

Will keep watching but so far this isn't showing me anything illegitimate.

[Dwarden 1125]

there are up2date files with needed filters available from me, you can reach us on DayZ admins IRC

[semipr0 1]

Ahh I don't have that, our server "admin" I.E. the guy who pays for it, has that info, I admin the server cause he doesn't know how. Technically I should have gotten our server but he got one first so I just agreed to handle the technical side of things.

---------- Post added at 15:33 ---------- Previous post was at 14:11 ----------

LOL actually the person that pays for the server can't even get this info. Its all stuff on support.dayzmod.com and our service host, Host Altitude, is the one that requested the instance ID's and thus has all that information, I guess as clients of a provider we don't have access to that part of administration.

I'm tempted to just dump this host provider and set up on my own colocated blade server and request our own instance ID so we're more closely involved with the admins group, but til the mod has a green light for a linux distro, I really can't be bothered to set up a Win2K 2008 server on the racks simply for one game.

[nuxil 2]

to all the dayz hosters. i suggest you request official files "all 3" from the dayz teams. this way all dayz hosters could use the same files and it wouldnt be so much hassle about this. this way they only know that they need to update the files by replacing them.. not by editing new content into it.

prevent more," how do i do this" posts.

Edit: Now i see they already have one

to be honest. i think to create proper files, you need knowledge that is a bit above what the average user knows.

let it also be said that. new mission makers should also take their time and provide thise files if needed to that spesific mission. possibly same for mod makers.

the only problem i see with this system is that. to create desent files. you basicly need to check every mod/addons/mission code it uses.

this can become a huge task in itself.

atlest this is better than nothing. :)

Edited August 14, 2012 by nuxil

[DayZDeadmeat 1]

there are up2date files with needed filters available from me, you can reach us on DayZ admins IRC

Could you not just post a link or put them in dropbox/pastebin?

[ShadowDuke 1]

Why just not post them? We (every admin) have to come to your irc and ask you for the files?

I really dont understand why you have to make it so hard for people!

Edited August 15, 2012 by ShadowDuke

[tonic-_- 53]

Maybe it would be of use to fix the current bypass methods for bypassing script detection then adding another detection pattern for them to bypass?

Just a thought.