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 sutviving 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".