Difference between revisions of "Integrity (Anticheat)"

From Oldunreal-Wiki
Jump to navigation Jump to search
Line 58: Line 58:
== 5) Settings ==
== 5) Settings ==


Settings are saved in your Unreal.ini. The settings can be accessed at:
Settings are saved in your Unreal.ini. The settings can be accessed at:<br>
Advanced Options -> Networking -> Unreal Integrity 227
Advanced Options -> Networking -> Unreal Integrity 227<br>


The default settings should be "all right" for the Joe Average server, you
The default settings should be "all right" for the Joe Average server, you<br>
may want to change some of them depending on the type of server you run.
may want to change some of them depending on the type of server you run.<br>
More consideration to some settings are required for...
More consideration to some settings are required for...<br>
- Last Man Standing / Standoff / Round Based ...
- Last Man Standing / Standoff / Round Based ...<br>
- Duelling ...
- Duelling ...<br>
- Specially modded...
- Specially modded...<br>
...servers.
...servers.<br>


Most settings more or less directly influence how taxing continuous checks
Most settings more or less directly influence how taxing continuous checks<br>
during the game are on players, and depending on the server type, more or less
during the game are on players, and depending on the server type, more or less<br>
can be allowed. Basically, when the server starts checking a client while the
can be allowed. Basically, when the server starts checking a client while the<br>
player is heavily engaged in combat, and dies because of the lag spike the
player is heavily engaged in combat, and dies because of the lag spike the<br>
checks created, then you - as administrator - probably did a crap job
checks created, then you - as administrator - probably did a crap job<br>
configuring! Your goal must be to configure the Integrity Server so it checks
configuring! Your goal must be to configure the Integrity Server so it checks<br>
most likely when a player is not running at risk being killed at that time.
most likely when a player is not running at risk being killed at that time.<br>


The Integrity Server already takes off the biggest challenge here, because
The Integrity Server already takes off the biggest challenge here, because<br>
by default checks already appear in "opportune" moments, such as:
by default checks already appear in "opportune" moments, such as:<br>
1. Player just joined (initial full check)
1. Player just joined (initial full check)<br>
2. Player died (in game death check)
2. Player died (in game death check)<br>
3. Player is the only player alive (1vs1 setting)
3. Player is the only player alive (1vs1 setting)<br>
4. A round is over (see chapter about "Mod Considerations")
4. A round is over (see chapter about "Mod Considerations")<br>
5. The game ended
5. The game ended<br>


So basically, the only "IN-opportune" time for a check is if the player never
So basically, the only "IN-opportune" time for a check is if the player never<br>
dies and the match takes ages and the player is in constant battle... and then
dies and the match takes ages and the player is in constant battle... and then<br>
the timer of the maximum amount of time a player can run around without being
the timer of the maximum amount of time a player can run around without being<br>
checked again is hit!
checked again is hit!<br>


Finding good timing options may be tricky, but smooth gameplay with enough
Finding good timing options may be tricky, but smooth gameplay with enough<br>
checks is worth tinkering a bit. All the other settings are less difficult,
checks is worth tinkering a bit. All the other settings are less difficult,<br>
like setting up what todo when something shows up out of the ordinary.
like setting up what todo when something shows up out of the ordinary.<br>


Please note that practically ALL settings require a map switch to take effect
Please note that practically ALL settings require a map switch to take effect<br>
if you change them during runtime.
if you change them during runtime.<br>




Line 101: Line 101:
- Settings "Integrity Server" -
- Settings "Integrity Server" -


AllowedConsoles
AllowedConsoles<br>
   Unreal Integrity retrieves the client's console and compares it to this list
   Unreal Integrity retrieves the client's console and compares it to this list<br>
   of allowed consoles. If you run mods on your server, you may want to add in
   of allowed consoles. If you run mods on your server, you may want to add in<br>
   the console of your mod.
   the console of your mod.<br>
   (Related: event_IllegalConsole)
   (Related: event_IllegalConsole)<br>




