Cheat Engine Executor Prevention

Hello, there has recently been a cheat engine executor out, here is a prevention from it injecting. please put it in a localscript in replicatedfirst game:GetService("Players").Name = game:GetService("HttpService"):GenerateGUID();
You could also just destroy their gui seeing as they parent it to playergui but still

(NOTE: YOU CAN ALSO RENAME THE SERVICE PLAYERS ON SERVER IIRC)
test game for another version, uncopylocked that i made: Detection-Test A-1 - Roblox
a friend tested it and worked

18 Likes

NOTE: i havent tested this but i looked at the code of their injection game

2 Likes

I thought the Name property of Player instances was locked.

4 Likes

they use game.Players instead of game:GetService(“Players”)

1 Like

name property of player instances are locked, you can rename services just fine, you can rename the service on server actually though

Oh, I didn’t see what instance has the name changed. And the error they would get is very simple to fix. This literally doesn’t do anything

this can get patched very easily, nice try tho

1 Like

to be fair theres another way to detect it

Cursing directed at someone is against the rules, using curses to intensify your sentences are allowed by what i know

2 Likes

I am sure its not. But whatever like I care, just making a point.

I doubt skids would patch it, It’s a level 2 anyway, literally 0 core Gui access, and No custom functions, and It only work with tools that have local scripts :skull:

Not to mention that there are alot of way to detect this cheat engine thing

Well, nice try but exploiter can easily do

for _,v in game:GetChildren() do 
    if v:IsA("Players") then 
        v.Name = "Players" 
    end 
end

OR

game:GetService("Players").Name = "Players"

And changing a service name does not consider as “executor detection”

5 Likes

Then, they would have to change the code of their init cheat engine, which most aren’t willing to do, specially when It crahes like 60% of the time or smth, this “executor” is pretty much a joke, and can easily get patched by not adding tools into the game or by making a custom backpack

1 Like

There’s no point in even trying to find a detection for the Cheat Engine thing, it’s literally a level 2 executor unlike if you look at other executors which levels are 7-8.
It basically can barely do anything, barely anything game breaking.

2 Likes

Here is my take on it. I think it works but someone should try!

local player = game.Players.LocalPlayer

local function checkForInjection()
  for i, v in pairs(getfenv()) do
    if type(v) == "function" and string.find(debug.getinfo(v).source, "rbxasset") == nil then
      player:Kick("Possible script injection found!")
      return
    end
  end
end

game:GetService("RunService").Stepped:Connect(function()
  checkForInjection()
end)
1 Like

Also some people have beeing hanving issues with debug.getinfo(v) because it isn’t used in the default lua library:

This function differs from debug.traceback() in that it guarantees the format of the data it returns. This is useful not only for general logging and filtering purposes, but also for sending the data to systems expecting structured input, such as crash aggregation.

This function is similar to debug.getinfo, an unavailable part of the standard Lua library which serves a similar purpose.

So if you want, you can change debug.getinfo(v) to debug.traceback(v). When I tried this out a few months ago, debug.getinfo(v) worked but it will probably not work now.

hookfunction() and getconnections() can easily bypass this.

Cheat engine executor is local script level, so what are you talking about, It doesn’t have any custom functions, also pretty sure the code wouldn’t work anyway

they use game.Players (instead of game:GetService(“Players”))

Alright, let’s break this down, my guy.
Cheat Engine already does not work with Hyperion. You simply cannot do anything with it.
It’s not an executor, nor a working exploit software with Roblox.

The methods I have provided are common methods that are being used in exploiting to easily bypass these foolish preventions. The OP clearly does not know anything on what they’re talking about. Exploiters have full control over their clients, everyone should develop according to that.

4 Likes