Cfx.re Monthly Update - April 2022 edition

Hello everyone! Due to some unforeseen developments, we’re late with April’s post and will move all updates to May’s update post instead. As such, we don’t have a lot to share today, though we do want to highlight the topics below. See you again next month!

Overwolf’s acquisition of Tebex

Tebex is now part of the Overwolf family. What does that mean for FiveM? Well, nothing changes for you: Tebex continues to operate as they do, and will now receive funding from Overwolf to expand their network and further improve their platform. Their product won’t change, nor will they be rebranded. Check out their announcement for full details!

Unauthorized ‘anti-cheat resources’

An update released last month for FiveM fixed an exploit in the client, which allowed servers to read specific memory on players’ systems. This one took a while to discover, as it was tied to what we call an “abusive anti-cheat”.

First off, FiveM has built-in client-side anti-cheating measures which are continuously being updated, in part based on your reports of runnable cheats. However, we are aware some server-side assets may be lacking validation of user input, and additional “anti-cheat” assets may very well be a valuable addition if you’re not able to rewrite the entire server code.

However, over time, we’ve seen an increase in the amount of unauthorized anti-cheat resources being sold, both directly against the Cfx.re ToS (on unauthorized stores), but also containing various user-hostile and project-hostile behaviors, some of which we have already documented before as being undesirable, others popping up over time.

In this case, however, a group developing such an anti-cheat asset had found a code execution vulnerability in the FiveM client, and instead of reporting it as one usually would, they decided to use it to add a detection vector to their (unauthorized, weirdly obfuscated, and otherwise bad-faith) anti-cheat resource for a few common cheat injections.

It is unknown why these people did such, as if they actually cared about improving the community or deterring cheaters, they’d have both reported the vulnerability and proposed these detection vectors so that cheaters would not only be banned from servers buying their resource, but would be banned from anywhere, without putting all players at risk from anyone else finding this vulnerability, placing it in for example a backdoored server resource (see the previous section) .

To help counter the growth of these ever-worsening abusive assets purporting to be “anti-cheat” systems, we will provide guidelines and a ‘focus group’ for third-party anti-cheat developers to adhere to, collaborate both with us and colleagues in their sector, and help users find safe, non-abusive choices for hardening their server’s security.

More on this in May’s update.

44 Likes

Thanks for the update peeps love yall loads <3
this one was kinda spooky :ghost:

3 Likes

this is awesome! :heart:

3 Likes

A lot of server owners turn to anticheat providers as a safeguard to protect themselves from the prevalence of users who in effect destroy community’s and will go server to server doing that. Its probably not helpful that a bug or exploit wasn’t elevated and reported to cfx however I couldn’t imagine chastising these guys would help encourage them to come to the table and report issues in the future. CFX is doing a good job but it seems like people are still getting though the cracks and will last a significant amount of time online before they get picked up by automated systems. The focus group is a great idea and a positive step to combatting these issues but more could be done.

6 Likes

How did you discover this “method”?

4 Likes

Client side dumping is a old issue.

FiveM Escrow System (currently) is the best encryption system for FiveM.

Why would FiveM not encrypt all the client side assets with their Escrow system and this, solving the issue with dumping and possibly exploiting events.

We all know, majority of public servers don’t have “professional” devs around them to help them code everything server side instead of “trusting” client. Even public frameworks lack security features.

Alot of qb-core events are not secured, I don’t even think its possible to secure event like “QBCore:Server:RemoveItem” without encrypting the lua file and making it weird event name where its impossible to guess the event and thus can stop exploits.

If FiveM really wants to make their platform best (they possibly dont want to, because of no competition?) then they would work on core issues first.

Simple google search can lead you to Bypassing FiveM’s ban system. Again, they can fix if they want to.

Open source projects, nvm.

4 Likes

its perfectly possible to secure events without encryption or weird event name obfu, you just need to put in the effort to write code that properly checks if whatever clients are asking of it is making sense, in the context, or if they even have permissions to do so.

it wont.

…flawed third-party resources?

4 Likes
2 Likes

See I understand shutting down people who make scripts in bad faith. But from what i read it seems you are more worried about them selling an anti cheat. And not selling it through your own thing called tebex. For 1 if cfx built in anti cheat was good server owners would not need to seek a third party anti cheat in the first place. Second you mentioned they selling it on their own store. Like why is that a problem this is just showing me that you guys are wanting to monopolize everything you can with fivem and rather dont actually care for the community rather just your money… I appreciate everything you guys do however your wording here worries me and makes me worry what you guys are really focusing on. Us or just your money