bUseUTeamFixIfAvailable
bUseUTeamFixIfAvailable<br>
Unreal Integrity will determine if you are using UTeamFix (not which version
Unreal Integrity will determine if you are using UTeamFix (not which version<br>
though) and this variable is true will try to utilize it for session bans.
though) and this variable is true will try to utilize it for session bans.<br>
The difference with UTF's session banning method are these, that the banned
The difference with UTF's session banning method are these, that the banned<br>
player IP will get a message that there is a temporary ban in effect,
player IP will get a message that there is a temporary ban in effect,<br>
whereas using the 227 native temporary banning will have the player join and
whereas using the 227 native temporary banning will have the player join and<br>
be instant-kicked. The native 227 banning does name bannd too though.
be instant-kicked. The native 227 banning does name bannd too though.<br>
If you are using an older version of UTeamFix (pre 9F) you should keep this
If you are using an older version of UTeamFix (pre 9F) you should keep this<br>
disabled. Also, since UTF-temp banned players are rejected at PRELOGIN
disabled. Also, since UTF-temp banned players are rejected at PRELOGIN<br>
rather than kicked, the server will receive 5 or 6 late UDP packets from
rather than kicked, the server will receive 5 or 6 late UDP packets from<br>
them if the UTF-banning is enabled (whether or not that is critical or
them if the UTF-banning is enabled (whether or not that is critical or<br>
even worth mentioning is beyond me though...).
even worth mentioning is beyond me though...).<br>




bUseSlowReplication and SlowReplicationSpeed
bUseSlowReplication and SlowReplicationSpeed<br>
These two settings go together.
These two settings go together.<br>
Unreal Integrity was first developed for speed and efficiency, but since
Unreal Integrity was first developed for speed and efficiency, but since<br>
client checks take a lot of cpu and bandwidth power, this will often cause
client checks take a lot of cpu and bandwidth power, this will often cause<br>
problems on real life internet servers and different clients. The sheer
problems on real life internet servers and different clients. The sheer<br>
amount of data transmitted hence and forth can lag out slower or
amount of data transmitted hence and forth can lag out slower or<br>
low-bandwidth clients completely, cause false alerts etc.
low-bandwidth clients completely, cause false alerts etc.<br>
Turning on "bUseSlowReplication" will CONSIDERABLY increase the time a
Turning on "bUseSlowReplication" will CONSIDERABLY increase the time a<br>
complete check takes in game. You will need about 3 to 5 times increased
complete check takes in game. You will need about 3 to 5 times increased<br>
TIMING settings as well. The setting "SlowReplicationSpeed" is indeed a
TIMING settings as well. The setting "SlowReplicationSpeed" is indeed a<br>
delay factor, so "higher" means "slower", doubling the value indeed
delay factor, so "higher" means "slower", doubling the value indeed<br>
doubles the time a full check takes to complete, and thus doubles your
doubles the time a full check takes to complete, and thus doubles your<br>
leniency factors you have to put in your timing settings accordingly.
leniency factors you have to put in your timing settings accordingly.<br>




ClientDetectionMethod
ClientDetectionMethod<br>
Unreal Integrity uses a combination of methods to detect loaded packages.
Unreal Integrity uses a combination of methods to detect loaded packages.<br>
The "Complete" method is rather strict and looks up -ALL- loaded packages,
The "Complete" method is rather strict and looks up -ALL- loaded packages,<br>
whereas the "Smart" one is less strict and only looks up the "critical"
whereas the "Smart" one is less strict and only looks up the "critical"<br>
ones, lessening the load on servers and clients.
ones, lessening the load on servers and clients.<br>
If you are not sure about a player you can change the method once in a while,
If you are not sure about a player you can change the method once in a while,<br>
but be aware of the following consequences:
but be aware of the following consequences:<br>
If this setting is "Complete", all custom S3TC packages that have not been
If this setting is "Complete", all custom S3TC packages that have not been<br>
whitelisted will remove players from the game. Also the "Complete" setting
whitelisted will remove players from the game. Also the "Complete" setting<br>
may yield more lag and more cpu pressure on both server and clients. The
may yield more lag and more cpu pressure on both server and clients. The<br>
"Complete" method is more likely to result in "innocent" kicks from
"Complete" method is more likely to result in "innocent" kicks from<br>
packages a client may have loaded from its last server visit or offline
packages a client may have loaded from its last server visit or offline<br>
play. You may need to increase the response time limits to allow for the
play. You may need to increase the response time limits to allow for the<br>
increased load to pass without timeouts. This is especially true for
increased load to pass without timeouts. This is especially true for<br>
slow-cpu clients!
slow-cpu clients!<br>




