Introducing Server-side Event Logging/Blocking

198 posts in this topic

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.

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.

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.

#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.

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.

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. ;)

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.

Share this post

Link to post

Share on other sites

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?

Share this post

Link to post

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

Share on other sites

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:

#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.

Share on other sites

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.

Share this post

Link to post

Share on other sites

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.

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.

Share this post

Link to post

Share on other sites

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.