GeneratorPlus - Protect your string & event parameters

Resources Community Resources
#1

Hello! I wanted to share my new resource GeneratorPlus :smiley:

It protects your STRINGS and EVENT PARAMETERS but you need to use it CORRECTLY

Here is example script:

local generatorplus = require(script.Parent.GeneratorPlus)
generatorplus.SetSeed("testseed123123123123123") -- Provide a seed before using this module

local mystring = "OMG! Is that GeneratorPlus??"

local compiledstring = generatorplus.Compile(mystring)
print(compiledstring) -- Compiled String (UNREADABLE, PROTECTED)
-- PRINTED: !FM3B6#GJ8J5M2J8B*C@Z3B*J8B6N4T8N4Z!Z3B*D1Z!@KX2A7M2Z8Z8

local decompiledstring = generatorplus.Decompile(compiledstring)
print(decompiledstring) -- Decompiled String (READABLE)
-- PRINTED: OMG! Is that GeneratorPlus??

local compiledparams = generatorplus.CompileParams("best,protected,parameters")
print(compiledparams) -- Compiled Params (UNREADABLE, PROTECTED PARAMETERS)
-- PRINTED: S9Z3Z!Z3%QL@G@S9Z3Z!Z3%QI4G@S9Z3Z!Z3%QF@

local decompiledparams = generatorplus.DecompileParams(compiledparams)
print(decompiledparams) -- Compiled Params (READABLE)
-- PRINTED: {[1] = "best", [2] = "protected",[3] = "parameters" }

I know, I am bad at writing resources but i guess it would be useful for someone :slight_smile:

Nevermind here is comments from module, i write them into module too

--[[
		Made by MonoClassic
	Please use this script in BackEnd because it could be malicious in ClientSide
	So do not make accessible this module for Clients. (THEY CANNOT READ COMPILED STRING BECAUSE OF SEEDS)
	(Put it to ServerScriptService)
	

	module.SetSeed(STRING) -- Provides a seed for you

    module.Compile(STRING) -- Compiles a string for you
    
    module.Decompile(COMPILEDSTRING) -- Decompiles string for you
    
	You can use this script if you want to add protection to something like
	RemoteEvents! (No longer parameter edited remotevents :3)


	(edit: i added functions for that)
	
	module.CompileParams("param1,param2,param3") -- EXAMPLE
	
	module.DecompileParams(COMPILEDPARAMSSTRING) -- EXAMPLE
	* it will print: {"param1","param2","param3"}
]]

HERE IS LINK OF MODULE: GeneratorPlus

I am not perfect on everything like writing resource or making resource so i need people’s feedback.

1 Like
#2

This is interesting but I’m not really sure if it would be useful. Also, I’m just wondering, what are the CompileParams and DecompileParams functions for?

1 Like
#3

Hmm… It’s an interesting concept, but I think it needs work to be useful. To me it seems like you’re encrypting strings on the server with the presumption that they’d be sent to the client, where the string would be useless because it’s encrypted, to then be sent back to the server and decrypted. This means that:

  1. Encrypted strings that the client needs to use will be rendered useless since the generatorplus module is stored on the server, meaning that to be useful, they can’t be encrypted
  2. Strings that the client DOESN’T need to use can just be kept on the server and not sent to the client, in which case they wouldn’t need to be encrypted.

This means that as it stands right now, there are not really any use cases for this.

NOW — if you could make it such that the encrypt function was available on the client, both the encrypt and decrypt functions were available on the server, and the decrypted message wasn’t easily discernible given the encrypted string, then this concept could make a WONDERFUL guard against remotespy (although if exploiters can cause TOO much damage using remotespy there’s usually a deeper issue — wouldn’t hurt to have this tool though).

2 Likes
#4

Exploiters can edit parameters and send them to server by remoteevents but with compiledparams it cant be edited and its not readable.

#6

So is this an encryption module?

1 Like
#7

What’s stopping the exploiter from just… extracting the seed the client & server are using and compiling a new set of params with that seed?

#8

They cannot extract seed because you must use this module in SERVER and you must put it to SERVERSCRIPTSERVICE.

If you want to make something with parameters you can compile PARAMETERS and send it to client but CLIENT cannot understand what STRING says, so thats the point we cant decompile strings in CLIENT because if we let they decompile STRING in client they can do same thing with EXPLOIT so we cannot let them use this module in client (they can reach to seed and they can decompile whole compiled ALPHABET table by compiling string like “ABCDEF…abcdef…” bang they got whole compiled ALPHABET table so they can understand what compiled string says.

If you use this module exploiters cannot understand what it says and you can use this strings in communication between server and server can understand what you mean by that compiled string because server can decompile it.

IF YOU WANT TO USE THIS MODULE IN CLIENT you must edit that module and make it able to change SEED in every use and change symbols to something exploiters cannot copy in debug like weird symbols

sorry for grammer

#9

Then how exactly is this useful at all? If you have data the client doesn’t need to know about it should be remaining on the server and never pass to/from a client.

#10

You can think it like COOKIES in web development. People cannot read it they just unreadable string but when you try to send it to server it can do what string must do for you

#11

The only reason cookies are used in web development is because there’s otherwise no reliable way to store some consistent session data across requests. This isn’t a problem in Roblox since you can associate session data with a player directly. What does this module solve that cannot already be done much more efficiently and securely than that?

1 Like