Magotchi

Ugh. 1 is almost useless IMO, unless you only have a few players in your server at a given time.

I applaud your optimistic view of the laws on hacking and their enforcement, Sol_Gemini. I wish you luck, but I have my doubts it will do much good.

Monky is likely the same hacker, FYI: http://code.google.c...tail?id=1408#c2 Regarding the PublicVariable Value kicks, you're absolutely incorrect. Please review this thread. Technically BattlEye can see everything the client logs, but what a server admin puts in his server's filters have nothing to do with BattlEye global bans.

If the hacker that visited my server two nights ago came to your server and ran the same script, you'd have buildings and helicopters in your Balota airstrip too. Get off your high horse. If you've found some foolproof method to prevent hacks entirely, please share it, but saying things like, "I would avoid this server at all costs." is unnecessary. I try my best to keep the hacks from working and to ensure that hackers are quickly banned, but it's not perfect. I don't know if you've noticed, but hacking is a major problem in DayZ, and it especially affects popular servers.

Sure.

"publicvariableval-local.txt" is just what I named my file (and put in my instruction post) in which I put the list of hacked item entries (with a line break at the beginning). Every time my server restarts, as part of the batch file that manages my log rotation, etc., I have it download the latest copy of publicvariableval.txt from the DayZ Community Banlist, and then I merge publicvariableval-local.txt onto the end of it. This way I can benefit from regular updates to the publicvariableval.txt that the DCBL provides while still kicking for hacked items.

Believe what you want to believe. I run a tight ship, and the regulars on the server know it.

I've been on this. It happened 2 nights (and several restarts) ago. I've been talking with people in the official IRC channels about it to try to get the stuff to despawn. The person that did the actual spawning got banned within 10 minutes of doing it, and I adjusted the way the filters on the server work to ban the same attack in the future; sure enough, the same guy came back with a different GUID (but same name and IP), and he got auto-banned within a minute for attempting a similar type of hack. Today, as per a recommendation from someone in IRC, I brought the server down for over 5 minutes and fully restarted the machine it's on. If that didn't solve it, I can only guess the buildings are probably coming back from the hive. I don't know if I'll ever be able to get rid of the helicopters without them just naturally despawning, though. (EDIT: I got rid of the helicopters. :-) Sol_Gemini: Keep your conflict of interest (being the admin of another server) to yourself. You know nothing about my habits as an admin, and accordingly, no valid basis on which to make such ridiculous statements. Also, all PublicVariable Value Restriction kicks of #43 and up are for doing hive updates while possessing invalid (hacked) items, as it says right in the first line of the MOTD. Therefore many people get kicked for that restriction all the time, without or without hackers present. For anyone interested, here are both of the issues with information about the specific guy that spawned the stuff: http://code.google.c...es/list?q=black . I'm zcallear.

http://clansm.net/forums/viewtopic.php?f=26&t=3266

