I have some cool ideas for make GrangerHub servers “non-hackable”
it mean what chance connect with hacked qvm is 0,000000…01% of 1 000…0000% (so impossible xD)
I have idea sv_smartpure, how it work:
- If player connecting to server with own.pk3 = then check, if it have vm folder, = ignore, use server qvm.
if it have ui folder = allow
and secound command: sv_bannedpk3s 1 (1 = enabled, if 1 = he reading bannedpk3s.dat)
Look of bannedpk3s.dat:
[pk3]
name = thz_shit.pk3 //as exemple
type = HACK (flag HACK work like: player connect with this shit, server see, player try hack, server do recording he guid, name, ip to Hackers.log, pk3 anyway ignoring, nothing using from it, Admins from chat see "HackDetector: Player ***** tried connect with hacked pk3, pk3 ignored.)
method = KICK (if player connecting with deny pk3 = autokick, for disable set to “NOKICK”
and look of Hackers.log:
NAME: UnnamedPlayer#999 (xD)
ACCIDENT: Tried connect with Banned pk3 “%.pk3”
DATE: 01.01.0000 (xD just as exemple xD, ofc difference date shpould be xDDDD)
STATUS: Connection Closed. Kicked.
I think if you make cmds like this - u 4ever gonna forrgot about “Hackers and cheaters”
What about injection, hardcoded, and other hacks that don’t use PK3s?
I like this idea. Even if it doesn’t catch all hacks it would majorly help out admins.
The above won’t prevent ppl from running hacks at all. There is already changes in upstream tremulous (or at least an patch floating around) that fixes the minizip library to not blindly use the CRC32 embedded in the PKZIP headers.
SST servers used to have patched game.qvm which was very good at detecting aimbots. SST modifications were never released to public AFAICT, but I’ve always suspected it was implemented in bg_pmove.c in client snapshot delta update stuff. Wallhacks are mostly implemented as dynamically loaded hooks/trampolines directly modifying the gl rendering pipeline; these are undetectable without an separate thread/process scanning memory on the client- which has only existed in Win32 applications (though similar techniques exist for other platforms like linux & OSX).
Otherwise, THZ was also ported to GPP by an separate party. They did not utilize the same loading mechanism (spoofed Pk3’s) due to the minizip changes noted above. Instead, the client was directly altered to simply echo the pure checksums that the server sends to client; back to the server- defeating any chances of the above method working.
That said, THZ is not compatible with Grangerhub (the latest packages). The code in SVN does not have an functioning aimbot; the code is there, but it is severly broken. Clients will not track anything correctly, instead they’re movements are all over the place.
Trigger-bots can be built without any code modification these days on an handful of clients- almost any client that has WireDDD’s Math functions which included branching on cvar values using “if” function (its amazing what can be done with a config these days). You won’t catch these either.
There are things that can be done; but there is no “perfect” solution without serious work into changing how the client<>server model. Implementations would break compatibility with existing Tremulous entirely.
I would be happy to help in discussions/development of cheat-detection capabilities on the server side.
6 Likes