madkowa@gmail.com

DayZ Anti-Hax is a very simple server-side console application for automatically banning hackers from a DayZ server. Utilizing some of the new features first introduced with the latest BattlEye update (v1.158) and ArmA 2 OA beta patch 95883, DayZ Anti-Hax parses server logs for only the most obvious hacker behavior and adds those deemed nefarious to the server's ban list. When used in combination with Battleye Extended Controls, which can automatically reload a server's ban list while it is running, this is a completely automated solution that requires little to no maintenance, making DayZ Anti-Hax an extremely useful tool when used in combination with good 'ol fashion manual log combing. Project Page on Google Code: http://code.google.c.../dayz-anti-hax/ Original Reddit Post: http://www.reddit.co...simple_console/ Before asking a question here, please read the FAQ!

Hello, This is (hopefully) a quick question: how would I go about setting up two completely separate DayZ server instances on the same dedicated server box if I installed ArmA 2 and ArmA 2 OA via Steam? Is this possible under one Steam account with those games assigned to it? Would I have to purchase the games again under a different Steam account? Thanks in advance for any assistance. :)

Sounds like you have a bone to pick with the guys running the DayZ Community Banlist, not the developers of DayZ Anti-Hax. Take this issue up with them, or continue to complain here where no one can help you and talk shit to people who are just trying to make your server a better place to play. Your choice.

Not entirely true; if the managed server provider is willing to have an instance of the parser run on a per-server basis, which is certainly possible, then it can be done. The problem is some providers don't understand this or simply aren't willing to do so.

I am indeed busy and unable to tackle any of this right now, but I am more than willing to add you as an administrator of the project on Google Code so you can make your own commits and submit your own zipped-up downloads for people to enjoy. Private message me with your primary email address, ideally a gmail one, and we can discuss this further. Thanks.

I actually do not automatically unban folks who were at one time banned on the DayZ Community Banlist, but that feature was planned -- and the solution would be rather easy. Again though, my time is limited as of late and my own server is likely going down sometime this month for a while, which makes development of this solution quite difficult. That multi-bans.txt solution sounds great and would certainly save everyone a lot of headaches...

The set of "bad" scripts intersects with the set of "good" scripts, which makes the type of detection I believe you're describing very difficult. If it was just the matter of filtering out the "bad" things and leaving the "good" or filtering out everything that isn't "good", this tool wouldn't be very useful at all; the problem is it is hard to determine what is "good" and what is "bad". I hope that made sense. It sounded a lot better in my head. I'm glad to hear you managed to unban yourself and I'm sorry the process is rather annoying. Do note though that DayZ Anti-Hax does not submit/push bans to the DayZ Community Banlist, it simply receives/pulls them, so being banned from a server running DayZ Anti-Hax alone (including your own) does not necessarily and, in fact, does not at all mean your GUID was added to the DayZ Community Banlist. Frankly, I'd rather see some of DayZ Anti-Hax's features rolled up into BattlEye...at least the ability to ban players for suspected hacks instead of just preventing them from executing and kicking the offending player. That would make development of this tool significantly easier and the solution a lot cleaner.

I'm not actively developing DayZ Anti-Hax at the moment, but seeing as this appears to be a new feature with one of the latest beta patches, it should take some time for servers to transition over to this anyway. This is definitely something I'd like to see considered for a future release though...I just haven't been monitoring my server or keeping up with DayZ in general as of late, so I don't feel comfortable fiddling around with my own source code at this point. Great suggestion though, thank you -- hopefully someone else has a look at it in the meantime.

'Object Access Flooding' detection is an experimental feature that may result in false-positives during heavy desync and when clients are executing many actions at once. Any servers frequently encountering this issue are advised to disable the feature by editing DayZ Anti-Hax's 'config.cfg' file and setting 'shouldCheckForFlooding' to 'false' instead of 'true' (it is enabled by default). Keep in mind this will make you more susceptible to hackers though.

