HttpService:GenerateGUID() generates a Globally Unique IDentifier. That means, you don’t need to check if it has existed before.
local function CreateID()
return HttpService:GenerateGUID(false)
end
1 Like
This goes against spoofing it,
The script and remote it’s self it vulnerable this is supposed to also use a handshake,
I should of included the full framework for some script kiddies in here, my fault.
This is true Thanks for pointing this out!
There is a 1 billion chance of collisions though, you never know 
The original reason for this is I was using math. random(1000,9999) as an ID system.
As mentioned even inside the original post there should be some handshake for the remote and localscript.
This isn’t the topic for you,
If you can’t understand how a client can’t be secured then you probably should check what topic you posting on first.
no offense but reading your post made me lose brain cells
9 Likes
Is this not just the equivalent of a normal sanity check except worse?
1 Like
I also lost braincells reading your post and writing my post
Due to the fact that the arguments loop-back is evaluated on the client, the OnClientEvent connection can be disconnected with ease and it’s immediately ineffective.
But it can STILL be bypassed entirely without disabling connections. The client can jump into the client script’s environment and modify the arguments stored in LocalArgumentCopys.
You could also just intercept the returning traffic and swap around the arguments again, but the above is easier.
This isn’t even security through obscurity. It’s just a useless “measure” that does nothing but vastly increase the bandwidth used by the game. An unnecessary GUID on top of putting all arguments into a table will rack up network usage very quickly if it’s for every event in the game (which could be fired nearly every frame per player).
All of your community resources are either shoddy, unauthorised, uncredited reuploads of other people’s work (occasionally with minor edits, usually impacting performance, security, UX or all of the above) or code filled to the brim with bad practices that are harmful to a game which you advertise as “#1 in Security” or similar like it’s the end-all of a developer’s problems.
As I’ve said previously, contributing to the community is a good thing. But, with that said, posting things like this with untrue information about best practices for game development can lead people on the wrong track and actually end up doing more harm than good. Double checking that what you’re doing is correct is incredibly easy, as other people in the replies have shown with posts that render this “method” ineffective. It’s worth it to ensure you’re providing the best possible information you can.
Mistakes happen, and we learn from them. But with your current track record, these are no mistakes. You’re purposefully creating these types of posts for some reason or another, at whatever cost to other developers. You’ve ruined your reputation among this community. That’s not to say it’s completely irreparable, but it’s gonna be a long journey. Please post some better resources in the future.
9 Likes
blud is sanity checking on the client
4 Likes
You can’t exactly verify arguments on the server from only the server.
1 Like
What on earth did I just read?
Everyone here probably lost a couple of brain-cells from just looking at it.
3 Likes
Likewise you can’t trust and verify the arguments from the client
Use particles to kick dont use the real kick on the client!
Completely false,
Likewise NILLED LocalScript placed within ReplicatedFirst might be jankey but can’t be removed/disabled.
Yet again only a example and should be expanded off of, clearly stated already.
You do know that getreg exists right?
Which, if I can remember correctly, returns an array or a dictionary of all stored Lua (or LuaU) values (if I’m more certain of that they’re tables that are yet to be gc’ed).
So, by simply doing this:
local argumentCopies = nil
local haltFutureSendingPackets = true
local _activelyFindingArgumentCopyTable = false
local event; event = S2C_C2S_Packet.OnClientEvent:Connect(function(...) -- i could say that hookmetamethod might be more friendlier here
if _activelyFindingArgumentCopyTable then return end
_activelyFindingArgumentCopyTable = true
local arguments = {...}
--assume getreg returns an array
for _, storedTable in ipairs(getreg()) do
if storedTable[arguments[1]] ~= nil then
argumentCopies = storedTable
event:Disconnect()
break
end
end
_activelyFindingArgumentCopyTable = false -- restart the process for the next event if we failed to find the copy table, this is ignored once we found the table
end)
-- think of this part as the section of code where the exploiter wants to send out spoofed data
-- mainSploit.lua
getgenv().savedRemotes = {}
getgenv().FireRemote = function(remoteName, packetName, ...)
if haltFutureSendingPackets then
-- do something, for example save the packets that are yet to be sent then fire it once the LocalArgumentsCopy table is found
warn("Cannot send spoofed data as a heavy risk is present!")
end
local remote = savedRemotes[remoteName]
if not remote then
remote = ReplicatedStorage:FindFirstChild(remoteName, true)
savedRemotes[remoteName] = remote
end
local args = {...}
local id = HttpService:GenerateGUID(false) -- GenerateGUID RARELY (in a very incredible sense) makes an identical identifier plus you're literally just going to unindex it anyways.
local packet = { [1] = id, [2] = packetName, [3] = if #args > 1 then args else args[1] }
argumentCopies[id] = packet
remote:FireServer(packet)
end
I’m not sure if this will really work (I can’t test it myself since Hyperion will soon be (or it is) everywhere now. I have some experience within exploiting just to find a workaround to slow down the process of manipulating sent data to the server whilst not going overboard with security through obscurity, hypocritical? Yes, maybe, but atleast it does its job of preventing skids of just using Remote:FireServer() and hookmetamethod(game, "__namecall", function(self, ...))
Give any experienced and seasoned exploiter in Roblox roughly a week and they’ll eventually discover a loophole (well, I already found it hehe~) with your anti-spoofing method and exploit said vulnerability.
getreg() cannot be countered or stopped once someone with enough knowledge in general exploiting and C as a whole touched any games with this method—since, again getreg() stores Lua values.
1 Like
I really still don’t understand why people keep trying to prevent people from firing remotes from the client, like why not just do it from the server, what could possibly need you to only verify something from the client.
If this is because of latency problems there are good tutorials like the one suphi made that teach you how to make a client and server synced clock that you can implement so latency doesn’t screws your gameplay up.
2 Likes
Network Optimization: am I a joke to you? 
2 Likes
Probally not the best for network optimization, but we must remind our self’s of games like ERLC and Pls Donate they use these same practices on the client.