Encrypt Api (Free)

Resources Community Resources
#22

I mean like if its not obfuscated it bypasses many of its security measures like an exploiter could just copy the code and run decode on client side. They won’t have the key but it could open up a brute force capability. If someone who is trusted wants the source I’ll send it to them I just don’t want it being publicly accessible.

#23

Exploiters can already bypass anti-cheats on the client. You really shouldn’t stress yourself out over a client-side anti-cheat because ultimately it will be bypassed. Not worth the effort.

It has to be, this is #resources:community-resources.

1 Like
#24

Instead, you should make a random key generator. I mean, that’s safer I guess instead of selecting your own key.

Use a random key generator so every game has a randomly generated key like “ydAeTHKujRGyyDMdeYyC5yQPzeGMFgHReeFqRCuNk9p3D9”

#25

Why? Exploiters can just send over that key by hooking invoke/fire server.

1 Like
#26

Where does it say source can’t be obfuscated.

1 Like
#27

Let’s be honest here, most exploiters are children who bought an exploit using their birthday money, executed a Remote Spy and using :FireServer on every remote they can find. It’ll take awhile for someone who actually knows how to do anything to combat this method.

Edit : Maybe forever, I have a simulator game and never in my life have I seen an exploiter who actually can bypass or combat with anti-cheats, all of them use infinite jump scripts and stuff

1 Like
#28

Exactly why I made this. Very few people are able to get the key and once one of these good scripters find it you can easily change the key and mess up their exploits. Just also want to add that it uses homebrew which has never been deobfuscated.

1 Like
#29

The “they won’t” logic is flawed. They will. And, if your game is big enough, surely exploiters have made scripts specifically for it, which account for these types of things.

Not to mention there are tutorials on how to make your own exploiting scripts, remote spy is one of them. Won’t link them here though

4 Likes
#30

True, but of course you’ll need to start using methods on the server-side by then, you deserve exploiters if you always trust the client-side.

My point is :

  • You should use server-sided protection.
  • Make an anti-cheat on the server-side.
  • Don’t trust the client-side.
  • Trust the server-side

Atleast keep this API for awhile but don’t just use this forever and expect your game to be 100% safe/secure. Protect your RemoteEvents, trust the server-side.

Not all APIs are gonna be the most secure thing in the universe.

#31

This api isn’t meant as an alternative to server-sided protection. It just makes it way harder to make exploits.

#32

Oof, what a way to defeat your own argument.

This module encourages trusting client side. The problem is that when devs use obfuscation as the only “security” against exploiters it gives a false sense of security, which is what this module promotes. Just secure your remotes, make sure the arguments passed through are valid and the remote is fired at the right time and such, you don’t need any obfuscation.

And overall, it is just a matter of exploiters doing

local old
old = hookfunction(Instance.new("RemoteEvent").FireServer, function(remote, key)
    return old(remote, key) -- they are sending over the key
end)
1 Like
#33

I’m not saying it’s an alternative, I’m saying it’s a way to protect yourself against skids

#34

That not how the module code works read the post before saying its an easy bypass. The key is never sent between the client and server.

#35

I don’t believe this should be in #resources considering the source is obfuscated and, if you’re afraid that someone will engineer some script to bypass your method of encrypting remotes, maybe it isn’t that secure after all.

Assuming you were going to send an “encrypted” key to the server, you’d be better off using prime numbers to generate a new key once a remote is fired so exploiters can’t use a remote spy to get the key but, this isn’t exactly secure as an exploiter could prevent a remote from being fired (intercepting it by modifying the metamethod :FireServer) and, they could use the key from a compromised remote.

Overall, I think “encrypting” remotes is a horrible idea and, you should verify everything on the server instead.

9 Likes
#36 
 local Key53 = 8186484168865098
  local Key14 = 4887

  local inv256

  function encode(str)
    if not inv256 then
      inv256 = {}
      for M = 0, 127 do
        local inv = -1
        repeat inv = inv + 2
        until inv * (2*M + 1) % 256 == 1
        inv256[M] = inv
      end
    end
    local K, F = Key53, 16384 + Key14
    return (str:gsub('.',
      function(m)
        local L = K % 274877906944  -- 2^38
        local H = (K - L) / 274877906944
        local M = H % 128
        m = m:byte()
        local c = (m * inv256[M] - (H - M) / 128) % 256
        K = L * F + H + c + m
        return ('%02x'):format(c)
      end
    ))
  end

  function decode(str)
    local K, F = Key53, 16384 + Key14
    return (str:gsub('%x%x',
      function(c)
        local L = K % 274877906944  -- 2^38
        local H = (K - L) / 274877906944
        local M = H % 128
        c = tonumber(c, 16)
        local m = (c + (H - M) / 128) * (2*M + 1) % 256
        K = L * F + H + c + m
        return string.char(m)
      end
    ))
  end
end

local s = 'Hello world'
print(       encode(s) ) --> 80897dfa1dd85ec196bc84
print(decode(encode(s))) --> Hello world

I have no idea who created the original, looks like edited version of it as the constants match but not the actual encryption format.

5 Likes
#37

Thats not the original code of the module. I took a small part out of the decode.

#38

It is an easy bypass.

All an exploiter needs to do is see what arguments are being sent over. And they can do just that by hooking the fire/invoke server methods. Since your game local scripts will be calling the tampered version of fire/invoke server with the key.

1 Like
#39

That’s not how the module even works it never even calls with a key. If you test it in studio you can see how it works. Encrypt Api Place - Roblox

#40

Since the code is obfuscated it is hard to understand how the code works, and lack of in-depth documentation isn’t helping.

And literally the key is in the local script in the place and in the OP. So what prevents someone from decompiling the local script? What prevents them from reverse-engineering an obfuscated script? There are tools to reverse-engineer obfuscated scripts, so you can’t use that excuse.

1 Like
#41

Encryption algorithms are specifically designed so that if a malicious person knows the function, they still cannot decrypt a piece without the key.

Open-sourcing the original code can’t hurt you or your module. It can only help in improving the module to be secure through feedback on possible flaws in the design. Even professionals make mistakes with encryption algorithms; which seem secure but can be broken.

1 Like