Introducing Server-side Event Logging/Blocking

[jedra 11]

Those are the normal BIS effect scripts (in ca.pbo) which are executed as soon as an air vehicle is killed (and the setVehicleInit in one or more of those functions also causes the "fire in the sky" bug...).

Xeno

OK - that's good to know. Thanks.

[TSAndrey 1]

Hey guys, is BE going to detect a custom skin as a cheat?

Edited January 2, 2013 by TSAndrey

[byteslam 10]

21.08.2012 04:53:48: player (213.xxx.94.xxx:64409) GUIDGUIDGUIDGUID - #121 "y']; _dummy = [_this, "CA_VO_ToggleAll"] call compile preprocessfilelinenumbers "\ca\ui\scripts\Hide"

21.08.2012 04:53:49: player (213.xxx.94.xxx:64409) GUIDGUIDGUIDGUID - #121 "y']; _dummy = [_this, "CA_VO_ToggleAll"] call compile preprocessfilelinenumbers "\ca\ui\scripts\Hide"

after this two lines, a lot of commands have been executed by this user but only as #132 "isDedicated" .... is it a way to hide illegal script execution?

[tonygrunt 10]

Hey guys, is BE going to detected a custom skin as a cheat?

No, custom face is a function of ArmA but a server can be setup to kick you if you have one or if you exceed a byte size.

[symptom 1]

I know nothing about coding, and I need help with protecting my DayZ Server with this new addition. I use Defcon Servers as a host. Can you help me??

Skype me please..... symptomco

Edited August 22, 2012 by Symptom

[ShadowDuke 1]

@TSAndrey

you get definitely kicked for because its not in the allowed dayz_code for (allowed) skins.

[hellfire257 3]

I'm not really sure I understand how this works. Does it simply log instances of the command(s)?

[xksimon 1]

19.08.2012 12:35:39: Gay_Man (183.26.246.162:44217) ed542a25e829c888c618210641508b30 - #0 "if (isnil ("bInvisibleOn")) then {objMYPlayer hideObject true;};"

19.08.2012 12:35:39: Gay_Man (183.26.246.162:44217) ed542a25e829c888c618210641508b30 - #6 "if (isnil ("bInvisibleOn")) then {objMYPlayer hideObject true;};"

19.08.2012 16:58:09: Murk (207.224.124.197:2304) b66b32b9347a29096e17312d95e78f04 - #0 "

if (isServer) then {

_object = createVehicle ['UH1H_DZ', [12403.2, 4372.4, 0], [], 0, 'CAN_COLLIDE'];

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

dayz_serverObjectMonitor set [count dayz_serverObjectMonitor, _object];

_uid = _object call dayz_object"

19.08.2012 16:58:09: Murk (207.224.124.197:2304) b66b32b9347a29096e17312d95e78f04 - #1 "403.2, 4372.4, 0], [], 0, 'CAN_COLLIDE'];

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

dayz_serverObjectMonitor set [count dayz_serverObjectMonitor, _object];

_uid = _object call dayz_objectUID;

_object setVariable ['ObjectUID', _uid, true];

_object s"

Gay_Man and Murk are cheater or not???

[hellfire257 3]

Yes, they are.

[BlackSheep 0]

Are there filters for ACE server? Or I do not need?

[fenechka 10]

25.08.2012 20:24:11: Sonur (128.74.60.155:2304) cbed55a226521f5a60bd031cad792ded - #0 "ParachuteWest" 21:1220 [2458,9802,381]

parachute in DayZ ?

or cheater ?

[democore 4]

I've written my own createvehicle.txt and remoteexec.txt but they appear to be overritten each day aroud 14:00 and on each server restart. Is there a way to stop that from happening?

And also is there a possibility to set the file via rcon? that would be really nice for people who have no ftp acces to their dayz server :)

But anyway great work so far!!

[$able 2]

FYI, many cheaters now use "publicVariable" to overwrite certain game variables/symbols with their own script code and remotely execute it that way. That can completely bypass the remoteexec.txt scans right now.

I will work with Ondřej/Suma to provide a solution that entirely fixes this exploit ASAP.

[eddieck 10]

I will work with Ondřej/Suma to provide a solution that entirely fixes this exploit ASAP.

While I (and hopefully others) certainly appreciate that you're working on this, this is hardly an exploit in either BE or the game, and the solution should be left up to mission makers. There is no reason any mission should be executing PV'd strings.

A PV log could still be a nice feature to detect clients altering data that they are not supposed to alter, but the better solution IMO would be for BIS to add a "caller" argument for PVEHs with the player that sent the PV.

[zyklone 1]

While I (and hopefully others) certainly appreciate that you're working on this, this is hardly an exploit in either BE or the game, and the solution should be left up to mission makers. There is no reason any mission should be executing PV'd strings.

A PV log could still be a nice feature to detect clients altering data that they are not supposed to alter, but the better solution IMO would be for BIS to add a "caller" argument for PVEHs with the player that sent the PV.

Sure there is.

It's the obvious way to provide a generic network communication system..

