-
Notifications
You must be signed in to change notification settings - Fork 92
/
anticheat.html
196 lines (156 loc) · 7.24 KB
/
anticheat.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html><head><title>Untitled</title>
<meta name="GENERATOR" content="MAX's HTML Beauty++ 2004">
</head>
<body style="color: rgb(0, 0, 0); background-color: rgb(192, 192, 192);" alink="#ff0000" link="#0000ff" vlink="#800080">
<font size=4>
<center>
<h2>Anti-Cheat Module for Ioquake3</h2h2>
<h3>Copyright (C) 2012 Laszlo Menczel</h3>
</center>
<h3>1. Intro</h3>
<p>
This document describes the server side anti-cheat module I have
implemented for ioquake3. The goals of the module are the following:
<ul>
<li>to prevent the use of wallhacks</li>
<li>to detect the use of aimbots</li>
</ul>
It should be quite easy to port to any game that uses the Q3A engine.
<p>
This is an alpha release for testing, only wallhack prevention is implemented
at this time. Also it is not yet restricted to dedicated servers, so you
can test it with bots on a single machine w/o starting a separate server.
I have included a simple client-side wallhack (see 2.1) to make testing
possible.
<h3>2. Wallhack prevention</h3>
Wallhacks are prevented by restricting the information sent by the
server. The positions of opponents that the player cannot actually
see are changed so that the opponent is directly below the player.
The distance of the player and its opponent is maintained so
that sound scaling works correctly. A little bit of X/Y offset may
also be added to help in estimating the direction of the sound (this is
an option controlled by a Cvar, see below).
<h4>2.1. Cvars controlling wallhack prevention</h4>
<p>
<b>wh_active</b><br />
If you set this Cvar to "1", the wallhack prevention code is activated.
Default is zero (inactive).
<p>
<b>wh_add_xy</b><br />
If you set this Cvar to "1", then the modified position of invisible
opponents will contain a bit of X/Y (direction) information. Default is
zero (do not include X/Y info).
<p>
<b><i>Note:</i></b> This information can be used to determine the exact
position of hidden players. I am convinced that this option must be omitted
from the final version. I just left it in so that testers can estimate
the subjective difference between the two cases.
<p>
<b>wh_bbox_horz</b><br />
<b>wh_bbox_vert</b><br />
These are the dimensions (in Quake units) of the players' bounding
boxes used for performing line-of-sight traces. All eight corners of
the bounding box are checked for visibility. Default values are 30
and 60, respectively.
<p>
<b><i>Note on bounding box dimensions:</b></i>
<br>
The above default values are considerably larger than the normal values
(16 and 32) used by Q3A. The reason for this is that it is better to predict
a player as visible when he/she is not than the contrary. It may give a slight
advantage to cheaters using wallhacks, but IMO it is not significant.
You can change these Cvars, but if you set them to smaller values then
it may happen that players do not become immediately visible when you go
around corners.
<p>
<b>cg_wallhack</b><br />
This is provided for testing the functions of the wallhack detector. If
you set this to "1" then a simple wallhack (based on changing an OpenGL
parameter) is activated in the client. Default value is zero (inactive).
<h3>3. Aimbot detection</h3>
[NOTE: NOT IMPLEMENTED YET!]
<br><br>
Aimbots will be detected by using Dynamic Bayesian Networks trained to
distinguish the playing style of cheating and honest players.<br>
<h3>4. Implementation notes</h3>
<h3>4.1. Wallhack prevention</h3>
The bulk of wallhack prevention code is in the source file 'sv_wallhack.c'.
There are other small changes in some of the server modules. The client
side wallhack code is in 'cg_local.h', 'cg_main.c' and 'cg_players.c'.
<p>
All additions and changes are flagged by the marker '_ML_' and are
enclosed in '#if defined ANTICHEAT ... #endif'.
<p>
The details of the algorithm of wallhack prevention are the following:
<p>
1. When potentially visible entities are added to the snapshot
sent to a client, we first check if the entity is another player. If yes,
we check if the client can actually see the opponent or not (in this
frame or in the next predicted one). Visibility checking is done as
follows:
<ul>
<li>
we check if the opponent is within the FOV of the player
</li>
<li>
we check if there is a direct line-of-sight from the viewpoint of
the player to any of the corners of the opponent's bounding box
</li>
<li>
if the above tests are negative, we predict the position of the player
and its opponent for a time point 100 msec later, and repeat the FOV
and line-of-sight tests
</li>
</ul>
<p>
2. If the opponent is visible (or is predicted to be visible in the next
frame) then its entity is added normally.
<p>
3. If the opponent is not visible, we save its position then change it
so that it is directly below the player at the same distance as before.
The modified opponent entity is then added to the client snapshot.
<p>
4. When the snapshot is built, each client entity is checked if its
position has been changed by the wallhack code. If yes, it is reset to
the original values after the entity is added to the snapshot.
<p>
The result is that a client using a wallhack cheat will always see the
hidden players at a position directly below his/her feet (it will contain
no X/Y info). Therefore, it is quite impossible to determine the real
position from the data available to the client.
<p>
<b><i>Note on sound position:</i></b>
<br>
As a consequence of changing opponent positions, the location of generated
sounds are not correct. You may ask if this could interfere with the
client's ability to estimate the location and distance of the opponent
based on the sounds he/she hears.
<br><br>
IMO it works because the distance of the sound source remains the
same so the attenuation of sound is correct. The X/Y information is
obviously lost, but I believe that it is less important. This loss may
be an acceptable price to pay for the elimination of wallhack cheats.
<h3>5. Compiling</h3>
For compiling under Windows you will need the MinGW/Msys system (a port of
the GCC compiler suite to Windows). If you are unfamiliar with this system,
see <a href="http://linradiant.intron-trans.hu/mingw.html">this</a>
document.
<p>
First you should adjust the variable COPYDIR in the file 'Makefile.local'.
Set its value to the path of your Q3A game install directory.
<p>
To build the game + AC module switch to the directory 'ioquake3' and run the
command 'make copyfiles'. This will build the game and install it to the
directory you specified in 'Makefile.local'.
<h3>6. Usage</h3>
The build system is set up to create dynamic libraries (.dll or .so) instead
of VM modules. The supplied small 'autoexec.cfg' file contains the settings
necessary to force ioquake3 to use these libraries. It also has settings
for activating the client side wallhack and the server side anticheat code.
Copy the content of this file to the end of your 'autoexec.cfg'.
<h3>7. Feedback</h3>
If you have comments, questions or suggestions, or if you have found a bug please,
send me an e-mail to this address: <a href="mailto:laszlo.menczel@gmail.com?Subject=q3-anticheat">laszlo.menczel@gmail.com</a>.
</body>
</html>