Magotchi

Mine's full right now. :-)

Okay, but that still would not catch people with invalid items (many of them, like weapons, anyway) until they do a dayzCharDisco (hitting escape, exiting game, etc.), and it would leave you highly vulnerable to hacks by not logging very much stuff. Additionally, someone having an L85 doesn't make them a hacker, clearly.

Well you might try "writeBans". It's the command that's documented to do that: http://community.bistudio.com/wiki/BattlEye#GUID_banning Also, even if it doesn't work, temp bans don't hurt anything by sitting in bans.txt. The number on them is the Unix timestamp at which they expired.

To test, just now I downloaded "@Server-1.7.4.4-Full_hotfix.rar" from the official location. I extracted it. dayz_server.pbo was 61,870 bytes. I extracted it using cpbo ("cpbo -e dayz_server.pbo"). I made the exact edit described above. I deleted the original dayz_server.pbo. I created a new dayz_server.pbo from the dayz_server directory using cpbo ("cpbo -p dayz_server"). The new dayz_server.pbo is 61,873 bytes (only 3 bytes different). To answer your other question, when I extract the official dayz_server.pbo using cpbo, it has 21 files (not including directories, but including "$PBOPREFIX$". Are you using cpbo from the ArmA Tools package at http://www.kegetys.fi/arma/ ?

There are no checks for authenticity done on you dayz_server.pbo. It works on mine. There is nothing special about that edit; all you're doing is uncommenting a line which outputs things that were originally in there for debugging that code, so it shouldn't have any effect on the operation of your server. Did you extract the PBO with cbpo, then edit the file, then rebuild the PBO with cpbo?

Also in my MOTD: "Post all ban appeals and hacker reports to our forums at clansm.net for the fastest response." I only know about this due to Google Alerts, despite me not regularly checking these forums for bans and it not being in the Ban Appeals forum. Sometimes Google Alerts takes a few days, but this one went through pretty fast. Anyway, on to the ban. If your ban reason started with 2012-12-06, that means it was issued on December 6th in +9UTC time. I have looked through all the names for the GUIDs I banned on that day, and I can't find something matching your forums username. What name do you use on my server (at least on 12-06 +9UTC)? EDIT: Nevermind. I found it. I banned you for the following in scripts.log: 06.12.2012 09:04:57: NwoSwat (216.36.150.178:2304) - - #21 "s _Object select 1), 1]; _particle = "#particlesource" createVehicleLocal _ObjectPos; _particle setParticleParams [_ShapeName, _" Not only is that code not something I've ever seen in scripts.log that I know of, but it didn't have a GUID, meaning you somehow ran it before your GUID was even verified by BattlEye (which happens immediately on connecting, within about a second). I therefore found your GUID in the other logs and manually banned you. Anyway, I can't be sure you were hacking, so I'll go ahead and remove it. Have fun.

The whitelist used in my script a few posts before this reflects the current items available in DayZ 1.7.4.4.

Yes. If you're talking about either the publicvariableval.txt method (doesn't work anymore), or my new method, a couple posts ago, neither should interfere with operation of DAH. You already have some of what files? Again, the method originally described in this thread no longer works. Originally most people, I assume, were using the DayZ Community Banlist version of publicvariableval.txt and then appending the filters for invalid items to the end. I must repeat, though, that using invalid item filters in publicvariableval.txt is no longer effective. There are no files in this thread which are still effective at preventing players from using invalid items in a server, except for my script, above, that I know of. My recommendations for filters on your server (not for handling invalid items) are currently as follows: Use all the filters from http://code.google.c...se/#git/filters . DayZ Anti-Hax has the ability to do this, but some new filters have come out recently which are available there, and I'm not sure DayZ Anti-Hax updates them all. As that scripts.txt hasn't been updated since the latest version of DayZ, in order to prevent it from kicking for certain normal in-game events, you'll need to tweak it a bit. Tack 1 "" onto the end of publicvariable.txt, publicvariableval.txt, setvariable.txt, and setvariableval.txt . This will result in massive logs for those files, with a ton of duplicate lines, but as hackers are constantly evolving their methods to avoid Dwarden's latest filters, that will at least ensure you're logging everything. And yes, you do need 1 "" in both the val and non-val versions, despite it appearing to cause duplicates. Most are duplicates, but some things only appear with one but not the other. Just to reiterate, none of the DayZ Community Banlist filters have anything to do with preventing the use of invalid inventory items in your server, and there is currently no known way (at least to me) to effectively do so via the use of BattlEye filters, as there had been for a long time prior to the last couple DayZ updates, due to changes in the way the dayzPlayerSave variable is used on the client side (as I believe).

