Integrity (Anticheat)
Full anticheat protection is can only be reached with disabling older clients, so if you need to secure your server, you have to set Unreal.ini, Section [IpDrv.TcpNetDriver], AllowOldCLients=False.
1) Introduction
Before Unreal 227, cheat protections were stand-alone mods purely scripted. I am not going to list each known protection up to date and their strengths and weaknesses, but a general weakness of all of them is that they are all working within the limits of script alone. So how to catch a DLL hack...?
The 2 main goals in 227 have been bug reduction and added security. The Unreal Integrity 227 package is the answer to the latter, capable of doing full file checks online comparing file checksums of the files the client is using towards either known lists of files or files the server can load itself.
Unreal Integrity 227 should be able to catch any modified file in Unreal. Patches and exploit-fixes outside of this package take care of a lot of cheats (exploits) as well, so even without using this special package your online experience should already be improved.
2) Installation
Unreal Integrity 227 should come readily installed already after you patched your Unreal to version 227. Nevertheless, you should ensure the u-file is present in your system directory and that this entry exists in your Unreal.ini:
ServerPackages=UnrealIntegrity227
3) What Is Being Checked
1. Client Unreal Version 2. Client Computer Name 3. Client Console 4. Certain Fabrications of specific values 5. Unreal.exe, all loaded package files including DLLs... 6. All checks are timed, failure to give expected replies to the server will lead to a kick (and possibly an automated ban).
4) Running
A server administrator will enable Unreal Integrity 227 by adding the package's main mutator on the server startup (UnrealIntegrity227.IntegrityServer):
Unreal.exe ...Game?Mutator=UnrealIntegrity227.IntegrityServer ...
5) Settings
Settings are saved in your Unreal.ini. The settings can be accessed at:
Advanced Options -> Networking -> Unreal Integrity 227
The default settings should be "all right" for the Joe Average server, you
may want to change some of them depending on the type of server you run.
More consideration to some settings are required for...
- Last Man Standing / Standoff / Round Based ...
- Duelling ...
- Specially modded...
...servers.
Most settings more or less directly influence how taxing continuous checks
during the game are on players, and depending on the server type, more or less
can be allowed. Basically, when the server starts checking a client while the
player is heavily engaged in combat, and dies because of the lag spike the
checks created, then you - as administrator - probably did a crap job
configuring! Your goal must be to configure the Integrity Server so it checks
most likely when a player is not running at risk being killed at that time.
The Integrity Server already takes off the biggest challenge here, because
by default checks already appear in "opportune" moments, such as:
1. Player just joined (initial full check)
2. Player died (in game death check)
3. Player is the only player alive (1vs1 setting)
4. A round is over (see chapter about "Mod Considerations")
5. The game ended
So basically, the only "IN-opportune" time for a check is if the player never
dies and the match takes ages and the player is in constant battle... and then
the timer of the maximum amount of time a player can run around without being
checked again is hit!
Finding good timing options may be tricky, but smooth gameplay with enough
checks is worth tinkering a bit. All the other settings are less difficult,
like setting up what todo when something shows up out of the ordinary.
Please note that practically ALL settings require a map switch to take effect
if you change them during runtime.
- Settings "Integrity Server" -
AllowedConsoles
Unreal Integrity retrieves the client's console and compares it to this list
of allowed consoles. If you run mods on your server, you may want to add in
the console of your mod.
(Related: event_IllegalConsole)
bUseUTeamFixIfAvailable
Unreal Integrity will determine if you are using UTeamFix (not which version
though) and this variable is true will try to utilize it for session bans.
The difference with UTF's session banning method are these, that the banned
player IP will get a message that there is a temporary ban in effect,
whereas using the 227 native temporary banning will have the player join and
be instant-kicked. The native 227 banning does name bannd too though.
If you are using an older version of UTeamFix (pre 9F) you should keep this
disabled. Also, since UTF-temp banned players are rejected at PRELOGIN
rather than kicked, the server will receive 5 or 6 late UDP packets from
them if the UTF-banning is enabled (whether or not that is critical or
even worth mentioning is beyond me though...).
bUseSlowReplication and SlowReplicationSpeed
These two settings go together.
Unreal Integrity was first developed for speed and efficiency, but since
client checks take a lot of cpu and bandwidth power, this will often cause
problems on real life internet servers and different clients. The sheer
amount of data transmitted hence and forth can lag out slower or
low-bandwidth clients completely, cause false alerts etc.
Turning on "bUseSlowReplication" will CONSIDERABLY increase the time a
complete check takes in game. You will need about 3 to 5 times increased
TIMING settings as well. The setting "SlowReplicationSpeed" is indeed a
delay factor, so "higher" means "slower", doubling the value indeed
doubles the time a full check takes to complete, and thus doubles your
leniency factors you have to put in your timing settings accordingly.
ClientDetectionMethod
Unreal Integrity uses a combination of methods to detect loaded packages.
The "Complete" method is rather strict and looks up -ALL- loaded packages,
whereas the "Smart" one is less strict and only looks up the "critical"
ones, lessening the load on servers and clients.
If you are not sure about a player you can change the method once in a while,
but be aware of the following consequences:
If this setting is "Complete", all custom S3TC packages that have not been
whitelisted will remove players from the game. Also the "Complete" setting
may yield more lag and more cpu pressure on both server and clients. The
"Complete" method is more likely to result in "innocent" kicks from
packages a client may have loaded from its last server visit or offline
play. You may need to increase the response time limits to allow for the
increased load to pass without timeouts. This is especially true for
slow-cpu clients!
Events
An event is when something "shows up on the screen" so to speak, and every
event can be responded to (or ignored) depending on its settings:
bTellPlayers
If enabled, all players in the server are being told that a player
raised an event.
bKick
If enabled, the player will be KICKED from the server who raised this
bSessionBan
If enabled, the player who raised the event will be KICKED and BANNED
until the map changes.
offenseName
This is a human readable explanation of the raised event such as "has
an unknown package".
message1-4
Up to four lines of text can be sent to the client as added information
to a raised event. For example, you can tell the player not to do a
stupid thing as this or that when playing on your server.
If a raised event kicked the player, that player will see all these
messages AFTER being removed from the server!
All in all, about 100 lines of text can be sent to the player in total.
event_ClientTimeOut
This event is raised if a client times out during a check. Since
non-responding to a server request is potentially dangerous (the client
part could be hacked to hinder it from sending a reply), non-responding
should be answered at least with a kick. If lag is so bad that the player
keeps timing out, it is no good to play anyway so not much harm done in
that case either ;)
event_FakeComputername
Computer names can be fabricated in Unreal. If an "obvious" fabrication is
found, this event is raised. Fake computer names pose no security threat,
so by default nothing happens when this event is raised. It is up to the
admin to either feel comfortable with players using obvious fabrications
or not.
event_OldVersion
Since full checks of Unreal Integrity only work on 227 clients and not on
older clients, it can not ensure any security for these old clients. So...
you could just circumvent all checks by using an old Unreal version...
This option enables admins to respond to old versions, kicking players and
telling them to upgrade. An ideal place to advertise your website with the
227 patch for download is the message1-4 field of this event!
event_IllegalConsole
If an unknown (not white-listed) console name is found, this event is
raised. Very primitive bots use custom consoles, but this check does not
generally prove to be very difficult to get by with a cheat, but still it
works on older clients too and it does about as much as Hackbuster 2...
just without the lag HB2 creates :)
(Related: AllowedConsoles)
event_IllegalClientRequest
Illegal client requests occur when certain messages from the client are
garbled or incomplete. This can be accidental (lag), or malicious (hacked
client). Either way, a reaction should follow this event, at least a kick.
event_UnknownPackage
If a client is found with a package in memory that the server does not
know. Practically every advanced script bot will show up this way, but
also harmless skin textures that the client loaded by accident. Either way
this event should raise an eyebrow and certainly warrants a kick.
event_ModifiedPackage
A modified package is outright BAD! It means a player has messed with a
file that should have been left alone. This may also happen with some mods
when client and server are out of synch but netcompatible, so in these
cases clients should update their file. Either way, a kick is in order
because the modification may just as well be malicious.
event_FabricatedReply
Some modified and hacked clients try to trick anti-cheat programs by
faking replies to common requests. Hopefully most fabricated replies
should be detectable but in some cases lag may also be responsible for
a partially garbled or incomplete reply which may then accidently raise
this event. Appropriate reply is at least a kick, if the same player shows
up REPEATEDLY with this "problem", consider a firewall-ban because he's a
hacker!
event_SuspiciousPackageName
This is an eyebrow raising event, because basically it means the client
replied with a checksum of a whitelisted or known file, but the filename
was different. This may not be critical in all circumstances and a case by
case study is appropriate.
IngameChecks
bEnableIngameChecks
Wether or not to enable in-game checking. If false, players are checked
through only ONCE right after they join. Since some cheats can be loaded
during runtime, it is highly recommended to enable ingame checks, however.
bAlwaysFullCheck
There are 2 types of checks ingame, a short and a full check. The short
check calculates a bunch of checksums and as long as they keep matchng
over time, the client has not loaded or unloaded any packages and thus
does not need to be examined in full again.
The short check is much faster than a full check, so the lag spike during
game is notably shorter when it occurs. If you want to forego the short
check, and ALWAYS check players in full, enable this setting.
bOneVSOneServer
If you run standoff / LMS or 1vs1 servers, this might be a good option to
enable. If this setting is on, the server will also try to recheck ALL
players when there is only ONE SINGLE player alive. This is very useful
in 1vs1, because the surviving player may be checked as well as the killed
player after a kill, rather than ONLY the dead player.
Likewise, in round-based games / Standoff or LMS, it may happen that from
all teams only one keeps standing alive at the end of a round, the ideal
time to recheck every player (including the survivor).
Servers running mods that implement the 227 Interface may not need this
setting, since the mod then takes care of the proper timing of re-checks.
bUnUsualPlayerPawns
Unreal Integrity uses carcass-detection (yes I know, that sounds a bit
morbid...) to see which player died. Since there are monsters in Unreal,
by default only the known human carcasses are detected as well as the
trooper carcass from the Skaarjplayer.
(***TODO**** OPEN ISSUE: NALI PLAYER)
This saves some CPU power and is good enough for all normal servers, but
if you run mods where players can be monsters or non-standard creatures,
Unreal Integrity will be unable to detect when these players die. For such
servers, this setting must be enabled because then all carcasses are seen
and matched against existing players. Of course, thid does cost a few CPU
cycles every time a normal monster is killed, but that's the tradeoff.
Actually, on today's GHZ CPUs, it shouldn't matter one way or another, but
it's always better to have room for optimization :)
minTimeRecheck
The minimum amount of time (in seconds) that must pass before a player
that has been checked can be checked again. So, if a player died and was
checked, then keeps dying several times in a row, no rechecks will occur
until this timer is exceeded.
maxTimeRecheck
The maximum amount of time (in seconds) which represents the absolte limit
a player is allowed to run around without being checked again.
NeedNotHavePackageList
This is a list of packages you can choose the client needs NOT send in a
full check.
In some rare circumstances, it may happen that this or that package ends
on the internal list of packages the server expects the client to see and
actually send a valid checksum for it. If the client does not see a package
and thus fails to send the checksum, the server will assume a fabricated
reply and thus a hacked client.
Obviously, if this problem suddenly appears for ALL players after installing
a new mod, then you have found one of those exots that need to be put in this
list. Just enter the package name (file name without extension).
Timings
initialTimeout
When the player just joined, this is the amount of time (in seconds) it
is allowed to take for an initial reply. This setting is extra because
very often lag and packet loss are responsible for a hitched
initialization process, so players which just joined should be granted
some extra lenience compared to players that are already connected fully
to the server.
shortReplyTimeout=3
The amount of time (in seconds) a client is allowed to take replying to a
short request (such as the short check or giving computer name, version
info etc). "shortReplies" are such that consist of one single reply so
they are expected to occur within one or 2 ping cycles.
fullCheckTimeout
A full check takes notably longer than any single-reply request from the
server, so the amount of time allowed for the client to reply to it (in
seconds) should be notably higher as well.
Verbosity (How much stuff you want in your logs?)
bLogInit
If true, all startup, pre- and postcaching of loaded packages on the
server is being logged. If you ever run into a very strange problem where
you are certain the server should actually KNOW a certain package, this is
what to use to discern if it was truly loaded on startup.
bLogClientIDs
If enabled, game version, computer name and Consoles of clients are
logged.
bLogClientChecks
If enabled, all checks that occur during runtime are logged in detail.
- Settings "Whitelist" -
Administrators can choose to enter their own packages freely in this list.
Unreal Integrity will treat all entries (if enabled) as pre-loaded as if the
file was loaded at startup.
In order to use the Whitelist, just enter the package name (for DLL/SO files
use: "./[filename.library]"), enter the MD5 checksum (CRC) in the CRC field,
and enable the entry. You can turn entries on and off without clearing the
actual entries.
NOTE: If you got your release with one or more entries filled, do not remove
them.
6) Legal notice
The copyright owners retain all rights not explicitely given. You, the user are allowed to use the package "as is" without any guarantees of its functioning, direct or indirect damages whatsoever.
UNDER NO CIRCUMSTANCES ARE YOU ALLOWED TO DISASSEMBLE, DECOMPILE, REVERSE ENGINEER OR SIMILARLY ANALYZE OR DISMANTLE THE PACKAGE FROM ITS ORIGINAL FILE.
USING THE UNREAL INTEGRITY PACKAGE IN ANY OTHER MANNER THAN THAT TO PROTECT YOUR UNREAL SERVER FROM CHEATERS IS ILLEGAL.
ALL RISK OF USING THE PACKAGE REMAINS WITH YOU.
7) Mod Programmers Considerations
Unreal Integrity was created with mod-compatibility in mind. It will not try to validate server actors that do not exist on clients and it will automatically try to find files and packages in its home directory system if a package name is encountered which is not yet loaded in the current session.
8) Interfaces
There is one interface in the Unreal Integrity server. Mods may indicate that "NOW" would be a good time for rechecks on players. Basically every round-based gametype is a prime example for such a feature, because the mod knows when a round is over, at which time checks would (not likely) interfere with any player-critical gameplay.
For mods it is not needed to use this 227 feature to actually HAVE 227 at compile time in order to use it.
What mods have to do is: - Find the "UnrealServer" mutator (e.g. via "IsA(...)") - call "trigger()" on it, using the mutator itself as first parameter
Example code: // demonstration code how to suggest to the mutator // when to perform rechecks of everyone from OUTSIDE 227 // MOD PROGRAMMERS: COPY AND PASTE THIS INTO YOUR CODE :) function TriggerInGameChecks() { local Mutator mut; for(mut = Level.Game.BaseMutator; mut != none; mut = mut.NextMutator) { if (mut.IsA('IntegrityServer')) mut.Trigger(mut,none); } }
9) Future Versions
Unlike other packages, the Unreal Integrity package CAN NOT BE MADE NETCOMPATIBLE across versions, so with each new Unreal patch, a new Integrity Package must be created. These new packages will be named "UnrealIntegrityXXX" with XXX being the new engine version (e.g. UnrealIntegrity228).
Server administrators will need to adjust their mutator line in the server startup and possibly the serverpackages if the updater did not take care of it. Other than that, everything is supposed to remain as is.
10) Configuration Tips for special purpose servers
As already stated, the "default" values should take of most any normal server around. You may encounter problems or wish to enhance performance in certain areas though.
1vs1 servers: Try to use the "1vs1 option", turn on either Smart/Old detection with the "slow replication" turned off. Use a very low "minimum" recheck timing value, and a very high "maximum" recheck value. This combination will be VERY effective on 1vs1 servers and check both players after almost every kill very quickly! Since at the time someone was killed there should be a few seconds to spare the high check rate should not inconvene anyone. This setting combination is meant for competitive 1vs1 servers only, where you need to be certain everything is up to par with the contestants at all times. If you find your players getting kicked often because of the high speed replication, use the slow setting but tinker around with the "SlowReplicationSpeed" to have it as low as possible but as high as required.
largely modded servers: Be very lenient with timings, regardless if you use "slow" or fast replication. If you have a lot of custom packages installed, checks will take very very long, especially using the "old" detection method. Have a lookout for "missing packages" in client replies when using the "smart" package detection method. Sometimes packages are not properly seen on the client and you might need to enter them in the "need not have" list to avoid accidental kicks. Alternately set the event "Fabricated Reply" to NOT ban (only kick or even ignore if you want to) because very often the "missing" packages are seen later on. You will need to check your logs more often to see what's going wrong and needs tinkering.
11) Example Setup
A good basic setup can be reached with the following settings, which will not affect gameplay. If you need 100% security, you need to enable IngameChecks also, but this may cause lag during gameplay for the players.
[IngameChecks]
bEnableIngameChecks = False
[Timings]
fullCheckTimeout = 100
initialTimeout = 30
shortReplyTimeout = 10
Leave the rest "as is".