New BattlEye features for server admins

[nuxil 2]

@ ballou as MadDogX said. read the 1st post.

1 : log to scripts.log.

2 : log to server console.

3 -> 1 + 2 : log to scripts.log and server console.

4 : Kick

5 -> 4 + 1 : Kick and log to scripts.log

6 -> 4 + 2 : Kick and log to server console.

7 -> 4 + 2 + 1 : Kick, log to scripts.log and server console.

Someone needs to move the info to the BIKI page finally.. $able/Dwarden/BI best case.

http://community.bistudio.com/wiki/BattlEye

I fully agree.

it would be more usefull to have it in the biki than go digging through threads/posts here on bif to find out hints here and there for how it works..

[cm. 10]

wtf is going on with the new BE update?

My scripts.log isn't budging at all. Even used the "correct" new version. Nothing.

[chaveezy 1]

They are urging server admins to remove their current scripts.txt file until an update is released... Last night it seems they had some issues and BE was kicking everyone for various script restrictions..

[Saiboogu 1]

Also, the restriction # reflects the entry number in your scripts.txt file (starting at 0).

Is this a firm line-by-line match of the file or does it skip commented out lines? Does //new count as line zero, for instance, or is it ignored?

[WestTom 1]

Can anyone share updated scripts.txt or cfgdayzdefault.zip?

[Saiboogu 1]

Can anyone share updated scripts.txt or cfgdayzdefault.zip?

I just got this a few minutes ago from a dev when I requested the latest.

http://pastebin.com/0M0dNWPf

[WestTom 1]

I just got this a few minutes ago from a dev when I requested the latest.

http://pastebin.com/0M0dNWPf

Seems to be broken.

Battleye has renamed it to scripts_old.txt

Can you ask full cfgdayzDEFAULT.zip file? It contains all setting from lates hive. Including new remoteexec.txt and createvehicle.txt files

[Saiboogu 1]

Seems to be broken.

Battleye has renamed it to scripts_old.txt

Can you ask full cfgdayzDEFAULT.zip file? It contains all setting from lates hive. Including new remoteexec.txt and createvehicle.txt files

Battleye didn't reject it on my side, though I don't have any logging yet. It's only been up briefly, I'm still assuming for the moment that no-one tripped any detections so far. I wasn't provided with the full cfgdayzdefault.zip file - I had put a ticket in with the devs asking if I, as a managed host admin, could get access to the files for the latest scripts.txt. They said sorry, no - but here's the scripts.txt file at least.

[Qauntum 1]

I just got this a few minutes ago from a dev when I requested the latest.

http://pastebin.com/0M0dNWPf

Line 153 of that file is going to cause problems.

5 "_v addweapon \"A"+\"A1"+\"2_PM\"+\"C\"; _v addmagazine \"20R\"+\"nd"

Should surely be:

5 "_v addweapon \"A\"+\"A1\"+\"2_PM\"+\"C\"; _v addmagazine \"20R\"+\"nd"

[Saiboogu 1]

Line 153 of that file is going to cause problems.

5 "_v addweapon \"A"+\"A1"+\"2_PM\"+\"C\"; _v addmagazine \"20R\"+\"nd"

Should surely be:

5 "_v addweapon \"A\"+\"A1\"+\"2_PM\"+\"C\"; _v addmagazine \"20R\"+\"nd"

You're right there. That's what I get for trusting a file provided to me from a DayZ dev would be any more trustworthy than the dozen other random scripts.txt pastebins. Thanks, I'll make that change and see what happens.

[WestTom 1]

You're right there. That's what I get for trusting a file provided to me from a DayZ dev would be any more trustworthy than the dozen other random scripts.txt pastebins. Thanks, I'll make that change and see what happens.

Still no luck. Battleye renames to scripts_old.txt

[imf2000 1]

*EDIT*

Looks like there is a scripts.txt tailored to DayZ out there. ;) Great work.

Edited August 14, 2012 by IMF2000

[Saiboogu 1]

I had to reinstall the beta, DayZ, and Hive with my host and it finally started rejecting the scripts.txt file, so I can agree that that file doesn't work. Problem is, it also rejects the old 08-08 update I was using previously, as well. Seems something else has changed with the syntax, or there's a bug.

