Raikiri (bc49e1644d8e354065789369d8b4c32d) has been kicked by BattlEye: PublicVariable Value Restric

U

UrbanSkaters

Valued Member!
Since the 1.7.6 update I've had 3 major hacks, which is 3 more than I had with 1.7.5 .. The last hack really screwed stuff up, but I can't for the life of me figure out what he did, or what I can do to prevent it in the future. I actually added the GUID to my ban list, Battle Eye did kick the player but only after they'd managed to execute the following script twice.. I had to rollback my database and reupload a new pbo to fix it :(


Raikiri (bc49e1644d8e354065789369d8b4c32d) has been kicked by BattlEye: PublicVariable Value Restriction #183
00:25:29 - 1 98.254.131.205:3308 110 bc49e1644d8e354065789369d8b4c32d(OK) Raikiri

When my players tried to log back in , this is what they got:
00:36:20 - (Unknown) player: No entry 'bin\config.bin/CfgMarkerBrushes. "norrnRACarUp" addPublicVariableEventHandler {call compile markerText "WHY_YOU_NO_LOVE_ME_AYNMORE"; }; cod

There were also loads of entries like this coming up on RCON:

00:25:59 - SetDamage Log: #1 Raikiri (bc49e1644d8e354065789369d8b4c32d) - #2 1.100000 15:300 z_soldier

What's really worrying about this, is even though battle eye was kicking him, he still managed to execute some script ... ?
 
UrbanSkaters said:
Since the 1.7.6 update I've had 3 major hacks, which is 3 more than I had with 1.7.5 .. The last hack really screwed stuff up, but I can't for the life of me figure out what he did, or what I can do to prevent it in the future. I actually added the GUID to my ban list, Battle Eye did kick the player but only after they'd managed to execute the following script twice.. I had to rollback my database and reupload a new pbo to fix it :(


Raikiri (bc49e1644d8e354065789369d8b4c32d) has been kicked by BattlEye: PublicVariable Value Restriction #183
00:25:29 - 1 98.254.131.205:3308 110 bc49e1644d8e354065789369d8b4c32d(OK) Raikiri

When my players tried to log back in , this is what they got:
00:36:20 - (Unknown) player: No entry 'bin\config.bin/CfgMarkerBrushes. "norrnRACarUp" addPublicVariableEventHandler {call compile markerText "WHY_YOU_NO_LOVE_ME_AYNMORE"; }; cod

There were also loads of entries like this coming up on RCON:

00:25:59 - SetDamage Log: #1 Raikiri (bc49e1644d8e354065789369d8b4c32d) - #2 1.100000 15:300 z_soldier

What's really worrying about this, is even though battle eye was kicking him, he still managed to execute some script ... ?
Click to expand...


I've been looking at your post trying to decide how best to approach it..

I'd like to preface with there is nothing we can do to prevent the constantly evolving cheats from executing on our servers. We can/do/will kick after execution thanks to BattlEye filters and ban accordingly either manually of with the help of some software. I think the best way to approach your situation would be for me to speak with you. PM me if you'd like to and I can walk you though how to handle this situation and overall best practices. I'm am left wondering why you felt the need to rollback your db and rebuild your *.pbo?

For the sake of the thread the kick message tells you where (PublicVariable) to find what the cheater did. Search the GUID (bc49e1644d8e354065789369d8b4c32d) against your PublicVariable.log and paste back the results so we can discuss it further.
 
To answer you main questions:

" I rolled back the database so that the people who had been killed and the vehicles that had been damaged, were put back to their original state? I obviously forgot to mention that part, I always assume people can read my mind :p

