Well, I did some research, but apparently, as long the local script is on the actor (both “hidden”), exploiters aren’t going to be able to find the info or get the info of the script, unless they use synapse (Which like I said earlier, byfron pretty much killed paid exploits atm), “because actors run under entirely different global states”, so I’m assuming It’s the best way to secure a local script atm, even if they aren’t foolproof.
If an exploiter tries to “ignore” the handshake, such as by blocking the RemoteEvent, the server will kick them.
Handshakes work like this:
The server sets a tick value. The client fires a RemoteEvent with a randomly generated encrypted key. The server checks the key and resets the tick value.
Then, in a loop, the server checks if the tick value exceeds a certain time limit, such as 30 seconds, and will kick them.
Key should be randomly generated and encrypted, a new key each time a RemoteEvent gets fired.
1 Like
But even if you hide a local script parented on nil or destroyed (since Instance:Destroy() don’t really “destroy” just disable connexions and parent to nil), the client, with the correct programs will continue been able to delete the parented with nil scripts or edit them. No? I mean, he can also disable some parts of the script to make that the important things (that ones who fire the server) continues working.
Is that true or im bad informated?
This also completely removes it from its environment. The script will not be able to be seen in:
- getscripts()
- getnilinstances()
- saveinstance()
- Dex Explorer
And the script will continue to run completely fine.
1 Like
Yes but the program wich uses the client to hack, can use more than this methods, (can create or modify as much methods as want). So the script can be harder to find but not imposible, no?
They could hook getfenv() upon auto execution and stop the script from hiding itself, however, most environments hooks I’ve seen simply do not return the script so you could check if script.Parent errors which would detect it. its definitely possible for them to hook the environment hide and stop it from hiding itself however it can be prevented.
1 Like
Ok, thanks for the aclaration. Anyways I would prefer don’t using the client as manager of some things.
What if we just use the method he already mentioned at the very start of the conversation?
I’ve contacted 3 of my exploiting friends, just to test if the script is able to detect them injecting, and they all got caught red-handed.
Maybe we shouldn’t focus on hiding local scripts for exploiters to never get, but maybe using server scripts to check on the client’s behavior.
3 Likes
I am sorry, but how would you check for client exploits on the server?
1 Like
My friends told me that when they inject they lag for a split second so it can get access to everything client-sided in the game, which spikes the Client Memory Usage.
If it spikes, then we can check for that to then kick the player.
Even though this is in a local script, it kicks the player prior to attempting to inject, so nothing would get deleted.
Using memory checks is indeed effective however it can cause many false positives (also known as false detections) in big maps or laggy players
You don’t need to make the detection very strict. My friends said they usually get 300-700MB+, then back to normal.
If someone is still reading this, you can use this for simple detection methods, while being fully protected againts hookmetamethod or hookfunctions attacks, not even auto execute can destroy/Disable the local script, Exploiters can’t also find the actor with auto execute and loop in ReplicatedFirst.
The only bad thing is that you are not going to be able to detect hookmetamethods or hookfunctions, keep in mind destroying things still affects the local script, but yeah, this is useful if you want to make simple anti cheats while not having to worry about spoofs.
That means that player:Kick() on the client will still work even if they “hook” it.
I recommend making a server sided script inside ServerScriptService, that changes the name of the local script and actor.
local ReplicatedFirst = game:GetService("ReplicatedFirst")
local Actor = ReplicatedFirst:WaitForChild("ACTORNAMEHERE")
local LocalScript = Actor:FindFirstChild("LOCALSCRIPTNAMEHERE")
Actor.Name = ""
LocalScript.Name = ""
-- DONE :D
EDIT: Also forgot to mention but actors are immune to getconnections().
1 Like
Apparently someone already bypassed byfron, with the exact same program, I don’t why this “Tool” isn’t in the blacklist, but yeah, they apparently bypassed it using the new version, my theory is, I think byfron is different in every client so that’s why there’s not an actual bypass, but that’s just a theory.
Hopefully, bitdancer decides to do something about this. 
2 Likes
Do you really think they’d do a bypass for each version? This is pointless and will be discovered and bypassed either way.
byfron is the same thing in every client (an anti-tamper located in the .krampus section of roblox)
not that hard to fake a bypass, use uwp and execute all the scripts, photoshop the uwp titlebar out and replace it with the x64 one, take a picture of process hacker and add it to a new layer. (the only people i believe who got past byfron are the script-ware devs, as they are competent)
2 Likes
Don’t forget about Client Prediction where you run the same code as the server did while keeping the it’s authority
Honestly, brother, I’ve seen lots of bad posts and replies on the devforum but nothing tops this one
Tell me how would you check if an exploiter ran a simple script (example: “Hello world!”)
And if everyone SHOULD use the server and not the client, why are there bounties for example Synapse X having bounties for Client Detections that goes up to 1K+$??
And why would ER:LC, a popular roblox game, have an OBFUSCATED Client Anti Cheat?
Forgot that image editors are a thing , but I guess you’re right, they can use the UWP, and fake everything I thought it was real because It had the new version of robloxplayer, also the scriptware one is suspicious as well, they screenshotted that like 3 months ago, but they are still not back, so It might be fake?, who knows.
Bit’s personal game engine is written in Rust (His favorite language too.), so if he possibly gets his hands on an executor he may reverse engineer if willingly.
1 Like