[$able 2]

I had to reinstall the beta, DayZ, and Hive with my host and it finally started rejecting the scripts.txt file, so I can agree that that file doesn't work. Problem is, it also rejects the old 08-08 update I was using previously, as well. Seems something else has changed with the syntax, or there's a bug.

You need to update to the latest scripts.txt provided by the DayZ team. The new BE Server fixes a bug in the scripts.txt reading that causes problems with the previous DayZ scripts.txt. To prevent mass kicks the old version is automatically renamed to scripts_old.txt.

[Saiboogu 1]

You need to update to the latest scripts.txt provided by the DayZ team. The new BE Server fixes a bug in the scripts.txt reading that causes problems with the previous DayZ scripts.txt. To prevent mass kicks the old version is automatically renamed to scripts_old.txt.

That was the problem, I was working with a file provided by the DayZ team. http://imgur.com/ihdvS Just wasn't the right one, evidently. My co-admin found the real up-to-date file somewhere last night, I'll find out where when I talk to him this morning.

Can you answer my question from the other day please? Having trouble reconciling the restriction codes with the lines in the file - they don't usually add up when I try to compare them to what gets logged, so I imagine I'm counting lines wrong somehow.

Is this a firm line-by-line match of the file or does it skip commented out lines? Does //new count as line zero, for instance, or is it ignored?

[Holmes 10]

Has anyone had issues with the new battleye features logging a bunch of items to the rpt file?

[humbleuk 1]

Trying to run JSRS sound mod with dayz & ace. (local server)

It kicks for script restriction 218 which code do i need to comment out in the scripts.txt file?

Help please?

I tried line 218 of the file but that's not it.

[PreedSwe 18]

Trying to run JSRS sound mod with dayz & ace. (local server)

It kicks for script restriction 218 which code do i need to comment out in the scripts.txt file?

Help please?

I tried line 218 of the file but that's not it.

Did you skip all the already commented out lines in scripts.txt when you counted to 218? It probably only counts the lines that are active..? Can't you also just check in the logs what the matching string was when they get kicked? Just find that in the scripts.txt?

---------- Post added at 09:57 AM ---------- Previous post was at 09:45 AM ----------

Does script detection work with beserver.dll v 1.159 and the original server version 1.62.95251?

[quatermass 1]

Since updating to the latest scripts.txt/remoteexec.tat, etc. from dayz-community-banlist, I'm getting some weird things happening on log in to my own LAN DAYZ server.

I've found quite a number of remoteexec.log type #8,#14, etc. kicks like:

29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #0 "mpi=[]execVM "playerinit.sqf""
29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #8 "mpi=[]execVM "playerinit.sqf""
29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #14 "mpi=[]execVM "playerinit.sqf""

I even get them myself when I log into my own server as admin....!

First I got a kick from BE Scripts for : "openDSInterface;", because I logged in as Admin!

Then second time I logged in, it didn't kick me when I logged in as Admin (!). But a few mins later I got a remoteexec kick for line #8: 5 "set"

(Is there ANY documentation on what these lines are suppose to protect against?)

The 3rd time I logged in, a min later, I didn't get kicked at all!

So what is up with BEC?

BEC claims it is up to date, so does BE.

Also is there a way for BE to re-load the scripts.txt, remoteexe, etc. without me having to restart the server?

:confused:

[$able 2]

Since updating to the latest scripts.txt/remoteexec.tat, etc. from dayz-community-banlist, I'm getting some weird things happening on log in to my own LAN DAYZ server.

I've found quite a number of remoteexec.log type #8,#14, etc. kicks like:

29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #0 "mpi=[]execVM "playerinit.sqf""
29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #8 "mpi=[]execVM "playerinit.sqf""
29.08.2012 15:10:12: Psychosocial (xx.84.130.80:62917) xxfcf1673bccc6b44d0b865de5ce3c9e - #14 "mpi=[]execVM "playerinit.sqf""

I even get them myself when I log into my own server as admin....!

