UI Interaction Anti-Exploit

Help and Feedback Scripting Support
, , , ,
#1

Hey.

Let’s say you have added a menu with a button that, when clicked, will trigger a remote event to the server where you purchase an item.

It would be pretty easy to exploit so you’d probably add checks like:
Does the player have enough money?
or maybe
Does the player have the menu UI opened?
which are both easily done on the server side of things.

Though even then (although not exactly game-breaking), an exploiter could open the menu and then execute a script to fire the remote event. Meaning they haven’t actually clicked the button.

The point is, what would you do to check if the the button has actually been pressed to purchase the item therefore crushing any attempt at " forcing " the buy sequence?

#2

Well, it’s not possible to prevent exploiters from firing remote events which is why honeypots work. The best you can do is to secure the remote events because guis are very vulnerable to being exploited due to being on the local side.

#3

I don’t think you can check this from the serverside.

I suggest sticking to sanity checks like:

#4

You could theoretically do this on the server side using player.PlayerGui.ScreenGui.Frame, but that can be kinda clunky and would be better to just check if they have enough cash. Like you said, a “sanity check”.

#5

I’m not sure if they’re much more secure, but a RemoteFunction would be better than a RemoteEvent (if you aren’t already using a RemoteFunction for the buy sequence.)

I’m not big in anti-exploit, so I can’t confirm if it’s more secure or not. I’m fairly sure it isn’t, but it is still better to do so for checking stuff and returning something to the client (i.e. if the purchase was successful to set the text of something to “purchase successful”).

#6

A better idea is to limit the conditions server-side in which a player can purchase an item:

  • Has an item been purchased in the last X minutes by the player?
  • Does the player have enough money?
  • Does the player already have the item?
#7

This isn’t more secure.

Events allow for communication between parties.

RemoteEvents allow for:

  • Client(s) → Server
  • Server → Client(s)

RemoteFunctions allow for:

  • Client → Server → Client(s)
  • Server → Client(s) → Server
#8

I thought so. I don’t really do anything with anti-cheat. Just make code that’s most efficient and don’t care if people exploit in my games. Not like anyone plays them anyways :woman_shrugging:

Thanks! :grin:

1 Like
#9

Yep. That’s actually true you can’t check updating UI stuff from server.

Either way the issue still lies in that executing a script can be the same as clicking the button, which was my question in the first place.

#10

In terms of stopping cheating this works as expected but my question’s still up.
You can still execute the script instead of clicking the button and it would have the same effect.

#11

why would that be a problem though? (unless the UI is supposed to unlockable? if so, just add a seperate boolean for that)

#12

You’re essentially discussing a client-side anti-cheat, which shouldn’t be your primary method of event protection.

However:

local GUI = foo

local RS = game:GetService("ReplicatedStorage")
local event = foo

local function main()
    if GUI.Visible then
        event:FireServer(bar)
    else
        return
end

foo.Activated:Connect(main)

… is how I’d approach a client-side check.

#13

In that case the exploiter can probably just do “event:FireServer(bar)”.

#14

So, umm, what actual exploit are you trying to prevent?

#15

The exploiter can fire the event either way, because they are not restricted by client-side anticheats.

LocalScripts, like the one I wrote, are property of a client, and are therefore subject to deletion by the client.

As I mentioned earlier, it’s better to check everything on the server.

#16

It’s impossible to stop exploiters from firing remote events. But at least it can be possible to detect when it’s fired and to set up conditions to secure the remote event.

#17

Yeah that’s what I’m trying to figure out, checking for button press as a check on the server which I doubt is possible but what do I know.

#18

Yes, I am aware of everything check related to stop exploiters from actually having an in-game advantage, but what I’m trying to achieve is having one of the server’s checks being the input received itself.

#19

Well, you can send information over through remote events and have it checked on the serverside.
Example, Remoteevent:FireServer(player, info)

#20

The issue with that is the exploiter also being able to fake that.