Each server has the ability to choose which files are allowed, and to do this you need to make a file list called anticheat-hashes.txt that goes in the mod dir (or baseq2 dir if you want a global list). The format of the file list is quite simple:
quakepath sha1hash flags
Where quakepath is the relative quakepath, eg maps/q2dm1.bsp and sha1hash is the SHA-1 hash of the file, eg:
maps/q2dm1.bsp c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
Flags is optional and may be a combination of "required" or "negative" separated with a comma.
It's very important to note that the space between the path, hash and optional flags fields is a TAB character, NOT simply spaces! This is to accommodate the unfortunate but rare presence of 3rd party files containing spaces in their names. In the above example, this means if the client loads maps/q2dm1.bsp, it must match the SHA-1 hash specified or the client will fail the file check. If you don't care what the client has for a certain file, then just don't include it in the anticheat-hashes.txt at all. You may repeat the path as many times as you like, each with a different hash in order to support different versions of the same file. You may use comments beginning with // or # in the file. The file must end with an empty line.
Keep in mind only the content loaded by the client is checked and only as it is loaded - for example, if you include players/cyborg/tris.md2 in your anticheat-hashes.txt, a client with an illegal model won't show up until someone on the server uses the cyborg model and causes it to be loaded. The same may be true for other models/sounds depending on how the mod handles precaching. Another thing to be aware of is how certain clients load skins/textures. For example, R1GL will load skin.tga, skin.png, skin.jpg before loading skin.pcx. If you only have a hash for skin.pcx, any illegal skin.png or skin.jpg file would not be detected. However, another problem then arises - not everyone may be using the hi-res skin pak or whatever provides skin.png, so if you add a hash for skin.png, a client which fails to load skin.png will also be considered a violation. You can fix this by including an all zero hash for files that are OK to be missing, eg if you want to check that skin.png is either version xyz or not used, you would do:
models/something/skin.png c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
models/something/skin.png 0000000000000000000000000000000000000000
Similarly, to avoid a client bypassing the checks by using their own custom skins, you should include all zeroes for files that aren't in use. Say for example there is a model that comes with a normal .pcx skin and a hi res .png skin. A cheater may create a .jpg skin which would be loaded, and since you don't have a hash for it, it would be considered legal. Thus, your file list would include something like this:
models/something/skin.pcx c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
models/something/skin.png c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
models/something/skin.png 0000000000000000000000000000000000000000
models/something/skin.jpg 0000000000000000000000000000000000000000
models/something/skin.tga 0000000000000000000000000000000000000000
Then if a cheater tries to load skin.jpg or skin.tga it will be detected. I realise this is pretty annoying to have to do for every skin but unfortunately it's the only way to really be flexible enough to support all the various possible configurations. This behaviour MAY change in the future if I figure out a better way of doing it, but for now this is how the current system works.
The flags allow you to modify certain checks, specifying the
required flag makes the file hash required - for example, you may have
sv_anticheat_badfile_action 2 to notify players of file failures, but on certain files such as player models, you may want to require them to be valid regardless of the other server settings. Setting the
required flag on a hash makes any hash failure a kickable offense.
With the newest R1Q2 versions, wildcards are supported for the
quakepath. This is useful for specifying the same hash for multiple files, for example, some players do not like the crakhor player sounds, so they replace them with the female sounds. By specifying the female jump sound hash with a
players/*/jump.wav path, this would allow the female jump sound to be used for any players jump sound.
The wildcard matching system works in a "good" matching mode only by default. For example, specifying:
players/*/tris.md2 c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
Would mean that any player model matching the specified hash would be considered valid. However, if the player model is not checked elsewhere on the hash list, it would not be considered bad either. Eg, if you had:
players/male/tris.md2 abcd123456abcd123456abcd123456abcd123456
players/*/tris.md2 c73f0c65e3d148f1a0d46dfcad2f8090f7285d7a
The male/tris.md2 must match either the abcd hash or the c73f hash. However a female/tris.md2 would be considered good if it matched the c73f hash, but would not be considered bad if it didn't. This is due to the large number of possible matches the wildcard may cause - eg if someone uses the flyingscepter/tris.md2 model, you have probably never heard of it and do not have a valid hash for it.
Using the
negative flag on a wildcard hash will change the above behaviour so that anything that matches the wildcard but doesn't match the hash would be considered bad. Use this carefully as a large wildcard match could result in many bad files being reported.
As of recent R1Q2 releases, you may give your anticheat-hashes.txt a "friendly name" so that players know what kind of checks are in use. Eg, if admins share a common anticheat-hashes.txt, you can give it a name by beginning a line with !, eg:
!My Super Hash List (v1.1)
Players using the
aclist command will see the name of the hash list.
To make managing file hashes easier, it is possible to split the anticheat-hashes.txt into multiple files by using the
\include directive. For example, if you stored your player model hashes in player-hashes.txt and your sound hashes in sound-hashes.txt, your anticheat-hashes.txt could look like this:
\include player-hashes.txt
\include sound-hashes.txt
Included files may themselves include other files. There is no recursion checking, so be careful not to get into an include loop! It is recommended that included files do not use the
!name syntax to name the hash list, as only one name may be set, the latest one will override any earlier ones. Included files are searched using the standard Quake II path searching, so if the file does not exist in the mod dir, it may be read from baseq2.
To help create the file list, pakhash is a tool that will go through a pak file and output the path/hash of each file in a format suitable for dumping straight into the anticheat-hashes.txt file. You may find it at
http://ftp://ftp.planetgloom.com/r1q2/utils/pakhash-src.zip and compile with
gcc -o pakhash pakhash.c sha1.c and run with
pakhash pak0.pak. Windows binary:
http://r-1.ch/pakhash.exeWindows users may find SummerProperties useful,
http://www.earthmagic.org/?software this will allow you to right click a file and view the SHA-1 hash. Linux users can use sha1sum or whatever.
Author