Cheaters keep using DevTools in order to make their lives easier. sv_enableDevtools 0 convar.

[d22tny]

What happened?

95% of cheaters use DevTools in order to cheat on a server ( in order to reverse engineer code to understand the workflow of events )

So, why does a client in a production server need DevTools? They don't.

For example, at this moment if i have all my code encrypted using escrow and i have a client code saying :

TriggerServerEvent("givemoney", 10000), the cheater can see via netEventLog that the givemoney with the parameter 10000 was sent from client to server, so, he can use then a lua executor to trigger the same event.

Can you please make a server convar sv_enableDevtools so that we can put that on 0 and maybe enable it only when we have to test something? Also note that this convar should stop all the functioning, at least for the netEventLog devTool, because some cheats are accesing directly the data.

Expected result

convar to be able to stop devtools functionality

Reproduction steps

Importancy

Slight inconvenience

Area(s)

FiveM

Specific version(s)

any build

Additional information

No response

[matehun00]

You should never trust what the client says, secure your events. And if you are so scared about DevTools, there are ways to detect it being used

[ook3D]

its a good practice to do that, but it shouldnt rely on it, you should in my opinion be able to disable all development features as suggested.

[AvarianKnight]

If people are using cheats "blocking" this from being used won't fix anything, they can just bypass it. If you want protect your server, the best way is to validate anything that comes from the client.

[yannbcf]

As previously stated you are looking in the wrong direction, your events should be validated server side.

Furthermore you could:

• change the event names to an enum representing randomized numbers, making it atleast a bit harder to understand what is going (which would also have the benefit to reduce the bandwidth)
• add rotating dummy values to your events allowing you to detect tampered events

Going from

TriggerClientEvent("givemoney", 10000)

To

-- client
TriggerServerEvent("32", 762, -32, 99)

-- server
if args[1] ~= 762 then .. -- 762 should be a rotating value for each event received
if args[2] ~= -32 then .. -- -32 should be a rotating value for each event received
local amount = args[3] + 9901 -- 10000, the offset could be rotated too

Obviously in that case you would never want to pass a monetary value directly to the server, you would prefer to pass a task id for what you performed, the server would verify that you indeed did it, and the server would add the serverside defined amount of money to the player.

I just showed some ways to obfuscate events which would make it really hard for someone to inject code to trigger the events themselves, if they just spoof the event and call it as is, it should be detected as the dummy values should be rotating

[d22tny]

It's all about coding in a much safer enviroment, coding for fun, not having to think every bit of code 10% for functionality and 90% for security. Obfuscating code is not a viable solution, you write the code and if you go back at it after a month or two you have no idea what is what. And as i've said, @AvarianKnight it should be a convar disabling the entire devtools from working, i'm not aware of any bypass for changing a server convar.

@ook3D how can i detect netEventLog or its data being used ? have a snippet or something ?

[thelindat]

cheaters use DevTools … in order to reverse engineer code

What lmao?

i have a client code saying :

TriggerServerEvent("givemoney", 10000)

So don't be lazy and write terrible code.

at least for the netEventLog devTool, because some cheats are accesing directly the data

Wait until you find out they could access that data in completely different ways or bypass your dumb convar because client side security is not secure.

It's all about … not having to think every bit of code 10% for functionality and 90% for security

Sounds like you need to stop coding.

This post is literally the biggest skill issue I've seen.

[d22tny]

Man, you literally have no idea what you're talking about. This attitude is not necessary at all. I didn't share how i write code. They have 2 ways of accesing that data and they are both stoppable.

[ChatDisabled]

You got a handful of the top class developers commenting on this issue and you dare say you literally have no idea what you're talking about 💀

[d22tny]

I wasn't speaking to the handful of the top class developers, i was speaking to this guy @thelindat

[DemmyDemon]

Man, you literally have no idea what you're talking about.

Right, but you trusting the client because you think it might possibly be respecting a convar, that's great security?
Please, it's an annoyance for people at best. Convars are not magic, they're just text strings sent to the client. The client isn't bound by the ancient magic of Baal to respect it, it can just discard it.

This does nothing.

[d22tny]