Events
Events<br>
   An event is when something "shows up on the screen" so to speak, and every
   An event is when something "shows up on the screen" so to speak, and every<br>
   event can be responded to (or ignored) depending on its settings:
   event can be responded to (or ignored) depending on its settings:<br>
     bTellPlayers
     bTellPlayers<br>
     If enabled, all players in the server are being told that a player
     If enabled, all players in the server are being told that a player<br>
     raised an event.
     raised an event.<br>
     bKick
     bKick<br>
       If enabled, the player will be KICKED from the server who raised this
       If enabled, the player will be KICKED from the server who raised this<br>
     bSessionBan
     bSessionBan<br>
       If enabled, the player who raised the event will be KICKED and BANNED
       If enabled, the player who raised the event will be KICKED and BANNED<br>
       until the map changes.
       until the map changes.<br>
     offenseName
     offenseName<br>
       This is a human readable explanation of the raised event such as "has
       This is a human readable explanation of the raised event such as "has<br>
       an unknown package".
       an unknown package".<br>
     message1-4
     message1-4<br>
       Up to four lines of text can be sent to the client as added information
       Up to four lines of text can be sent to the client as added information<br>
       to a raised event. For example, you can tell the player not to do a
       to a raised event. For example, you can tell the player not to do a<br>
       stupid thing as this or that when playing on your server.
       stupid thing as this or that when playing on your server.<br>
       If a raised event kicked the player, that player will see all these
       If a raised event kicked the player, that player will see all these<br>
       messages AFTER being removed from the server!
       messages AFTER being removed from the server!<br>
       All in all, about 100 lines of text can be sent to the player in total.
       All in all, about 100 lines of text can be sent to the player in total.<br>


   event_ClientTimeOut
   event_ClientTimeOut<br>
     This event is raised if a client times out during a check. Since
     This event is raised if a client times out during a check. Since<br>
     non-responding to a server request is potentially dangerous (the client
     non-responding to a server request is potentially dangerous (the client<br>
     part could be hacked to hinder it from sending a reply), non-responding
     part could be hacked to hinder it from sending a reply), non-responding<br>
     should be answered at least with a kick. If lag is so bad that the player
     should be answered at least with a kick. If lag is so bad that the player<br>
     keeps timing out, it is no good to play anyway so not much harm done in
     keeps timing out, it is no good to play anyway so not much harm done in<br>
     that case either ;)
     that case either ;)<br>
event_FakeComputername
event_FakeComputername<br>
  Computer names can be fabricated in Unreal. If an "obvious" fabrication is
  Computer names can be fabricated in Unreal. If an "obvious" fabrication is<br>
  found, this event is raised. Fake computer names pose no security threat,
  found, this event is raised. Fake computer names pose no security threat,<br>
  so by default nothing happens when this event is raised. It is up to the
  so by default nothing happens when this event is raised. It is up to the<br>
  admin to either feel comfortable with players using obvious fabrications
  admin to either feel comfortable with players using obvious fabrications<br>
  or not.
  or not.<br>
event_OldVersion
event_OldVersion<br>
  Since full checks of Unreal Integrity only work on 227 clients and not on
  Since full checks of Unreal Integrity only work on 227 clients and not on<br>
  older clients, it can not ensure any security for these old clients. So...
  older clients, it can not ensure any security for these old clients. So...<br>
  you could just circumvent all checks by using an old Unreal version...
  you could just circumvent all checks by using an old Unreal version...<br>
  This option enables admins to respond to old versions, kicking players and
  This option enables admins to respond to old versions, kicking players and<br>
  telling them to upgrade. An ideal place to advertise your website with the
  telling them to upgrade. An ideal place to advertise your website with the<br>
  227 patch for download is the message1-4 field of this event!
  227 patch for download is the message1-4 field of this event!<br>
event_IllegalConsole
event_IllegalConsole<br>
  If an unknown (not white-listed) console name is found, this event is
  If an unknown (not white-listed) console name is found, this event is<br>
  raised. Very primitive bots use custom consoles, but this check does not
  raised. Very primitive bots use custom consoles, but this check does not<br>
  generally prove to be very difficult to get by with a cheat, but still it
  generally prove to be very difficult to get by with a cheat, but still it<br>
  works on older clients too and it does about as much as Hackbuster 2...
  works on older clients too and it does about as much as Hackbuster 2...<br>
  just without the lag HB2 creates :)
  just without the lag HB2 creates :)<br>
  (Related: AllowedConsoles)
  (Related: AllowedConsoles)<br>