Because I don't check this forum regularly, I only know about posts about my server via Google Alerts, like I just got for this thread. The fastest way to get my attention is to post in the clansm.net forums. PanzerKnacker: Here's the message I sent in Global chat via RCon 5 minutes after your ban: "If anybody's a friend of PanzerKnacker, tell him he's not really banned. False-positive, fixing. --Mister_Magotchi" I believe I was working on my anti-hack scripts at the time and accidentally banned you for something. Sorry about that. It seems you've played since then, though. Acer: http://code.google.c...98&can=1&q=Acer Last night I unbanned a ton of people, including you, that had gotten banned for something I started auto-banning for in the last week (people appearing to be using medical items at least 4 times in the same second). As I've come to believe, these are likely caused by desync combined with people mildly spamming medical items.

I've written a new script. This time it parses the RPT log for both dayzPlayerSave (requires hive code tweak) and logins, and if anyone has invalid items (or an invalid skin) at those times, it temp-bans them and tells them the offending items they had. This script also makes the publicvariableval.txt method obsolete, unless you care to additionally kick players when they do dayzCharDisco (happens on hitting escape and at some other times). Requirements: The ability to edit your server's hive files PHP - You do not need a web server. some way of running commands on a schedule Instructions: In your hive files, inside "dayz_server.pbo", inside "compile\server_playerSync.sqf", replace: //diag_log ("HIVE: WRITE: "+ str(_key) + " / " + _characterID); with: diag_log ("HIVE: WRITE: "+ str(_key) + " / " + (name _character)); This will simply make the server log what it writes to the hive when it does server_playerSync (happens at dayzPlayerSave), and include the player's name at the end. To extract/create .pbo files, use cpbo, found here. Restart your server. Extract my script (two files) to anywhere you want. Edit the top portion of the script (invalid-items-ban.php) to match your server details. $state_file_path can be any valid path; the file size of the RPT log will be stored there between runs. Run the script often (preferably about every 30 seconds) via Task Scheduler, Bec, or whatever method you want. The command should be like: php -f invalid-items-ban.php If you don't have PHP's path in your PATH environment variable on your system, you'll need to specify its full path, and if you aren't starting in the directory where the script resides, you'll need to specify its full path. I personally run mine from the batch file which monitors my server, so that it doesn't pop up a new window every time. Notes: On the first run, the script never bans anyone. It only records the current file size of the RPT log in its state file and closes. Only players still in the server will be temp-banned when the script runs. I think either loadBans or writeBans need to be run to clean up expired bans from bans.txt. I'm not sure, but when another script I have runs loadBans, that seems to be the time it happens on mine. The rcon.inc.php code was modified from the DayZAdmin for Sanctuary project. Last updated (2013-03-04): Added: A bunch of empty soda cans and MuzzleFar.

I don't know if you ever figured this out, but here is some PHP which does RCon (although sometimes the data it receives is a little corrupted with certain characters): https://github.com/katzsmile/DayZAdmin/blob/master/modules/rcon.php

Well that makes me feel better. I was sort of going off you saying Gotcha worked in my thought-process that whole time I think. Anyway, hopefully we can figure out a better way to do it. One way is to parse the hive extension log for the hacked weapons and kick or temp-ban based on the player name. I'll look into that, since it's possible. Edit: Nevermind. The default hive code doesn't log the name there. It's possible to edit it, but I may just say meh for a while.

Edit: While I was testing things, I got dayzPlayerSave entries for bad items to log in that log file, but now that I'm up and running with the script, I haven't seen any yet (only dayzCharDisco). I'll keep testing, but logging is certainly being funky. Edit: I *thought* I had gotten dayzPlayerSave entries for weapons to log to Bec's log file earlier, but I can't reproduce it, so I'm probably just out of my mind. Anyway, dagg929, if you're sure Gotcha is able to detect hacked weapons, at this point I'd really like to know what magic they're using that I can't figure out. I've even stuck 2 "" in all the filter files they say in their install instructions to try to reproduce the kind of data Gotcha normally gets sent to it, and I still can't see information about the weapons (specifically) in player inventories. As Gotcha, AFAIK, only uses the data that BattlEye sends it via logging things to the server console, I don't know how Gotcha could know about it any faster than Bec's log would show it, assuming the same settings. This post had contained a script I wrote and instructions for it, but it didn't work.

Anyway, my conclusion is that there's nothing wrong with my filter, and that something's wrong with the game or BattlEye with regard to logging instead, as per my testing above. Edit: Again, I'm probably wrong.

