Introduction:

SpeedBlock is Gothic 2 Online module consisting of both server and client side components. It allows to detect undesirable (game process) speed changes performed by using applications such as Cheat Engine and measure speed multiplier with an accuracy of 0.001. Any reactions and penalties are configurable via adding handlers to provided server-side events. False positive results are very unlikely to happen.

Server-side events:

onSpeedHackDetect(int pid, float multiplier) - called if measured player speed multiplier for player is incorect. Provides measured multiplier as parameter.

onSpeedBlockModuleMissing(int pid) - called if player has no module, module is not loaded on client side or module file hash mismatch occurs. Event won't be called right after player joins, it will trigger in few seconds - this allows to prevent false positive on overloaded server. If you wish to detect missing module on client-side instantly, you should use custom script similar to presented below.

onSpeedBlockModuleError(int pid) - rare event occuring only when someone is trying to mess with module protection algorithm. Should be also penalised.

Example implementation:


For instantly detecting missing module on client-side, include in onInit:



Download links:

Client Module (Windows) - SpeedBlock.dll
SHA256: 9369ae58679040f2c2e657779f79dbe864d967ae54582536f18d4564dfbfcec7

Server Module (Windows) - SpeedBlockServer.dll
SHA256: fc8ac3cfc67208ec4b6f987b977c9567246048d14ad630096b2d731688151397

Server Module (Linux) - SpeedBlockServer.so
SHA256: 3ca49fbf140291ac28887590630e8d85d176e7670febe1a229ca10e8d62e3f63

Configuration (exact while placing server-side modules in main server directory):

Client module should be placed in Multiplayer/Modules folder and in a desired server directory.

For both Windows and Linux based servers, add line to config.xml:


If hosting server on Windows, add another line:


If hosting server on Linux, add line:


For Linux version, it might be required to put ./ before module names/directories. Example:

Super opcja, zastanawiałeś się nad wykryciem procesu cheat engine ?

(24.06.2020, 07:45)Quarchodron Wrote: Super opcja, zastanawiałeś się nad wykryciem procesu cheat engine ?

Tak, ale zrezygnowałem z tego pomysłu ze względu na dość banalne obejścia wykrywania procesu czy samego dołączania do procesu. Przy czym istnieją różne inne programy oferujące to, co Cheat Engine, włącznie z takimi które można napisać. Moduł wykazuje nieprawidłowości poprzez wykrycie innych niż spodziewane wyników wywołań funkcji jądra systemu, przez co blokuje sam fakt, a nie wybiórczo jeden ze sposobów. Jeżeli chodzi o inne zastosowania Cheat Engine'a, najlepszą metodą jest przyjęcie założenia, że klient może zmodyfikować wszystko, wobec czego niezbędna jest walidacja po stronie serwera.

Tak, to o czym mówisz wiadome jest dość długo przy czym to co mówisz jest oczywiście prawdą. Problemem wg mnie jest że zablokowanie najpopularniejszych procesów tego typu programów dałoby dużo. Teraz każdy bez wiedzy o programowaniu czy nawet jakiejkolwiek glębszej może użyć tych narzędzi. Fajnie byłoby mieć moduł, ktory to blokuje. Przypuszczam, że wtedy zablokowalibyśmy większość takich prób, które obecnie wykrywamy. Z doświadczenia wiem (Elisium), że 90% osób zmieniających cokolwiek robi to przez cheat engine.

Póki co moduł będzie funkcjonował w ramach pojedynczej odpowiedzialności. W obecnym wariancie jest dość oszczędny jeśli chodzi o wykorzystanie pakietów, co pozostawia pewne wektory ataku, jeśli ktoś z odpowiednią wiedzą mocno się uprze. Nie wykluczam zmiany pod tym względem, jeśli znajdzie się powszechne obejście. W przyszłości może wejść w skład większego modułu, zawierającego wykrywanie popularnych programów tego typu, czy też np. umożliwiającego blokadę teleportacji poprzez DX11 przy zachowaniu pozostałych funkcji. Wtedy uwspólnienie algorytmu weryfikującego poprawność wczytania modułu i przesyłanych pakietów będzie optymalnym rozwiązaniem pod względem minimalizacji komunikacji klient-serwer.

Powodzenia

Edit: onSpeedBlockModuleMissing event description with custom client script to instantly detect missing module.

IMO same can be done in pure scripts, also how someone can know for sure if you didn't include some malicious code into your module?

Quarchodron Wrote:Super opcja, zastanawiałeś się nad wykryciem procesu cheat engine ?

Instead detecting cheat engine process, you can for example, detect dll injection.
https://reverseengineering.stackexchange...e-detected

Detecting one program isn't a good option, this can be easilly bypassed:
https://itstillworks.com/12458787/how-to...ocess-name
https://forum.cheatengine.org/viewtopic....063c0b99be

Keep in mind that any detection like this on c-side can be easily bypassed by an expierenced reverser.
You could also monitor some values periodically and check if their content is valid.

IMO it's better to focus on implementing server-side secure code, rather than making client-side security systems which can be bypassed one way or another.

Why do the module? After all, you can do the same with scripts and why the module is not open source

Any form of process detection or injection detection can be easily bypassed, that's true. That's why this module has two communicating components with server-side validation.

It's not an open source to make eventual bypass methods less obvious. And no, you can't do the same in pure scripts. While large chunk of this module contains Squirrel script compiled on load (GO doesn't support pre-compiled scripts), you can't achieve the same range of measurement accuracy with functions that go through Squirrel Virtual Machine. Client scripts can also be manipulated while module contains some special algorithm to detect that it's loaded and in desired form.

No one can know for sure if I didn't include any malicious code into module. Same goes to GO, Windows, vaccines, etc.
You can also check Virus Total reports on files:

VirusTotal - SpeedBlock.dll

VirusTotal - SpeedBlockServer.dll

VirustTotal - SpeedBlockServer.so

I've got some feedback that the module sometimes trigger false positive for some players. Unfortunately, I wasn't able to reproduce this error with simulation of load and latency.
If such problem occurs, you can resolve it with setting some tolerance to estimated multiplier, by modifying server script code like this:


Where x is maximum tolerated multiplier (like 1.015).
Other option is to store counter of wrong multiplier values in some players data structure, together with multiplier. Then, you can check if the same multiplier occurs consistently. There high probability that false positive will produce other multiplier on different estimation.