Yup right, i'm a little bit tired, a server command, anything without client access. There are multiple ways of ensuring cheaters can't use cheats.

[AdrianIsBored]

There are multiple ways of ensuring cheaters can't use cheats.

Correct! Disabling devtools isn't one of them, not being able to identify what events are triggered is just a little inconvenience, there is millions of other ways that cheats can see what events are triggered and what not. You can try more effective measures after you secure your "givemoney" events.

[draobrehtom]

I believe that hiding devtools and eventlog might partially help in reducing cheaters, as it will make it harder for ordinal cheat users to use current cheats. However, in future new cheats will eventually emerge and ordinal cheat users will be back on track.

[DemmyDemon]

Yes, it'll take them 5 minutes to circumvent, this causing it to only be an inconvenience for legitimate users.

The solution is to not have blatantly exploitable events.

[draobrehtom]

The solution is to not have blatantly exploitable events.

100%, but in the reality we have a LOT of blatantly exploitable events in scripts and some of them even exists in resources officially provided by txAdmin in recipes, by CFX. Is is not an issue why those scripts/frameworks are not validated before approving them?

1. QB: [BUG] Shop Exploit qbcore-framework/qb-inventory#461
2. VORP: https://github.com/VORPCORE/vorp_weaponsv2/blob/6a8471a4e8f0d3f508f9699168ed490fc723e171/server/server.lua#L211

[Shinzuh]

If this is a real problem you can implement a method on your server to check if the user is using the devTool.

[racistnoob]

DevTools on its own isn't an issue; the real problem lies in resources that have NUI callbacks which are vulnerable and can be exploited to trigger events without having to use a "lua executor cheat"

Here's an example from qb-phone

RegisterNUICallback('AcceptMailButton', function(data, cb)
    if data.buttonEvent ~= nil or data.buttonData ~= nil then
        TriggerEvent(data.buttonEvent, data.buttonData)
    end
    TriggerServerEvent('qb-phone:server:ClearButtonData', data.mailId)
    cb('ok')
end)

[AdrianIsBored]

the real problem lies in resources that have NUI callbacks which are vulnerable

Cheat or not, vulnerabilities are vulnerabilities, and they will be exploited at some point by an actual malicious actor. Putting a bandage on it only makes it more likely that when someone capable is doing some sketchy stuff then it will cause more fuckery since you weren't able to catch them early.

If NUI is the main attack vector for your cheaters, then I must only imagine what other vulnerabilities exist outside of that scope.

[coblyox]

DevTools on its own isn't an issue; the real problem lies in resources that have NUI callbacks which are vulnerable and can be exploited to trigger events without having to use a "lua executor cheat"

And once again, it's laziness or simple incompetence of a developer who wrote it. IMHO, if people don't know what the f they're doing, they should hire a professional or don't touch this thing at all. Because blocking devtools or eventlog won't fix anything as said in this issue before. One way or another, they will get that data and use it against you if it's not secured.

In general, NUI Devtools are pretty much same shit as you doing Right Click -> Inspect in any website, no one sees an issue there, but sees them here.

[AvarianKnight]

This is also not to mention that the client has the source code for anything on the client anyways, they can already see what everything does.

They already intercept C->S traffic, they already check what data is being sent via events, this is why people preach put as little on the client that you can, and if you have to take anything from the client make sure to verify it.

And as i've said, @AvarianKnight it should be a convar disabling the entire devtools from working, i'm not aware of any bypass for changing a server convar.

That isn't how the world works, you can't just magically disable it and the cheaters can't use it, the cheater can do whatever it wants regardless of what you do.

It's all about coding in a much safer enviroment, coding for fun, not having to think every bit of code 10% for functionality and 90% for security.

I'm sorry to say but if you're interacting with client -> server events then this is something you need to think about you can't just wish this away with a "safer environment", you need to think about this stuff when you're interacting with data from the client.

[d22tny]

I see that this escalated, i meant no harm at all and maybe one day i'll do some forum topic teaching you guys some security. Have a nice day.

[DemmyDemon]

maybe one day i'll do some forum topic teaching you guys some security.

Thank you, looking forward to it.