Difference between revisions of "Integrity (Anticheat)"

From Oldunreal-Wiki
Jump to navigation Jump to search
Tag: New redirect
 
(24 intermediate revisions by 4 users not shown)
Line 1: Line 1:
'''Full anticheat protection 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.'''
#REDIRECT [[Unreal v227 Manual/Server admin tools]]
 
 
== 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 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 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=UnrealIntegrity
 
 
for older release up to 227h see:
 
[[old Integrity (up to 227h)]]
 
== 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 by adding the
package's main mutator on the server startup
(UnrealIntegrity.IntegrityServer):
 
Unreal.exe ...Game?Mutator=UnrealIntegrity.IntegrityServer ...
 
== 5) Settings and Ini ==
 
Settings are saved in your Unreal.ini. The settings can be accessed at:<br>
Advanced Options -> Networking -> Unreal Integrity 227<br>
 
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.<br>
More consideration to some settings are required for...<br>
- Last Man Standing / Standoff / Round Based ...<br>
- Duelling ...<br>
- Specially modded...<br>
...servers.<br>
 
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<br>
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<br>
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<br>
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<br>
by default checks already appear in "opportune" moments, such as:<br>
1. Player just joined (initial full check)<br>
2. Player died (in game death check)<br>
3. Player is the only player alive (1vs1 setting)<br>
4. A round is over (see chapter about "Mod Considerations")<br>
5. The game ended<br>
 
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<br>
the timer of the maximum amount of time a player can run around without being<br>
checked again is hit!<br>
 
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,<br>
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<br>
if you change them during runtime.<br>
 
 
 
- SHALinkerCache.ini -
 
This new ini takes care about the checksums used to validate the client.
All packages to be validated need to be entered here.
However, you don't need to add it manually, there are new commands to do this for you.
There are 2 types of sections:
 
[Linker]
 
This section contains linker information about .u files and provides basic security against modified files and hacks. This protection was specifically implemented to check pre 227 clients and should be able to detect the currently known bots and cheats.
Note that this protection is limited to Unreal packages (no dll and exe files) and may not be able to detect newer cheats.
227i contains already the checksums of the older clients for 224,225,226b and 226f as well as some popular packages.
To add more entries use the command:
 
ucc engine.linkerupdate <path>\<filename>.<extension> and accepts also *.
 
Example: ucc engine.linkerupdate .\*.u
 
this way you can easily add the custom packages running on your server.
 
[SHA]
 
This section contains SHA256 checksums for the files of 227i clients. These checksums are used to validate all files in use, including native .exe and .dll files (also applies to Linux .so and .bin files) and is way extensive than the checks possible on pre 227i clients.
 
To add new entries you can use the command:
 
ucc engine.shaupdate <path>\<filename>.<extension> and accepts also *.
 
Example: ucc engine.shaupdate ..\SystemClassic\*
 
(this will create checksums for every file but it makes no sense for .ini files)
 
It is also possible to use some other tool to create the SHA256 checkum and add it manually.
 
== 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:<br>
  // 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.
 
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".
[[Category:General]]
[[Category:Server]]

Latest revision as of 19:47, 27 June 2022

Redirect to:

Retrieved from "https://www.oldunreal.com/wiki/index.php?title=Integrity_(Anticheat)&oldid=21943"