event_IllegalClientRequest
event_IllegalClientRequest<br>
  Illegal client requests occur when certain messages from the client are
  Illegal client requests occur when certain messages from the client are<br>
  garbled or incomplete. This can be accidental (lag), or malicious (hacked
  garbled or incomplete. This can be accidental (lag), or malicious (hacked<br>
  client). Either way, a reaction should follow this event, at least a kick.
  client). Either way, a reaction should follow this event, at least a kick.<br>
event_UnknownPackage
event_UnknownPackage<br>
  If a client is found with a package in memory that the server does not
  If a client is found with a package in memory that the server does not<br>
  know. Practically every advanced script bot will show up this way, but
  know. Practically every advanced script bot will show up this way, but<br>
  also harmless skin textures that the client loaded by accident. Either way
  also harmless skin textures that the client loaded by accident. Either way<br>
  this event should raise an eyebrow and certainly warrants a kick.
  this event should raise an eyebrow and certainly warrants a kick.<br>
event_ModifiedPackage
event_ModifiedPackage<br>
  A modified package is outright BAD! It means a player has messed with a
  A modified package is outright BAD! It means a player has messed with a<br>
  file that should have been left alone. This may also happen with some mods
  file that should have been left alone. This may also happen with some mods<br>
  when client and server are out of synch but netcompatible, so in these
  when client and server are out of synch but netcompatible, so in these<br>
  cases clients should update their file. Either way, a kick is in order
  cases clients should update their file. Either way, a kick is in order<br>
  because the modification may just as well be malicious.
  because the modification may just as well be malicious.<br>
event_FabricatedReply
event_FabricatedReply<br>
  Some modified and hacked clients try to trick anti-cheat programs by
  Some modified and hacked clients try to trick anti-cheat programs by<br>
  faking replies to common requests. Hopefully most fabricated replies
  faking replies to common requests. Hopefully most fabricated replies<br>
  should be detectable but in some cases lag may also be responsible for
  should be detectable but in some cases lag may also be responsible for<br>
  a partially garbled or incomplete reply which may then accidently raise
  a partially garbled or incomplete reply which may then accidently raise<br>
  this event. Appropriate reply is at least a kick, if the same player shows
  this event. Appropriate reply is at least a kick, if the same player shows<br>
  up REPEATEDLY with this "problem", consider a firewall-ban because he's a
  up REPEATEDLY with this "problem", consider a firewall-ban because he's a<br>
  hacker!
  hacker!<br>
event_SuspiciousPackageName
event_SuspiciousPackageName<br>
  This is an eyebrow raising event, because basically it means the client
  This is an eyebrow raising event, because basically it means the client<br>
  replied with a checksum of a whitelisted or known file, but the filename
  replied with a checksum of a whitelisted or known file, but the filename<br>
  was different. This may not be critical in all circumstances and a case by
  was different. This may not be critical in all circumstances and a case by<br>
  case study is appropriate.
  case study is appropriate.<br>






