Forks: Difference between revisions

From Multi Theft Auto: Wiki
Jump to navigation Jump to search
m (t)
mNo edit summary
 
(18 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''This page is meant to be informative for the creators and maintainers of custom MTA builds or forked projects based on the MTA source code. We often get questions related to AC support for them.
__NOTOC__ {{Note|Information on this page does not apply to the official builds of MTA.}}
'''<br />Information contained on this page isn't relevant for the official MTA build or releases, or open-source contribution to the official MTA repository at https://github.com/multitheftauto/mtasa-blue


Custom MTA builds and forked projects (as a lot of russian ones exist) that made their own game platform using the MTA source code, will face some challenges relating to anti-cheat.
Multi Theft Auto is open-source software, freely available on [https://github.com/multitheftauto/mtasa-blue GitHub multitheftauto/mtasa-blue].
Anyone is free to fork the project as long as they abide by the terms of our license, The GNU General Public License v3.


<br />Anti-cheat (also called: AC) support is very limited on custom builds/forked projects, and may be dropped entirely in the future (this is actually being considered). You cannot rely on the MTA anti-cheat for your project, or the limited and very basic support that remains in netc.dll for custom projects.
You can find explanations of the GNU GPL v3 here: [https://choosealicense.com/licenses/gpl-3.0/ choosealicense.com] and [https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) tldrlegal.com]. Our [https://github.com/multitheftauto/mtasa-blue/blob/master/LICENSE license] takes precedence, but this generally means that you must:
<br />'''We strongly advise that you write and implement your own anti-cheat.'''


If you cannot do that, and want to use the very limited anti-cheat offered to custom projects, even though we discourage it you can optimize it by the following steps/design choices to still get the most out of limited support (and not hinder it):
* state significant changes made to the software
* disclose the source code
* share your code under the same license
* include the original copyright notice


<br />- Always use the latest version of netc.dll (closed-source) e.g from https://mirror.mtasa.com/bdata/netc.dll and https://mirror.mtasa.com/bdata/net.dll matching the master branch of your base MTA source used for fork, actually you can use the latest module always unless MTA commits changed bitstream code or you did
If you are working on a fork, we ask that you include a link to your homepage and where we can find the source code. This allows us to keep up to date on projects and even introduce improvements to the vast majority of MTA players. Adding your Discord name is not compulsory, but if you ask for development help on our GitHub, forum or Discord, it helps us know what project you are from and that you are abiding by the license.
<br />The "bdata" modules are specifically for custom builds & forks and fetched by running https://github.com/multitheftauto/mtasa-blue/blob/master/win-build.bat
<br />- Never block MTAHQ/client or server traffic in your project


== Forks and anti-cheat==


(from https://wiki.multitheftauto.com/wiki/Anti-cheat_support_for_custom_builds)


<br />If you don't do this and don't have professional developers to write good anti-cheat, then your fork will be more infested with cheaters than other forks enjoying the limited anticheat protection.
=== '''// UPDATE (December 2022)''' ===
<br />A good approach is to write and implement (to your custom build) some of the 'missing' anticheat features yourself, see below:
You can now leverage "full Anticheat for forks" as well. For more information, visit this article: '''[[Forks Full AC]]'''<br><br>


'''AC missing on forks/custom builds:'''
.. But otherwise
* No detection of changes to gta_sa code section
* No detection of changes to certain gta_sa variables
* SetElementData not protected against external changes
* No detection against various Lua injection methods
* Much less AC heuristics and protection of internals
* Continuous updates for all patched methods to write cheats based on (vulnerabilities) aren't guaranteed, although handpicked ones may occasionally land in custom project netc.dll updates.
This is one of the reasons why updating netc.dll to the latest offered version is beneficial.
* MTA dll's aren't checked for modifications or remote hooking/memory writing


Custom MTA builds and forked projects will face some challenges relating to anti-cheat (AC). Due to the fact that many forks and custom builds perform in ways that the anti-cheat module does not expect, we were forced to remove plenty of advanced detections and protections from the anti-cheat, in order to create and provide a separate module (the one from https://mirror.mtasa.com/bdata/netc.dll) that, simply put, is a much weaker anti-cheat than the 'real' MTA has. So, unless you take measures of your own, your forked project can (and will) easily become infested with cheaters. This can be sidestepped with [[Forks Full AC]] (click for article). But in the standard scenario, reading the below information helps.


There are more things missing that we won't mention here, for security reasons.
The anti-cheat and netcode components (netc.dll, net.dll, FairplayKD.sys) are, unlike MTA itself, closed-source, and therefore without informing yourself it would be hard to overcome the challenges.


AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally ''cannot'' rely on the MTA anti-cheat for your fork. '''We strongly advise that you write and implement your own AC.'''


If you cannot write your own AC, here are steps you can follow to get the most out of our (unsupported) AC:


The reason for limited support is that MTA AC is proprietary unlike MTA itself, and custom builds may do things differently that can set off AC and cause us to need to support custom builds, which we principally don't.
* Always use the version of our net modules (e.g [https://mirror.mtasa.com/bdata/netc.dll netc.dll] and [https://mirror.mtasa.com/bdata/net.dll net.dll]) that matches our commit on master that your fork is based on
<br />Therefore, laxing it up minimizes the issues that can arise, leaving custom builds a lot of freedom to do awkward things (such as incorrect practise and programming, hacky things) in networking layer or memory.
** To be specific, you can use the latest module that is bitstream version compatible
<br />Basically, to keep it simple, custom projects can deviate in ways that requires adapting of the anti-cheat. Since our anti-cheat is closed source, you cannot do that, and our volunteers reasonably won't be customizing OUR anti-cheat for such projects.
** You can fetch these modules by running https://github.com/multitheftauto/mtasa-blue/blob/master/win-build.bat
* Never block any MTA traffic (client and server communicates with official MTAHQ servers) in your project
'''* Make sure to use 'unstable' build type and not 'custom', or else the 15% AC features for "bdata forks netc" goes down to 1%. See build type documentation at [https://github.com/multitheftauto/mtasa-blue/blob/master/Shared/sdk/version.h mtasa-blue/Shared/sdk/version.h] for details and proper configuration'''


<br />Note: to visualise it, most of what works (for the 'limited' anti-cheat support that exists for custom projects) are some signature-based detections. No heuristics, patched methods, security by design and patched vulnerabilities.
=== AC features missing in custom builds ===
<br />Signature-based detections of known hacktools and cheats are the weakest possible, and the anti-cheat in the official MTA tackles the actual problem rather than using signatures.
* No detection of changes to gta_sa code section
* No detection of changes to certain gta_sa variables
* No detection against memory modification
* No detection against various Lua injection methods
* SetElementData not protected against external changes by hacks
* Much fewer AC heuristics and protection of internals
* Continuous updates for all patched methods and vulnerabilities to write cheats based on aren't guaranteed (occasionally, they are cherry-picked; one of the reasons why updating netc.dll to the latest offered version is beneficial). This is the biggest (and most important) part of the original anti-cheat.
* MTA modules aren't checked for modifications or remote hooking/manipulation
* and much more


Note: while AC in MTA official version is one of the strongest around, custom builds clearly do not benefit from it and are like a second SA-MP as a result; cheaters everywhere, even s0beit might work, etcetera.
Generally, most of what will work are some signature-based detections. No heuristics, patched methods, and patched vulnerabilities. Signature-based detections are the weakest kind, and the mainstream anti-cheat tackles the actual problem rather than being signature-based. Note that certain forks (e.g the russian "MTA Province") have even less MTA anti-cheat support, so not even the minimal amount that most other forks enjoy. This is due to fork developers having the ability to completely block or break client > MTAHQ communication traffic (something we heavily rely on to help forks counteract cheating, as most regular AC features and protections aren't available), or do and change other things that from a technical perspective will cause AC features not to work as intended or fail immediately. If you don't want your fork to even become cheater-infested as much as "MTA Province" and how they call it, "their clones" (of Province).. in addition to having set buildtype to "custom" whereas it should be "unstable". Then now you hopefully know what to watch out for as fork developer. Also, it would be nice if this message reaches the developers of cheater-heavy forks like Province.
<br />So any project willing to take things seriously is advised to implement their own anti-cheat eventually, if they got developers experienced in that. Enough to eventually not rely on our limited one at all.
<br />Until then, or until adding some hard checks to minimize the problem, you might need actual admins to use their eyes against (old-school) cheating.


Additionally, MTA anti-cheat team does some additional, manual work to break up cheating on forks, e.g by causing occasional banwaves of known forks cheats using way too simple detection methods, on a best effort basis (without any guarantees). It is only meant as a courtesy from MTA, done when we feel like it, or maybe when you reach out to us.. and you cannot rely on it.
<br />
The aforementioned banwaves are known to result in bans with reasons that look similar to, and are known by cheaters as, "BAN: RPBOX / NEXTRP / PROVINCE CHEAT" (depending on the names of forks affected by a certain cheat) so please do not refer these users to MTA for ban appeals either.


<br />Also, MTA takes pride in its good anti-cheat for official builds. When we see a video of blatant cheating on custom projects (such as the prevalent russian ones), we always facepalm ourselves because there it's just so much easier.
[[Category:Development]]
<br />It is really sad to see that the maintainers of such projects aren't aware of the risks and actual situation, so that's why we are documenting it on this wiki page now. ===

Latest revision as of 11:00, 13 July 2024

[[{{{image}}}|link=|]] Note: Information on this page does not apply to the official builds of MTA.

Multi Theft Auto is open-source software, freely available on GitHub multitheftauto/mtasa-blue. Anyone is free to fork the project as long as they abide by the terms of our license, The GNU General Public License v3.

You can find explanations of the GNU GPL v3 here: choosealicense.com and tldrlegal.com. Our license takes precedence, but this generally means that you must:

  • state significant changes made to the software
  • disclose the source code
  • share your code under the same license
  • include the original copyright notice

If you are working on a fork, we ask that you include a link to your homepage and where we can find the source code. This allows us to keep up to date on projects and even introduce improvements to the vast majority of MTA players. Adding your Discord name is not compulsory, but if you ask for development help on our GitHub, forum or Discord, it helps us know what project you are from and that you are abiding by the license.

Forks and anti-cheat

(from https://wiki.multitheftauto.com/wiki/Anti-cheat_support_for_custom_builds)

// UPDATE (December 2022)

You can now leverage "full Anticheat for forks" as well. For more information, visit this article: Forks Full AC

.. But otherwise

Custom MTA builds and forked projects will face some challenges relating to anti-cheat (AC). Due to the fact that many forks and custom builds perform in ways that the anti-cheat module does not expect, we were forced to remove plenty of advanced detections and protections from the anti-cheat, in order to create and provide a separate module (the one from https://mirror.mtasa.com/bdata/netc.dll) that, simply put, is a much weaker anti-cheat than the 'real' MTA has. So, unless you take measures of your own, your forked project can (and will) easily become infested with cheaters. This can be sidestepped with Forks Full AC (click for article). But in the standard scenario, reading the below information helps.

The anti-cheat and netcode components (netc.dll, net.dll, FairplayKD.sys) are, unlike MTA itself, closed-source, and therefore without informing yourself it would be hard to overcome the challenges.

AC is generally unsupported for forked projects and may be dropped entirely in the future. This means that you generally cannot rely on the MTA anti-cheat for your fork. We strongly advise that you write and implement your own AC.

If you cannot write your own AC, here are steps you can follow to get the most out of our (unsupported) AC:

  • Always use the version of our net modules (e.g netc.dll and net.dll) that matches our commit on master that your fork is based on
  • Never block any MTA traffic (client and server communicates with official MTAHQ servers) in your project

* Make sure to use 'unstable' build type and not 'custom', or else the 15% AC features for "bdata forks netc" goes down to 1%. See build type documentation at mtasa-blue/Shared/sdk/version.h for details and proper configuration

AC features missing in custom builds

  • No detection of changes to gta_sa code section
  • No detection of changes to certain gta_sa variables
  • No detection against memory modification
  • No detection against various Lua injection methods
  • SetElementData not protected against external changes by hacks
  • Much fewer AC heuristics and protection of internals
  • Continuous updates for all patched methods and vulnerabilities to write cheats based on aren't guaranteed (occasionally, they are cherry-picked; one of the reasons why updating netc.dll to the latest offered version is beneficial). This is the biggest (and most important) part of the original anti-cheat.
  • MTA modules aren't checked for modifications or remote hooking/manipulation
  • and much more

Generally, most of what will work are some signature-based detections. No heuristics, patched methods, and patched vulnerabilities. Signature-based detections are the weakest kind, and the mainstream anti-cheat tackles the actual problem rather than being signature-based. Note that certain forks (e.g the russian "MTA Province") have even less MTA anti-cheat support, so not even the minimal amount that most other forks enjoy. This is due to fork developers having the ability to completely block or break client > MTAHQ communication traffic (something we heavily rely on to help forks counteract cheating, as most regular AC features and protections aren't available), or do and change other things that from a technical perspective will cause AC features not to work as intended or fail immediately. If you don't want your fork to even become cheater-infested as much as "MTA Province" and how they call it, "their clones" (of Province).. in addition to having set buildtype to "custom" whereas it should be "unstable". Then now you hopefully know what to watch out for as fork developer. Also, it would be nice if this message reaches the developers of cheater-heavy forks like Province.

Additionally, MTA anti-cheat team does some additional, manual work to break up cheating on forks, e.g by causing occasional banwaves of known forks cheats using way too simple detection methods, on a best effort basis (without any guarantees). It is only meant as a courtesy from MTA, done when we feel like it, or maybe when you reach out to us.. and you cannot rely on it.
The aforementioned banwaves are known to result in bans with reasons that look similar to, and are known by cheaters as, "BAN: RPBOX / NEXTRP / PROVINCE CHEAT" (depending on the names of forks affected by a certain cheat) so please do not refer these users to MTA for ban appeals either.