4 Likes

Just to be clear, I love what you guys did here with this update and I am of the opinion that no server developer should ever be able to access such low level information.
However, for all of the years I’ve been developing scripts in FiveM ( which I know being really difficult to develop, since it’s not file-integrated into GTA and since the cfx team cannot directly look at the gta source code ) I’ve always struggled to acquire essential information which is useful to achieve specific tasks. I think this is leading people to abusing natives: the lack of a basical API with which also server developers could be able to read some basical info about what’s going on in the client PC. For instance, I tried developing a script preventing players to use non-canon resolutions in order to avoid advantages in PvP but I could do nothing about it since GetAspectRatio and GetActiveScreenResolution return values that are game-set; this allows the player to bypass this by editing his Nvidia settings. So I was wondering if it would be possible to allow us to fetch some simple information ( hardware basic info, number of Citizen.CreateThread created coroutines globally active, monitoring the execution of natives f.e. OnNativeCalled("CreatePed",...) and generally having some more info about what’s going on; even in the other resources [this would also imply such an API to not be able to be used in escrowed scripts and a complete blocking of obfuscation sistems, allowing transparency in seeing what information is being transmitted]). This system would also increase the 3rd parties allowed anticheat development and simply allow us to put our efforts in helping ourselves and the community securing our servers. I am completely aware that a safe server is made by securing every section of it, taking care of details and doing checks etc… but this would be a great addition to the already available information ( GetInvokingResource is a good example).
Thank you for reading,
I hope to have explained myself in the most clear words, no offences or blaming are intended.

2 Likes

Again, I’m reiterating, for the so-manyth time by now, that this is not the case at all.

‘Money’ isn’t a relevant concern in this discussion whatsoever, other than the part where ‘making a server’ has a ‘hidden cost’ because somehow it has become normalized for people to sell questionable ‘anti-cheat resources’ where we aim to offer anti-cheat functionality for free, but instead have to deal with both cheat developers as well as ‘anticheat authors’ keeping info from us, since both would be negatively affected by us having a better ability to fix cheats, and anticheat sellers would similarly be negatively affected if cheats could be properly eliminated, so it’s in their best interest as well to not actually (help) fix the root of the issue.

I’m also really not sure how your takeaway from this post is that ‘the project maintainers are just greedy’. If that were the case, we’d just not work on the project at all and just ‘rake in money by doing nothing’ or whatever you folks are trying to accuse us of.

As to both this post, and the post below by @MrFreex, a lot of suggestions you folks are thinking of aren’t remotely as simple as they seem (see the part where anything client-reported can just be falsified by a cheating client! even stuff like ‘natives being called’, or ‘number of active coroutines’, etc.), and we prefer a level playing field, not one where there’s an ever-evolving cat-and-mouse game of hacky and at times nefarious ‘mitigations’ that are being spread through private channels and not as part of an open community discussion accessible to anyone, or at least anyone ‘confirmed’ to not be some ‘hostile agent’ (like aforementioned anticheat ‘working group’, for example).

The main thing with these kinds of requests is that, in addition to them needing work done by everyone to make use of them, is that they’d be the same for every client, and that them generally being silly means that these are likely to lead to wasted effort as cheats will just try to report ‘safe’ values for those fields - which is why we tend to focus on adding more means to have server-side protection.

Also, again, we do take the anti-abuse concern seriously. We’re continuing to ban more and more cheaters and breaking more cheats that we do have access to, and are always thinking of new means to solve other concerns.

You should expect a future post to provide some more details as to the exact intent here, but I’d like to close with one reminder: we aren’t somehow against the user base at all, and treating everything in this ecosystem like we are does not help anyone. We’re not out to randomly restrict you, we’re not out to even ‘milk you as a cash cow’, we’re just trying to do the right thing here. Assuming we are hostile is a sure-fire way to make a conversation constantly ‘on edge’, and it’d be preferred if people wouldn’t do so.

Here’s some historical posts for context, by the way. Some points may be out of date, but yeah:

9 Likes

This topic was automatically closed after 7 days. New replies are no longer allowed.