IngameChecks
IngameChecks<br>
   bEnableIngameChecks
   bEnableIngameChecks<br>
     Wether or not to enable in-game checking. If false, players are checked
     Wether or not to enable in-game checking. If false, players are checked<br>
     through only ONCE right after they join. Since some cheats can be loaded
     through only ONCE right after they join. Since some cheats can be loaded<br>
     during runtime, it is highly recommended to enable ingame checks, however.
     during runtime, it is highly recommended to enable ingame checks, however.<br>
   bAlwaysFullCheck
   bAlwaysFullCheck<br>
   There are 2 types of checks ingame, a short and a full check. The short
   There are 2 types of checks ingame, a short and a full check. The short<br>
   check calculates a bunch of checksums and as long as they keep matchng
   check calculates a bunch of checksums and as long as they keep matchng<br>
   over time, the client has not loaded or unloaded any packages and thus
   over time, the client has not loaded or unloaded any packages and thus<br>
   does not need to be examined in full again.
   does not need to be examined in full again.<br>
   The short check is much faster than a full check, so the lag spike during
   The short check is much faster than a full check, so the lag spike during<br>
   game is notably shorter when it occurs. If you want to forego the short
   game is notably shorter when it occurs. If you want to forego the short<br>
   check, and ALWAYS check players in full, enable this setting.
   check, and ALWAYS check players in full, enable this setting.<br>
   bOneVSOneServer
   bOneVSOneServer<br>
   If you run standoff / LMS or 1vs1 servers, this might be a good option to
   If you run standoff / LMS or 1vs1 servers, this might be a good option to<br>
   enable. If this setting is on, the server will also try to recheck ALL
   enable. If this setting is on, the server will also try to recheck ALL<br>
   players when there is only ONE SINGLE player alive. This is very useful
   players when there is only ONE SINGLE player alive. This is very useful<br>
   in 1vs1, because the sutviving player may be checked as well as the killed
   in 1vs1, because the surviving player may be checked as well as the killed<br>
   player after a kill, rather than ONLY the dead player.
   player after a kill, rather than ONLY the dead player.<br>
   Likewise, in round-based games / Standoff or LMS, it may happen that from
   Likewise, in round-based games / Standoff or LMS, it may happen that from<br>
   all teams only one keeps standing alive at the end of a round, the ideal
   all teams only one keeps standing alive at the end of a round, the ideal<br>
   time to recheck every player (including the survivor).
   time to recheck every player (including the survivor).<br>
   Servers running mods that implement the 227 Interface may not need this
   Servers running mods that implement the 227 Interface may not need this<br>
   setting, since the mod then takes care of the proper timing of re-checks.
   setting, since the mod then takes care of the proper timing of re-checks.<br>
   bUnUsualPlayerPawns
   bUnUsualPlayerPawns<br>
   Unreal Integrity uses carcass-detection (yes I know, that sounds a bit
   Unreal Integrity uses carcass-detection (yes I know, that sounds a bit<br>
   morbid...) to see which player died. Since there are monsters in Unreal,
   morbid...) to see which player died. Since there are monsters in Unreal,<br>
   by default only the known human carcasses are detected as well as the
   by default only the known human carcasses are detected as well as the<br>
   trooper carcass from the Skaarjplayer.
   trooper carcass from the Skaarjplayer.<br>
   (***TODO**** OPEN ISSUE: NALI PLAYER)
   (***TODO**** OPEN ISSUE: NALI PLAYER)<br>
   This saves some CPU power and is good enough for all normal servers, but
   This saves some CPU power and is good enough for all normal servers, but<br>
   if you run mods where players can be monsters or non-standard creatures,
   if you run mods where players can be monsters or non-standard creatures,<br>
   Unreal Integrity will be unable to detect when these players die. For such
   Unreal Integrity will be unable to detect when these players die. For such<br>
   servers, this setting must be enabled because then all carcasses are seen
   servers, this setting must be enabled because then all carcasses are seen<br>
   and matched against existing players. Of course, thid does cost a few CPU
   and matched against existing players. Of course, thid does cost a few CPU<br>
   cycles every time a normal monster is killed, but that's the tradeoff.
   cycles every time a normal monster is killed, but that's the tradeoff.<br>
   Actually, on today's GHZ CPUs, it shouldn't matter one way or another, but
   Actually, on today's GHZ CPUs, it shouldn't matter one way or another, but<br>
   it's always better to have room for optimization :)
   it's always better to have room for optimization :)<br>
   minTimeRecheck
   minTimeRecheck<br>
   The minimum amount of time (in seconds) that must pass before a player
   The minimum amount of time (in seconds) that must pass before a player<br>
   that has been checked can be checked again. So, if a player died and was
   that has been checked can be checked again. So, if a player died and was<br>
   checked, then keeps dying several times in a row, no rechecks will occur
   checked, then keeps dying several times in a row, no rechecks will occur<br>
   until this timer is exceeded.
   until this timer is exceeded.<br>
   maxTimeRecheck
   maxTimeRecheck<br>
     The maximum amount of time (in seconds) which represents the absolte limit
     The maximum amount of time (in seconds) which represents the absolte limit<br>
     a player is allowed to run around without being checked again.
     a player is allowed to run around without being checked again.<br>