Gotcha only works by telling the filters to log to the server console (and therefore to RCon) rather than just to individual files for each filter. If Gotcha is working, it just means that the game is properly logging the information to the console, but not to the filter log files. Edit: I just added 1 "\"ItemPainkiller\"" right after the log to kick for the L85, and immediately ItemPainkiller starting showing up in the logs for dayzPlayerSave with its appropriate detection number (121 in my case), so the logging is working to a degree. Odd that it's not working for other items. Edit: Anyway, I'm doing a lot of experimenting with publicvariableval.txt and talking about it in IRC. Even without my supplemental filter, but just with 1 "" at the end, I'm having difficulty getting it to log all the player inventories. Even with a nearly full server, it logs very infrequently. My hunch is that something changed in the way BattlEye logs things, because it indeed used to work. I used to spectate people and watch them get kicked for it, without fail. Edit: With 3 "" in publicvariableval.txt, RCon shows way more stuff than either server_console.log or publicvariable.log. Something is indeed wrong with the logging system, I believe. Edit: I'm probably wrong.

I'm looking into it. What's strange is that I can't find a single dayzPlayerSave line that also has the text "l85" in it in my publicvariable.log files either, although I see plenty showing other items in inventories. I also log everything (1 "" at the end of both publicvariableval.txt and publicvariable.txt).

My current settings: MaxCreateVehiclePerInterval 20 1 MaxSetPosPerInterval 1 180 MaxSetDamagePerInterval 3 1 MaxAddBackpackCargoPerInterval 2 1 MaxAddMagazineCargoPerInterval 70 2 MaxAddWeaponCargoPerInterval 10 1 I can't tell you if they're good or bad, but I don't have many false-positives with them as far as I know, and they don't seem to affect server performance.

I've never seen a single log entry in addweaponcargo.log, ever, using the DCBL filter for it, and the only backpacks that exist in the game are valid DayZ items, so no, it won't do anything in those files.

Well, you do put them in that file, but I wouldn't recommend just tossing them in. You'll want to adjust them to your liking. Also, there are 6 settings total. Here are the other 3: http://forums.bistudio.com/showthread.php?138736-Introducing-Server-side-Event-Logging-Blocking&p=2241070&viewfull=1#post2241070

http://forums.bistudio.com/showthread.php?138736-Introducing-Server-side-Event-Logging-Blocking&p=2250640&viewfull=1#post2250640 You want MaxAddMagazineCargoPerInterval.

Also, Monky is a prolific DayZ cheater, but plenty of other people use stuff he's created.

I believe I've adapted the blacklist method correctly for addmagazinecargo.txt: http://dayz-hacked-items-publicvariableval-filter.googlecode.com/git/addmagazinecargo-local.txt As always, use it at your own risk. If you aren't sure it's good, log (1 "") instead of kick and log (5 ""). EDIT: I just made a silly mistake. Fixing. EDIT: Fixed. For some reason I went braindead and mistakenly removed the L85 from the list, and then I had to put it back. Also, for anyone wondering, the new filter is just generated with a little PHP script I threw together, based on the publicvariableval-local.txt file and my whitelist. I'm not sure if the filter matching system is case-sensitive or not, so I just assumed it isn't. For example, in the rule: 5 "bizon" !="64Rnd_9x19_SD_Bizon" !="bizon_silenced" I assume "bizon" by itself would have matched "64Rnd_9x19_SD_Bizon" even though the case is different, so I left 64Rnd_9x19_SD_Bizon in to be better safe than sorry.

Well again, the magazine thing is highly experimental, and that's why I said to use 1 "" instead of 5 "" when I originally posted the whitelist version of it. If the publicvariableval.txt thing is kicking for the L85, it should be also be kicking for M4A3_RCO_GL_EP1, but again, it only happens when a player does dayzPlayerSave. If you want to see all instances of dayzPlayerSave so you can see how frequent it is, you can tack 1 "dayzPlayerSave" onto the end of publicvariable.txt. EDIT: Regarding the addmagazinecargo.txt whitelist method, here's what I believe is happening if try to use the entire whitelist: The server has a set size for the pattern string, so it's just cutting off the list after a certain point, which is why things like Trash* are commonly logging for it. I'll attempt to build a working blacklist.

If it can't all work in one line, it can't work at all with the whitelist method. The rule is saying to kick for anything unless it exactly matches any of the other things in the line. For example: 1 "" !="ItemRadio" would log anything that didn't match ItemRadio exactly. You can play around with it by using 1 (log) rather than 5 (kick and log). I'll experiment more when I have the free time.

Are you saying it's kicking players for possessing the whitelisted items?