But i certainly agree that the correct solution is to provide the source client id to the event handler.

Ideally the PV variables would exist in a separate variable space also to prevent overwriting of other globals.

(This is basically what old-style CTI money cheats did, they just PVed a new sum for that player)

Perhaps allow missions to enable the use of public variable namespace in the mission config...

[$able 2]

While I (and hopefully others) certainly appreciate that you're working on this, this is hardly an exploit in either BE or the game, and the solution should be left up to mission makers. There is no reason any mission should be executing PV'd strings.

A PV log could still be a nice feature to detect clients altering data that they are not supposed to alter, but the better solution IMO would be for BIS to add a "caller" argument for PVEHs with the player that sent the PV.

This is only partially true. Cheaters can overwrite normal functions with "publicVariable" as well, one public example being the BIS_Effects_* functions, so a mission that explicitly executes code sent via PV isn't even needed.

Anyway, I will forward your suggestion regarding PVEHs to the developers.

[eddieck 10]

This is only partially true. Cheaters can overwrite normal functions with "publicVariable" as well, one public example being the BIS_Effects_* functions, so a mission that explicitly executes code sent via PV isn't even needed.

Good point. I hadn't even thought about that.

Anyway, I will forward your suggestion regarding PVEHs to the developers.

Thanks!

[xksimon 1]

well hello everyone, first of all, another suspected cheater log:

24.08.2012 11:40:53: Ferghus (70.71.19.59:2304) 77cb23dd383e8600d57ff0db21efe099 - #0 "if (isnil ("bInvisibleOn")) then {objMYPlayer hideObject true;};"

24.08.2012 11:40:53: Ferghus (70.71.19.59:2304) 77cb23dd383e8600d57ff0db21efe099 - #8 "if (isnil ("bInvisibleOn")) then {objMYPlayer hideObject true;};"

24.08.2012 11:44:58: Ferghus (70.71.19.59:2304) 77cb23dd383e8600d57ff0db21efe099 - #0 "if (name player == "DK") then { (vehicle player) setDamage 1;};"

24.08.2012 11:44:58: Ferghus (70.71.19.59:2304) 77cb23dd383e8600d57ff0db21efe099 - #7 "if (name player == "DK") then { (vehicle player) setDamage 1;};"

another questions is that, "beeeh = this" & BIS_Effects_AirDestruction shouldn't be some kind of cheating, right?

I was using all txt files from http://code.google.com/p/dayz-community-banlist/source/browse/#git%2Ffilters

is that the currently the best and the most effective one to stop cheater for BE right now??

[andreasb 1]

I've written my own createvehicle.txt and remoteexec.txt but they appear to be overritten each day aroud 14:00 and on each server restart. Is there a way to stop that from happening?

And also is there a possibility to set the file via rcon? that would be really nice for people who have no ftp acces to their dayz server :)

But anyway great work so far!!

Tried writeprotection?

[democore 4]

Tried writeprotection?

Thanks for the reply.

Yes i did, but the provider gamed.de doesnt let you set write protection for file -.-"

Setting these files via rcon would be perfectly fine too (i mean setting the content of createvehicle.txt etc.).. But i dont think that i will see that soon :/

Edited August 31, 2012 by DemoCore

[hohlraum 1]

I hope you figure something out soon.

We had someone inject something into the server that ran continuously for hours injecting code into clients connecting which made them run something that would cause a script restriction. In essence automatically kicking everyone who connected.

[XmarksTheScot 1]

BE Server v1.156 in combination with the latest OA 1.62 ......

Yet again new features that us Arma 2 only server managers have to cross fingers and hope that they finally get round to patching us to. Meanwhile we suffer constant hacking and script kiddies attacking our servers because BI make it SOOOOO easy just to DL a new copy of A2free with a brand spanking new GUID so they can carry on after you ban them.

[Gonobob 1]

Hi all, i have a question, help please.

i have a script for teleporting(he works great)

it looks like this

_pos = [_this select 0, _this select 1,_this select 2];

if ((vehicle player isKindOf "Air")) then{

(vehicle player) setpos [_pos select 0, _pos select 1, 100];

player setVariable["lastPos",0, true];

}else

{

(vehicle player) setpos [_pos select 0, _pos select 1, 0];

player setVariable["lastPos",1];

};

openMap [false, false];

onMapSingleClick "";

and how can i block this in my server???

what i need to do with script.txt or remoteexec.txt or createvehicle.txt or somwere else to block this s**t!? thx

i think need to block function SetPos but how can i do this?

sorry for my bad english

Edited September 3, 2012 by Gonobob

[zyklone 1]

I hope you figure something out soon.

We had someone inject something into the server that ran continuously for hours injecting code into clients connecting which made them run something that would cause a script restriction. In essence automatically kicking everyone who connected.

Unfortunately public variable can be used to get others kicked/banned right now.

Not much to do until a new battleye is released with PV fixes..

[$able 2]

BE Server v1.162 in combination with OA beta server v1.62.96584 provides protection against remote code execution via "publicVariable" and its variants.

See the first post for more information.