BattlEye: make it work for the common gamer

[AgentRev 22]

only solution would be remove every single script command which relay over network from client into MP space from the scripting

in such case forget about any backward compability ...

(pure example removal of setVehicleInit which per say, has no effect as other ways around exist, yet that step alone breaks like 25% old missions)

Well, not every command, but removing the old createUnit from OFP that has an init parameter would be a good start. I can't really think of a legitimate use for it, compared to the new createUnit introduced in ARMA.

Another problem that needs to be tackled is the BIS_fnc_MP function. The only way it can be filtered is via publicVariableVal.txt, which doesn't offer a lot of flexibility. I've had to modify the code from BIS_fnc_MP, BIS_fnc_MPexec, BIS_fnc_initMultiplayer, and recompile them into new functions just to do text filtering on BIS_fnc_MP_packet. Without any filtering, this function is a wide-open backdoor. Maybe a "BIS_fnc_MP_packet.txt" filter for BattlEye would be in good order?

Since I had my new set of "fnc_MP" functions, I tried to block BIS_fnc_MP altogether, but I discovered that some scripts from the game core actually use BIS_fnc_MP to call other functions across the network, regardless of the mission, which prevents certain things from executing if BIS_fnc_MP_packet is tampered with. Here's a list of some:

• BIS_fnc_kbTellLocal
  
• BIS_fnc_effectKilledAirDestruction
  
• BIS_fnc_effectKilledSecondaries
  
• BIS_fnc_effectKilledAirDestructionStage2
  
• BIS_fnc_tridentHandleDamage
  
• BIS_fnc_tridentHandleDamage_server
  
• BIS_fnc_showNotification
  
• BIS_fnc_taskSetState
  

I think the problems with network communications are becoming clear at this point. We need a new native function for remote procedure calling. Something like BIS_fnc_MP, but that doesn't rely on public variables (by doing network transfers outside of the scripting engine), doesn't allow code types in its arguments, and can only call defined functions, with separate BattlEye filters for both the arguments and function name to call.

[mlewis1969 1]

@Dwarden: Well you kinda lumped me into the same category as LW1 and my views and opinions are not shared by him. I can't remember being warned about arguments dealing with these same issues although my views are popular and shared here by others. It's true that I do not agree with the way things are being handled in relation to Arma 3 back door to hackers but that's only my opinion and opinions apparently mean nothing here. I don't want to be blamed for wrongdoing if I have not said or done anything so please warn me if my words are offensive or taken out of content.

[$able 2]

no sir, its not stupid at all. if i make a video showing the BE version and the battleye config. and i show in the video that the server ill'hack in is running BE and its not able to detect me, even with the correct script filters, youll have a clear proof at how BE sucks.

obviously at that point you won't have more theories to brings to defend BE...so i im just speculating on what you can come with to defend BIS games you brave white knights.

That's a funny argument. You are saying that because BE might not detect 100% of all hacks it sucks. Well, then obviously any anti-cheat sucks. Plus what you are talking about is a bypass, so of course BE's anti-script features would not work at that very moment. But I guess the fact that you will likely get banned a few hours/days later when using such a bypass doesn't count, right?

---------- Post added at 00:42 ---------- Previous post was at 00:30 ----------

andrey: those 100.000+ bans are inclusive of dayz mod. we litterally had millions of players for it.

so that number is a good example of the BE efficiency?

"Millions" sounds like quite a lot. Did you ever check the player count on the DayZ website? According to that number nearly 150,000 global bans are not that bad I would say (but who am I to judge this?), considering that the vast majority of cheaters plays DayZ.

Btw, in case you haven't read my previous posts, I always said myself that BE is totally ineffective in OA since cheaters hardly care about getting constantly banned because of the unlimited supply of cheap stolen cd-keys. Fortunately that's no longer the case in Arma 3.

[terox 316]

Specific filters for servers that run 1 mission, such as wasteland can be useful.

The filters would, when written correctly basically block any network code that the mission doesn't use

However if your server runs lots of different missions, forget manually writing filters for them, it would be a never ending task.

Battleye by itself does a pretty good job at keeping the idiots at bay

and the type of servers the idiots want to have their fun on are the typically public play missions such as wastelands

Am wondering if it would be possible for a system that reads all the code on the mission.pbo installed on the server and then automatically whitelist's the networking commands and the variables used in that mission

for example something like if( command == "Publicvariable") then {add to whitelist the string following "Publicvariable"};

How this would cope with a dynamically created variable using compile format, would be an additional issue to work around

or alternatively when a mission is saved in the editor, some internal engine function creates a filter.txt specific for that mission and saves it within the mission.pbo for battleye to read

just a thought, probably a lot of work and have no idea if its doable

and then add to that code from addons and mods ............................

Edited August 4, 2013 by Terox

[Dwarden 1125]

Well, not every command, but removing the old createUnit from OFP that has an init parameter would be a good start. I can't really think of a legitimate use for it, compared to the new createUnit introduced in ARMA.

it's way more commands than most of You realize :(

[AgentRev 22]

it's way more commands than most of You realize :(

I am talking about commands that send direct code for execution on all clients, not every command that has a global MP effect. So far, I only know the old createUnit with the init field, MP event handlers, and BIS_fnc_MP. Some hacks are calling the old createUnit for every cheat function, in order to send crap to other clients or the server.