Just added: Actually I did mention this (00:25:59 - SetDamage Log: #1 Raikiri (bc49e1644d8e354065789369d8b4c32d) - #2 1.100000 15:300 z_soldier) . So I'm wondering now why you would think a database rollback would be a strange move?

Users were getting the "no entry" error message even after a reboot, the only solution that worked was re-uploading my custom pbo again. Why that worked, I don't know. But it did and I was even advised to do this by the dayz.st staff, next time it happens. They said nothing can be done and that I did exactly what they would have done.... "

I'm not sure what you are asking me from this point on though, maybe I'm just too tired and need to get some sleep before reading this again. However there is no need to share my log entries with you at this point as we have since updated our BE scripts file to combat this attack in the future (i'm presuming, as there loads of updated filters that needed changing/adding), the script kiddie managed to bypass one filter to execute another (possibly?), it was that simple in the end. As you say, there is not much we can do about it.

Also, if you don't mind me asking. Who are you? I say this in a nice way, not being rude or anything (but your account is pretty new). You talk like you're some authority on the matter and before I discuss privately or post extra log information, I'd like to know I'm not being drawn into a social engineering trap :p (no disrespect intended).
 
Just went to check the logs as you suggested and found that the log file is overwritten after each reboot (Gotcha AntiHack doesn't seem to record this information either for some reason). So anyway, I'll keep this in mind for the next time and grab a copy before I rebooted!

Update: Added the ' 2"" ' line to the txt files as advised in the gotcha faq. Should now be logging.
 
UrbanSkaters said:
To answer you main questions:

" I rolled back the database so that the people who had been killed and the vehicles that had been damaged, were put back to their original state? I obviously forgot to mention that part, I always assume people can read my mind :p

Just added: Actually I did mention this (00:25:59 - SetDamage Log: #1 Raikiri (bc49e1644d8e354065789369d8b4c32d) - #2 1.100000 15:300 z_soldier) . So I'm wondering now why you would think a database rollback would be a strange move?

Users were getting the "no entry" error message even after a reboot, the only solution that worked was re-uploading my custom pbo again. Why that worked, I don't know. But it did and I was even advised to do this by the dayz.st staff, next time it happens. They said nothing can be done and that I did exactly what they would have done.... "

I'm not sure what you are asking me from this point on though, maybe I'm just too tired and need to get some sleep before reading this again. However there is no need to share my log entries with you at this point as we have since updated our BE scripts file to combat this attack in the future (i'm presuming, as there loads of updated filters that needed changing/adding), the script kiddie managed to bypass one filter to execute another (possibly?), it was that simple in the end. As you say, there is not much we can do about it.

Also, if you don't mind me asking. Who are you? I say this in a nice way, not being rude or anything (but your account is pretty new). You talk like you're some authority on the matter and before I discuss privately or post extra log information, I'd like to know I'm not being drawn into a social engineering trap :p (no disrespect intended).
Click to expand...
UrbanSkaters said:
Just went to check the logs as you suggested and found that the log file is overwritten after each reboot (Gotcha AntiHack doesn't seem to record this information either for some reason). So anyway, I'll keep this in mind for the next time and grab a copy before I rebooted!

Update: Added the ' 2"" ' line to the txt files as advised in the gotcha faq. Should now be logging.
Click to expand...

Yeah, you didn't really explain the extent of griefing, IMO a rollback is a last resort action justified by specific events. A number of things factor into a decision like that but I'm sure you did right by your players.

I've never seen a "no entry" message on this execution, our players get the "something went wrong" time out. I can't even begin to understand why you needed to re-upload your *.pbo, that makes absolutely no sense. What does "reboot" mean to you in regards to your server?

I asked you to share your logs so other admins who might stumble on to this thread could potentially benefit. Your response (no disrespect intended) is an example of an administrator who could benefit from reviewing the logs. Familiarization with skiddie methods goes a long way in regards to prevention. The recent BE filter updates won't effect the entries we're seeing but I'm sure they protect against something Dwarden is seeing on Honeypot servers or his own.. For the most part the scripts/executions bypass Battleye, if fully protected/undetected/bypassed there isn't anything for the filter to run against.

I'm just an admin like yourself, unfortunately I have some practice with cheaters. If you Google us you'll see some of my posts, while I don't post much here I've been at this a while now..

Logs are everything IMO. Scanning our logs gives us an edge against the skiddies, if there's something to be found we will find it. Also keeping the logs allows us to be accountable for our actions and learn from any potential mistakes. I was never really impressed with Gotcha, if I recall that 2 "" spams the specified filters raw output to the console. If you run BEC I think it will bloat those logs.. But if that allows you to log then it's worth it.
 
You must log in or register to reply here.
Back
Top