I got kicked for BikeHorn the other night. :-) I didn't think much of it, as within 2 seconds of it, a hacker had just teleported most people to one spot in the server and killed them, and I was just trying to hit Escape and Abort. Anyway, I've updated my instruction post, removing any Horn entries, as it seems like the horns go into your primary weapon slot when you're in the driver's seat of a vehicle (so you can honk with your Attack bind, and hitting escape likely triggers a hive update that otherwise wouldn't happen.

Edit: I no longer recommend this method. There are now better ways to handle users of hacked weapons in our servers. Ventho's publicvariableval.txt method (with my tweaks to it) is what I now use on US 303. However, the code below may still be useful for other purposes, such as logging or generating a blacklist. I would have released this publicly about a month ago, but as it's sort of a gray area (some people believe admins can't ban for hacked items, while Rocket has only said players won't be global banned for hacked items), I've kept it to myself and to those that ask. I've decided to just release it, as I believe the benefit to everyone outweighs anything else. As far as my personal policies go for its usage on US 303, I have a warning immediately upon joining about not using invalid items in the server, and I unban anyone that asks, with the understanding that they won't continue to use hacked items. Script (rename to remove the .txt): http://callear.org/m...weapons.php.txt It's written in PHP, so that means it requires PHP (http://windows.php.net/download/). You only need PHP; you don't need a web server. You also need to be able to run it on the same machine as the server. Although this script could be tweaked to download the logs via FTP, it's outside the scope of my interest in it. You'll also likely need to have some sort of reasonable log rotation. My logs rotate on every server restart. The script may work with giant log files, but I haven't tested it. How to use it (how I do it, anyway): Edit the top of the script to reflect the paths to your RPT log, server_console.log, and your ban file (or any text file you want it to write the ban lines to, as long as the file isn't totally empty). Every minute, have Task Scheduler run: php -f "C:\Program Files (x86)\Steam\steamapps\common\arma 2 operation arrowhead\ban-players-hacked-weapons.php" You'll need to adjust the paths according to how you have things set up, including possibly using the full path for PHP, unless you have its directory in the Windows PATH environment variable. The script does not have to be in the game's installation directory; I just happened to put mine there. Use BattlEye Extended Controls or some other method to run "loadbans" every so often. I run it every minute. This just reloads the bans.txt file, actually banning newly detected players. Using BEC to do that is described at http://code.google.c...ionInstructions . Optionally, edit the whitelist at the top of the script to your liking. I built that by looking directly at the item spawn lists in the dayz_code.pbo file (inside config.bin, after decompiling it), and then I added some other things I'd missed as I saw them show up. The way I have it set up, it bans anyone with any item or wearing any clothing that isn't in the game. Keep in mind that since it's just reading their loadout as your server gets it from the hive server, it can't ban people that later get hacked weapons after they've joined, but if they join with hacked equipment, they'll be banned. Venthos' publicvariableval.txt method can detect weapons acquired after a player has joined. License: You may do whatever you want with this code, as long as you have fun.

The publicvariableval.txt method can only kick.

Thanks for the update. I hate to be the ultimate nitpicker, but the log shows this for setdamage detections: " for Hacking Damage (30.09.2012 07:18:06: publicvariable.log)". Should be "setdamage.log". :-)

Cool. It looks like the config.cfg regressed to an older version, though. Also, setdamage detection works, but only if I change the "1.00000" in the damage.lst to "1.000000".

I'm not positive this will work, but I believe DayZ Anti-Hax just searches the bans.txt for the GUID to determine if it has already been added or not, so try this: Change the ban from the following (as an example): a356e744b7d4be54ba9ac4ef0718167f -1 DayZ Anti-Hax (Remote Code Execution) to: beeffacebeeffacebeeffacebeefface -1 a356e744b7d4be54ba9ac4ef0718167f Alternatively, you can just rotate your logs, or delete the offending detections from your logs.

I no longer recommend this method. There are now better ways to handle users of hacked weapons in our servers. Ventho's publicvariableval.txt method (with my tweaks to it) is what I now use on US 303. However, the code in the OP may still be useful for other purposes, such as logging or generating a blacklist. I still run the script on my server, but I just output it to a different file as an extra admin tool.

If you look at my list, which is just based on my RPT logs, 29 people have joined my server with an item having "Horn" in the name since August 19th, so it's certainly possible to have in one's inventory; it's just not legit.

BikeHorn is also in the list, and I know I've jingled the bike's horn quite a few times since adding this filter, and I haven't been kicked. I don't believe you should ever have CarHorn in your inventory while using a car.

I agree that it should be optional, but worsin: if I were you, I'd search for their GUIDs in the issues list at the DCBL's Google Code site. You may be able to see log entries that will clue you in as to why they were banned.

I brought up-to-date the list of invalid items detected on my server since August 19th and the instructions based on it.

I figured it out. People are being kicked for normal stuff. There was an error in my filter example. Where it should be ' \"" ' at the end of each line, I have ' "\" ' at the end of each line. Once again I gave out bad advice... Sorry again. It's corrected now.

I'm not sure. With the exact settings in my current instruction post, a lot of people on my server get kicked for BAF_AS50_TWS (currently #41), and I haven't seen anybody get kicked for AKS_74_Kobra.

You can test on a full server; just use 1 instead of 5 for each entry. Polli: If you're using "\"ITEM_CLASSNAME"\", I don't believe an M249 entry should detect the regular M249_DZ, because a backslash followed by a double quote is the escape sequence for a double quote, meaning the entry is actually searching for the classname surrounded by double quotes. If you aren't sure, you can put a 1 on that entry instead of a 5 and check the inventories of the people as they're detected for it. Edit: Should be "\"ITEM_CLASSNAME\"", not "\"ITEM_CLASSNAME"\".

Yes, but the numbering starts with #0. The first non-commented line in publicvariableval.txt corresponds to #0. The 5th non-commented line corresponds to #4. The way the DCBL does their comments, they put the number added at the end of each comment line (like "//+4"), also. That means that if you subtract 4 from lines after it, you'll get the logged detection number. For further example, as the current publicvariableval.txt has 44 lines, 4 of which are comments, for your 45th line (where your hacked item detection entries start), you subtract 4 (due to 4 comments) and 1 (due to numbering starting with 0), which means your first hacked item detection (on line 45) should be #40.

FYI, a very well-known Arma II and DayZ developer wrote the script for that functionality, and the odds are reasonable that that functionality (or something similar) may make its way into the official DayZ hive build. :-)