First I got a kick from BE Scripts for : "openDSInterface;", because I logged in as Admin!

Then second time I logged in, it didn't kick me when I logged in as Admin (!). But a few mins later I got a remoteexec kick for line #8: 5 "set"

(Is there ANY documentation on what these lines are suppose to protect against?)

The 3rd time I logged in, a min later, I didn't get kicked at all!

So what is up with BEC?

BEC claims it is up to date, so does BE.

Also is there a way for BE to re-load the scripts.txt, remoteexe, etc. without me having to restart the server?

:confused:

Wrong thread.

Anyway, this has nothing to do with BE being bugged. Obviously certain code is executed for players joining your server, so maybe you are running another mod beside DayZ? If you check DayZ's remoteexec.txt, you can see that line 9 (5 "play") and line 15 (5 "init") are the offending entries here (they are contained in the logged code). Note that the restriction # is usually line number - 1. The kick for going to the admin interface is a trick implemented by the DayZ team to prevent cheaters from loading their scripts that way.

[.kju 3245]

I'd like to start a discussion about possible future improvements in BattlEye and beyond.

While the new BE logging and server side script blocking is a big step forward,

1) it is less useful and harder to get right/to set up for normal public play with various mission types

2) game destroying hacks wasting an x hour game with no (easy) way for revert before the event (think of Warfare)

Some thoughts we have gathered so far:

• Admin (logged in, not voted) can enter an spectator mode to watch all players from first person view or observer perspective to see if anything is fishy
  
• Friendly fire disabled (in general/certain areas/for the first x minutes/for new players) to avoid excessive team killing
  
• Detecting certain events (player beaming, scripting hacks but with the ability to revert the effects, like on killed event check if valid an otherwise revive instantly)
  
• Enhanced logging (player movement, kills, etc) to detect non valid behavior
  

Thoughts or other ideas?

(PS: Again these may or may not be doable with BattlEye, but relate to it and the whole anti cheat/game destroying topic)

[Fireball 16]

I rather think the BE script blocking should be configurable per mission, so that a script blocking definition file can be delivered along with the mission (maybe even tool-generated), which contains all important excludes which are used by the mission, so the expressions are not global. This would help a lot already, from what I've heard from other server admins, when the enhanced script logging/blocking feature was released.

[.kju 3245]

Excellent point Fireball!

A few more thoughts on the script blocking:

# regular expression support (perl derived style)

# it'd great if there was a way to differentiate between scripting commands from game files, user addons, from the mission and finally user induced commands

(however probably only BI could do that, if at all - probably something along the lines of code signing)

[Prodavec 10]

[*] Admin (logged in, not voted) can enter an spectator mode to watch all players from first person view or observer perspective to see if anything is fishy

What about protection against admins that regulary abuse their power and/or their friends? I don't want to spot my position and reveal my (and my squad) unique tactics for some douchebags that just have BE rcon password. Me and my mates a few times were "tested" by shitty admins on leggit actions with scripted observer. In most cases it was ruined game even all is ok. So if it will be implemented by BI using some Editor Module (for example) the list of possible negative factors will grow:

1. Abusive admins which use BE for ban players because of they are just admins and may break their own rules.

2. Abusive admins which use addons with private keys/signatures to add admin power (legit hacks) and may hack on their own server.

3. Abusive admins which add some scripts in the mission with UID filter to add admin hacking power (for example +$1000000 if it's Life or spawn TWS stuff for "debug purposes" if it's some of kind TvT/PvP mission)

4. Hackers

5. And admin spectator, with some module can be used by ANY admin/admin friend, even he's a full douchbag.

By my experience admins make much more damage than hackers. The hacker can ruine single mission, admin can ruin the whole game for few players.

No protection for single player and/or squads?

Edited September 2, 2012 by Prodavec

[.kju 3245]

There is only one solution to that: Information.

This means you see when the admin uses the spectator mode, what keys are permitted, if someone uses addons and which, etc.

In addition ultimately you can just join another server or run your own. Arma is far to open to avoid any abuse by an admin/server owner.

So you see your points do not negate the need for such system. It only highlights that it needs to be done right.