NeedNotHavePackageList
NeedNotHavePackageList<br>
This is a list of packages you can choose the client needs NOT send in a
This is a list of packages you can choose the client needs NOT send in a<br>
full check.
full check.<br>
In some rare circumstances, it may happen that this or that package ends
In some rare circumstances, it may happen that this or that package ends<br>
on the internal list of packages the server expects the client to see and
on the internal list of packages the server expects the client to see and<br>
actually send a valid checksum for it. If the client does not see a package
actually send a valid checksum for it. If the client does not see a package<br>
and thus fails to send the checksum, the server will assume a fabricated
and thus fails to send the checksum, the server will assume a fabricated<br>
reply and thus a hacked client.
reply and thus a hacked client.<br>
Obviously, if this problem suddenly appears for ALL players after installing
Obviously, if this problem suddenly appears for ALL players after installing<br>
a new mod, then you have found one of those exots that need to be put in this
a new mod, then you have found one of those exots that need to be put in this<br>
list. Just enter the package name (file name without extension).
list. Just enter the package name (file name without extension).<br>






Timings
Timings<br>
   initialTimeout
   initialTimeout<br>
     When the player just joined, this is the amount of time (in seconds) it
     When the player just joined, this is the amount of time (in seconds) it<br>
     is allowed to take for an initial reply. This setting is extra because
     is allowed to take for an initial reply. This setting is extra because<br>
     very often lag and packet loss are responsible for a hitched
     very often lag and packet loss are responsible for a hitched<br>
     initialization process, so players which just joined should be granted
     initialization process, so players which just joined should be granted<br>
     some extra lenience compared to players that are already connected fully
     some extra lenience compared to players that are already connected fully<br>
     to the server.
     to the server.<br>
   shortReplyTimeout=3
   shortReplyTimeout=3<br>
     The amount of time (in seconds) a client is allowed to take replying to a
     The amount of time (in seconds) a client is allowed to take replying to a<br>
     short request (such as the short check or giving computer name, version
     short request (such as the short check or giving computer name, version<br>
     info etc). "shortReplies" are such that consist of one single reply so
     info etc). "shortReplies" are such that consist of one single reply so<br>
     they are expected to occur within one or 2 ping cycles.
     they are expected to occur within one or 2 ping cycles.<br>
   fullCheckTimeout
   fullCheckTimeout<br>
     A full check takes notably longer than any single-reply request from the
     A full check takes notably longer than any single-reply request from the<br>
     server, so the amount of time allowed for the client to reply to it (in
     server, so the amount of time allowed for the client to reply to it (in<br>
     seconds) should be notably higher as well.
     seconds) should be notably higher as well.<br>




Verbosity (How much stuff you want in your logs?)
Verbosity (How much stuff you want in your logs?)<br>
   bLogInit
   bLogInit<br>
     If true, all startup, pre- and postcaching of loaded packages on the
     If true, all startup, pre- and postcaching of loaded packages on the<br>
     server is being logged. If you ever run into a very strange problem where
     server is being logged. If you ever run into a very strange problem where<br>
     you are certain the server should actually KNOW a certain package, this is
     you are certain the server should actually KNOW a certain package, this is<br>
     what to use to discern if it was truly loaded on startup.
     what to use to discern if it was truly loaded on startup.<br>
   bLogClientIDs
   bLogClientIDs<br>
     If enabled, game version, computer name and Consoles of clients are
     If enabled, game version, computer name and Consoles of clients are<br>
     logged.
     logged.<br>
   bLogClientChecks
   bLogClientChecks<br>
     If enabled, all checks that occur during runtime are logged in detail.
     If enabled, all checks that occur during runtime are logged in detail.<br>




Line 332: Line 332:
- Settings "Whitelist" -
- Settings "Whitelist" -


Administrators can choose to enter their own packages freely in this list.
Administrators can choose to enter their own packages freely in this list.<br>
Unreal Integrity will treat all entries (if enabled) as pre-loaded as if the
Unreal Integrity will treat all entries (if enabled) as pre-loaded as if the<br>
file was loaded at startup.
file was loaded at startup.<br>
 
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.
 


In order to use the Whitelist, just enter the package name (for DLL/SO files<br>
use: "./[filename.library]"), enter the MD5 checksum (CRC) in the CRC field,<br>
and enable the entry. You can turn entries on and off without clearing the<br>
actual entries.<br>


NOTE: If you got your release with one or more entries filled, do not remove<br>
them.<br>


== 6) Legal notice ==
== 6) Legal notice ==

Revision as of 18:28, 12 November 2008

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