I want to simulate an exploit to some extent, however I just found out I can’t use loadstring() from a local script to do it, is there another way?
1 Like
That is Player:LoadString, which is from data persistence, loadstring is a built-in global that executes code in a string.
I second the use of the in-studio command bar. It’s simple to access and does pretty much anything a malicious user could do, unless they have access to the server side of your game through a backdoor of some sort.
You’re right, that was my bad confusing loadstring() and LoadString().
@Ayloix If you were meaning loadstring(), I suggest you remove the solution mark on my answer.
This topic and this post still might help you.
1 Like
You can use the plugin InCommand to do client sided exploits(there’s where the exploits are located), although it does cost robux.
1 Like
Yeah that’s what I use, the command bar disappeared for me for some reason
1 Like
Use information gathered from your remotes and modules and try to fire them like an exploiter would. Heres a very basic listener I made just to visualise things from a exploiters perspective a bit more.
Your goal is to use your event based on whats going through them. (From a local script of course)
I think it’s worth mentioning that even if you create a custom Lua VM to run code on your client to attempt to mimic the behaviour of a script execution exploit, you will not have access to all the functionality of such an exploit.
Script execution exploits have access to higher script contexts (thus access to by default Roblox restricted properties, functions, etc), access to in-depth debug libraries to access Lua constants, upvalues, etc. So, even if you do implement a method to run code on your client - for what I assume is testing your anti-exploit systems - this wouldn’t be a fully reliable way to security test your game.
You’re best just following standard security advice from many developers on this forum - so making sure that you verify data sent to your RemoteEvents, making sure you don’t trust the client, etc. There’s many resources for this already.
4 Likes
Its not a matter of testing security I just wanted to see if it was possible
If that’s all you’re wondering, then the answer is not really. As I mentioned within my reply, you wouldn’t have access to nearly as much features as a regular script execution exploit.
The thing that makes an exploit powerful is its features, not just the fact you can run code on your client. Sure, that’s part of it, but to effectively use such an exploit, you’re going to want to use the features the exploit provides - that you wouldn’t have access to by default.
3 Likes