r1ch.net forums
* Home Help Search Login Register
r1ch.net  |  r1ch.net stuff  |  Anticheat  |  Topic: How to setup anticheat-hashes.txt
Pages: [1]
Print
Author Topic: How to setup anticheat-hashes.txt  (Read 19452 times)
R1CH
Administrator
Member

Posts: 2625



« on: July 13, 2006, 04:12:51 am »

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:
Code:
quakepath sha1hash flags
Where quakepath is the relative quakepath, eg maps/q2dm1.bsp and sha1hash is the SHA-1 hash of the file, eg:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
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:
Code:
!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:
Code:
\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.exe

Windows 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.
« Last Edit: February 09, 2007, 10:04:50 pm by R1CH » Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #1 on: July 20, 2006, 06:43:20 pm »

Another thing to consider, if you allow auto downloading, be sure to add zero hashes for any files you offer via autodownload! Eg, if you only have a hash for maps/custom.bsp and a client without custom.bsp connects, initially they will send a hash of 0000 and then after autodownloading they will send the hash of the file. If you do not have the 0000 hash, they will be kicked (depending on your sv_anticheat_badfile_action of course) before the autodownload completes.
Logged
TgT
Member

Posts: 103


« Reply #2 on: October 16, 2006, 06:58:41 pm »

Make it sticky
Logged
shovel
Member

Posts: 84



« Reply #3 on: January 20, 2007, 12:18:40 pm »

sorry for being redundant, but still after reading the instructions I am a little confused (ya I know, easily done rolleyes)

I currently do a hash check for the stock rocket model

models/objects/rocket/tris.md2   9e29d53020984dc853b541c4a8a0a7eaac042fe0



Someone sent me another version of the rocket model that he would like to be allowed on my servers.

So would I put both hash checks in like this?

models/objects/rocket/tris.md2   9e29d53020984dc853b541c4a8a0a7eaac042fe0
models/objects/rocket/tris.md2   97e0dcc789284146569a71ff077277971cad8e36






Logged
zorg
Member

Posts: 49


« Reply #4 on: January 20, 2007, 08:42:10 pm »

Yes, both files are marked as valid now. If a player has one of these installed, he will be reported as "clean".
Logged
shovel
Member

Posts: 84



« Reply #5 on: January 21, 2007, 02:56:10 pm »

thx zorg, I got a little confused if I needed to put a line in with all the 000000's

I didnt think I needed to but wanted to make sure. It works fine btw.

thx again
Logged
Snake
Member

Posts: 184


« Reply #6 on: February 05, 2007, 11:03:58 am »

Now that we're getting a little more comfortable with how it works, and what people use, we are thinking about allowing some stuff on one server, while not allowing them on other mods. For that it would help us a lot if we could use one 'basic' standard hashes file (which can be shared), and '#include'  that from a file with extra hashes for some server/mod. The same applies to the cvars.txt really. This should be helpful for all server admins that run more than one mod, or maybe one mod in several modes. Think you could squeeze that in for the next release?
Logged
emperphis
Member

Posts: 28



« Reply #7 on: February 07, 2007, 02:23:44 pm »

i go for that as well and *-cvar.txt Smiley
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #8 on: February 07, 2007, 02:37:12 pm »

All anticheat-* files will support a "\include" directive in the next release.
Logged
R1CH
Administrator
Member

Posts: 2625



« Reply #9 on: February 09, 2007, 10:05:08 pm »

Documentation updated regarding wildcards, hash list naming, \include and flags.
Logged
DJ_MELERIX
Member

Posts: 53



« Reply #10 on: August 05, 2007, 06:24:16 am »

is possibly protect hashes of the q2/r1q2 dll files ?
Logged
TgT
Member

Posts: 103


« Reply #11 on: August 05, 2007, 05:07:07 pm »

I tihnk it only works in mod dir
Logged
Snake
Member

Posts: 184


« Reply #12 on: August 05, 2007, 05:34:22 pm »

Those files are protected by anticheat itself, no need to hash it... if anticheat is broken then having a hash of the files won't help one bit.
Logged
Pages: [1]
Print
r1ch.net  |  r1ch.net stuff  |  Anticheat  |  Topic: How to setup anticheat-hashes.txt
Jump to:  

Powered by SMF 1.1.19 | SMF © 2013, Simple Machines