Even if it can be blocked with [5 ""] in remoteExec.txt, I don't think many server owners are aware of it, and I can't think of a legit purpose for using the old createUnit versus the new createUnit, so it would be best to just remove it altogether, just like setVehicleInit was removed for the same reasons.

[*LK1* 10]

That's a funny argument. You are saying that because BE might not detect 100% of all hacks it sucks.

nope.

"Millions" sounds like quite a lot. Did you ever check the player count on the DayZ website? According to that number nearly 150,000 global bans are not that bad I would say (but who am I to judge this?), considering that the vast majority of cheaters plays DayZ.

millions could sound queit a lot but dayz had more than 1 million unique players.

http://dayzmod.com/

unique players: 1,737,741

however, i want to be honest: i just trolled you a bit guys. i dont have problems with BE which seems to works good nowadays. the script filters works good and its a long time that i dont see cheaters in game despite the huge amount of hours im still spending in arma 3.

keep up the good work, long live BE.

[stefeman 1]

You can disagree as much as you want, but it's a fact that BE is better at detecting cheaters than PB/VAC. As people said before, you should be mad at BI, not at BE.

lol. tell me more about these facts. please.

however i never decide to compare vac and PB in my previous post. i consider a typical funboy battlefield fighting and arguing for which game has the best anti cheat-system.

This made me facepalm so hard that i had to register in order to post here.

You sir are an idiot.. As already posted in some earlier page of this thread, go and choose one of the private/paid hacksites.

-removed-

Pick your liking and enjoy the daily global bans. If you ask from me, BE does pretty damn good job compared to anything else out there in terms of detecting.

The real issue is the hacks that are installed into servers and used by server admins.

Edited August 5, 2013 by PurePassion
No mentioning of warez/hacking related sites etc please!

[eddieck 10]

however, i want to be honest: i just trolled you a bit guys. i dont have problems with BE which seems to works good nowadays. the script filters works good and its a long time that i dont see cheaters in game despite the huge amount of hours im still spending in arma 3.

Related: http://img.photobucket.com/albums/v514/Benny1/what-trolls-want-you-to-believe.png

The real issue is the hacks that are installed into servers and used by server admins. (such as blurgaming "anticheat" which was actually made by script kiddie "infistar" and his gang).

I agree, this is a real problem. I have long been in favor of absolutely no in-game "admin tools" (AKA cheats) because they always get used for other purposes.

[*LK1* 10]

This made me facepalm so hard that i had to register in order to post here.

You sir are an idiot.. As already posted in some earlier page of this thread, go and choose one of the private/paid hacksites.

-removed-

Pick your liking and enjoy the daily global bans. If you ask from me, BE does pretty damn good job compared to anything else out there in terms of detecting.

The real issue is the hacks that are installed into servers and used by server admins.

reported. 2/10. making fakes account is not tollerated. if you wish to troll then dont hide yourself.

mister "oh the facepalm is so big that i decide to register"...:rolleyes:

[stefeman 1]

reported. 2/10. making fakes account is not tollerated. if you wish to troll then dont hide yourself.

mister "oh the facepalm is so big that i decide to register"...:rolleyes:

Me, Sorry but i really registered here after seeing your trolling posts :P

[*LK1* 10]

sure...

[Dwarden 1125]

I am talking about commands that send direct code for execution on all clients, not every command that has a global MP effect. So far, I only know the old createUnit with the init field, MP event handlers, and BIS_fnc_MP. Some hacks are calling the old createUnit for every cheat function, in order to send crap to other clients or the server.

Even if it can be blocked with [5 ""] in remoteExec.txt, I don't think many server owners are aware of it, and I can't think of a legit purpose for using the old createUnit versus the new createUnit, so it would be best to just remove it altogether, just like setVehicleInit was removed for the same reasons.

ye, but the problem is that exploitable are way more commands than you realize ...

[eddieck 10]

ye, but the problem is that exploitable are way more commands than you realize ...

... which is just more reason they (eventually, at least) need to be completely removed.

I don't know what your current plans are for an SQF alternative, but if that's ever going to happen (I know one of the mods in the BI livestream in June said JVM was still happening, but considering the recent news I'm not holding my breath for that), that's when you really should consider making some big changes. Consider it an opportunity for a fresh start - you'll be maintaining the SQF APIs anyway for backwards compatibility, so those can be kept as they are, but the newer one can enforce proper security practices.

[Dwarden 1125]

... which is just more reason they (eventually, at least) need to be completely removed.

I don't know what your current plans are for an SQF alternative, but if that's ever going to happen (I know one of the mods in the BI livestream in June said JVM was still happening, but considering the recent news I'm not holding my breath for that), that's when you really should consider making some big changes. Consider it an opportunity for a fresh start - you'll be maintaining the SQF APIs anyway for backwards compatibility, so those can be kept as they are, but the newer one can enforce proper security practices.

we have some plan, some of problematic commands may turn quite simple to secure ... others might need more headbanging ... but definitely we have some 'list' of things to solve ;)

[eddieck 10]

we have some plan, some of problematic commands may turn quite simple to secure ... others might need more headbanging ... but definitely we have some 'list' of things to solve ;)

Thank you. I'm glad to see some work is still being done in this area, as this is quite honestly one of the most important issues remaining with this game/series. (Gameplay issues are one thing; a fundamental flaw in the engine is another.)