Yeah I know, I’m taking the risk either ways. That aside, is an exploiter actually able to change the LocalScript.Source of a LocalScript?
LocalScript.Source doesn’t exist on the client
So theoretically it is not possible to stop the Lua Code from running with exploits, other than deleting or disabling the LocalScript, is it?
No
Every post about anti cheats always evasize the fact that the player is in complete control of the client. Maybe you can catch a few skids who don’t know what they’re doing but unless you’re really experienced with exploits. Client-sided anti cheats are useless
2 Likes
They can hook functions to something out or disconnect something, say like Player.PlayerAdded (only can disconnect client only)
So basically they can turn off any events, such as Instance.DescendantAdded or Instance.DescendantRemoved?
Yes
The client is literally on the player’s pc, they can change anything about the game on their screens
1 Like
I’m pretty sure that relies on client memory spikes if I’m pretty sure.
Its the only known client sided method that is actively used but it produces a lot of false positives and doesn’t work 100%
1 Like
Is there any possible way to access Instances which’s parent are set to nil from Studio LocalScrips?
You’re on about injection detection which is possible using checks for client memory spikes like @legs_v said but I’m on about the fact that exploiters can halt the script’s execution entirely without disabling or deleting it.
No.
Parts sent to nil are to be garbage collected, if roblox allowed a method to collect nil instances it would cause a lot of memory leaks with people who don’t know what they’re doing.
There is a lot especially on low end devices that don’t handle memory well
1 Like
Do >
local Backup = script:Clone()
local MyParent = script.Parent
game:WaitForChild("RunService").RenderStepped:Connect(function()
if script.Disabled then
script.Disabled = false
end
if script == nil then
Backup.Parent = MyParent
end
end)
These don’t even work inside Studio, so I doubt it’ll do anything in an actual game where an exploiter can just pause a localscript’s execution without setting .Disabled if they really wanted to.
1 Like
Wrong d_hq
It says right in the Lua Manual, that anything deleted, or Parent set to nil, can be resurrected by re-referencing it.
If you knew the original Parent of that Script you could bring it back.
Maybe even, if you gave it any Parent… I have no idea…
This deletes a bunch of models in Parts, in a table:
game.Players.LocalPlayer:WaitForChild(“ClearCache”).OnClientEvent:connect(function(Tab)
print ("-- Obj:Destroy()")
local obj = nil
for i = 1, #Tab do
table.insert(CamList,Tab[i].Name)
table.insert(CFrameList, Tab[i].CFrame)
table.insert(RotList,Tab[i].RotVelocity)
– Tab[i].Parent = nil
obj = Tab[i]
obj.Parent = nil
end
end)
This brings a table full of them back to life, and deletes some more:
game.Players.LocalPlayer:WaitForChild(“ClearTile”).OnClientEvent:connect(function(Obj, NegObj) – object is a list
for i = 1, #Obj do
local cloud = container[Obj[i].Name]
cloud.Decal.Transparency = 1
cloud.Transparency = 1
cloud.OldInfo:ClearAllChildren()
– cloud.OldInfo:Destroy()
–Obj[i].Parent = nil
if cloud:FindFirstChild("Mesh") then cloud.Transparency = 1
cloud.Mesh:Destroy() end
Obj[i].Parent = workspace.globe
end
wait(.5)
for i = 1, #NegObj do
–
NegObj[i]:clone().Parent = container[NegObj[i].Name].OldInfo
greyOut(container[NegObj[i].Name].OldInfo[NegObj[i].Name])
– Instance.new(“Model”, container[NegObj[i].Name].OldInfo)
– NegObj[i].Parent = container[NegObj[i].Name].OldInfo.Model
NegObj[i].Parent = nil
end
end)
It makes for a very elegant FOW but unfortunately it is exploitable, as the deletes, can simply be deleted…
I wish that it weren’t so, because I want what I want, so I’m gonna figure-out some sanity checks, I can do, without letting on that I know…
If you got any elegant ideas; lay 'em on me…
No, client sided anti cheats aren’t useless. You shouldn’t rely on them but they aren’t useless.
Currently, Roblox locks the parent property when calling Destroy, so you can’t exactly resurrect deleted instances in Luau, unless you pull them out of the garbage collector to prevent them from being completely deleted, which isn’t possible without exploits AFAIK.
Exploiters can do whatever they want on their computer, you got no control over it. You just need to make sure the packets sent to the server are not manupulated.
There’s no way of getting the location of the injected script. They’re all stored in the lua stack/memory, both of which you can’t access at all from a Lua script.
Although if you really want to detect injected scripts you can look at the output of some skidded scripts and detect them via LogService.
Well, is this, Lock, a recent development, because, I’m sure I read that statement years ago…
Then it stopped working…
Now it’s working again, but I may have actually changed the code to get it to work again…
And now that I look at the code: It seems like I am really just passing the values from the server to the client, and the original concept of reviving the old Tile, which I deleted, by Name only is gone…
So, ,actually, it is at least a little less hackable now, if I can just keep all the data Server side until needed on the client…
But that means I’m pushing lot of data around now, and I did want this to be somewhat of an RTS; so FAST…!
Obviously, I don’t really know what I am doing but that’s my life basically so I’m used to it…
And it WAS fun to read the Lua Reference Manual again…
so thanks Phoenixwhitefire
Don’t know if these are new, but I am loving that I found them… Def. not mentioned on Roblox…
-
&: bitwise AND -
|: bitwise OR -
~: bitwise exclusive OR -
>>: right shift -
<<: left shift -
~: unary bitwise NOT
AND, I’m scripting for this artist’s game, and he’s GREAT!