Assuming DayZ Anti-Hax has been installed properly, it could be related to this issue posted about a week ago, in which case I fear there's very little that can be done until the BattlEye guys step up their game yet again, because it seems the script kiddies might be one step ahead of us (again). I'd be surprised if this was true. Are you seeing the items appear in createvehicle.log and they just aren't being banned or does stuff not appear in the log and you're seeing the items in-game? If it's the latter, I'm afraid there's very little me or anyone else can do...

It's when a client attempts to remotely execute code on the server or another client (e.g. spawning hacked weapons). Often times, this is intentional and malicious. DayZ Anti-Hax filters out some possible false-positive detections, then bans anyone caught attempting any type of remote code execution. It is only since recent BattlEye updates and ArmA II OA beta patches that this has become possible.

This is certainly possible as it hasn't been updated in some time, however I would strongly advise only using the file I include with each major release of DayZ Anti-Hax. Using filters from anywhere else, including the DayZ Community Banlist, can result in false-positives and other unintended consequences. It is, however, safe to use any scripts.txt file you please, as neither scripts.txt nor scripts.log is touched in any way by my parser. I'm quite busy as of late and probably won't have time to look into any such issues for a while. The solution is open-source, so I would appreciate it if someone who knows C# and is familiar with advanced DayZ server administration could take over things for now...

Sup. I created DayZ Anti-Hax. The system isn't perfect, and thus false-positives can happen from time to time, but assuming DayZ Anti-Hax is installed and configured properly -- ideally right after a fresh server install so that things like these hacked weapon boxes don't exist on the map prior to the parser being run -- everything should work as intended. I'm sorry anyone has had any problems using the system, but as I've mentioned many of times, it isn't for everyone. Anyway, that's my two cents. I'll look into this, but to be honest, 'Remote Code Execution' is one of the most sure-fire detections I have available to me and has never been proven wrong before...

First off, stop the DayZ Anti-Hax parser, then proceed to do as you did before, removing the applicable entries in bans.txt and remoteexec.log and/or createvehicle.log according to what got those users banned, which is listed in DayZAntiHax.log. After you've done this, restart the parser. If they are still banned, you've done something wrong. If they are banned *again* as soon as they join or something, which is entirely different, check DayZAntiHax.log for the time, date and log file to look in to see what's getting them banned and report that to me either here or in a private message and I'll try to help you out.

You should submit a support ticket to your host explaining what you're looking to do and including links to this thread as well as our Google Code page, which includes a download link and instructions/usage guide. It is possible to use this solution under a manager server and not a dedicated one as long as your provider is willing to do so, as the solution is entirely automated when used in conjunction with Battleye Extended Controls (BEC), as explained in the installation instructions.

A blind spot? You just provided a perfect example yourself of why parsing scripts.log can be quite dangerous, which is why my parser doesn't do it. Also, the log flooding detection can be turned off simply by changing a value in the included configuration file, it's just turned on by default as I've never had a problem with it.

If the first block of stuff you posted was in scripts.log (i.e. what appeared to be from all players), which I strongly suspect it was based on what you've explained in your post, anyone who uses this tool is fine, as the parser does not ever read/write from/to scripts.txt or scripts.log. At this time, only remoteexec.log and createvehicle.log are parsed for hacker activity. In other words, I appreciate your concern, but I can assure you DayZ Anti-Hax is immune to silly attempts by script kiddies like this.

Okay. You might not ever reach whatever threshold you set though; I was very careful with my memory usage and C# automatically manages memory. I'm also at a bit more than 7k passes and the parser's memory usage at any given time has either stayed the same or actually gone down since I last restarted it. Perhaps check by how long the process has been running or something instead?

I cannot use the DayZ Community Banlist filters as-is because they use a fundamentally different mentality when designing them (e.g. my remoteexec.txt is designed with the expectation that anyone who shows up in remoteexec.log is going to be banned, which is not the case for DayZ Community Banlist's remoteexec.txt). Also, because of the way I've designed my filters, they don't need to be updated very frequently. That said, I do update them when necessary and use the ones the DayZ Community Banlist offers as a reference. Whenever I do this, I commit my changes to our Google Code subversion repository, so you're free to update from there manually or just wait until another major release of DayZ Anti-Hax. There's really no harm in waiting and you're protected either way. Nice. If you ever feel the number of passes is getting a little ridiculous, you can always just restart the parser to reset the count to 1. :P

Frankly, the script kiddies are probably just getting smarter and realizing what gets them banned and what doesn't. The stuff my parser uses has been out there for a couple weeks now, which has given them ample time to try and come up with something new and, perhaps, undetected. I can confirm all filters are still operating as intended, so there's little else to explain the decrease in remoteexec.log entries. I'll continue to monitor the situation though. EDIT: I am continuing to get bans via the remoteexec method of detection (as recently as a few minutes ago, actually), so just make sure your filters are up-to-date according to what's available in DayZ Anti-Hax v0.5 and you should be fine -- for now.

Still shouldn't be a problem. Just make sure the parser isn't reading the file at the time, which, by default, only happens for about one second out of every minute. Even then, I'm pretty sure I gave it read permissions only, so that might not even matter. I've done this before as well.

This is not possible currently, but it is something I can look into for future releases. I believe I've added all the functionality I need, so it might be good to make the process even more open and allow people to manage the tool on their own. I also truncate my logs every new release of DayZ Anti-Hax (as you should, actually), so no, you should not encounter any problems doing so. :) This is true, although occasionally you'll want to unban someone who has been banned by this tool (unless you disable log flooding detection, then that chance suddenly becomes a lot less), and the best way to do that involves bringing the tool down temporarily while you do so, then restarting it afterwards. This solution really is meant more for dedicated servers than managed ones, but as long as you are under a good provider with a good support staff, sfmadmax, you should be fine in the long run.

Some script kiddies initialize variables calling for the creation of a bunch objects all at once. The flood checking catches this by making sure the accessing of these objects doesn't occur all at once as it would in the case of most scripts of this nature, thereby banning hackers before they have the chance to do anything wrong in the strictest sense. It is DayZ Anti-Hax's most liberal feature as far as banning hackers is concerned, which is why it can be disabled (though it is still enabled by default, and perhaps this was a mistake on my part), and while large amounts of desync combined with the execution of a bunch of actions all at once can occasionally break the system, I still have it enabled on my server as it has proven its worth to me over the past few days. I've also come across several cases where all of DayZ Anti-Hax's other detection methods have failed, and where without the anti-flooding feature, these tricky SOBs would have managed to continue their reign of terror on my server, which is why I ended up deciding to include it in v0.5 in the first place.

My solution only bans players, it does not kick them, so if you were kicked and not banned by something called 'DayZ Anti-Hax', let alone something similar, I can assure you it was not my solution. And again, for the last time, if you would like to continue this conversation, we can do so via private message, otherwise all we're doing is spamming up this thread and continuing to go off-topic. Despite my complete disagreement with everything you've been saying, I am willing to talk this out and see it through, just not here, so please honor my one request. Thanks again. I am certainly willing to make the parser itself more standalone, but how would you suggest I do so/what purpose should it serve? Assuming it should still ban players, are you talking about allowing admins to set their own parameters as far as what is bannable and what is not? If so, I don't see how that's much different than just adding some configuration options allowing admins to turn certain features on and off, which would avoid me having to essentially completely rethink what the parser is supposed to do, if I understand you correctly.

Your ban was not the result of my solution, it was the result of a completely different program that server is using that happens to have a relatively similar name, so yes, this is completely off-topic. If you would like to continue this conversation further for some reason, please private message me, but please refrain from doing so here. Thanks again.