• If you haven’t read the introduction of this guide, you can check it out here
• If you haven’t read the previous part, you can check it out here
• You can check out the repository for this guide here

Introduction

In this part, we will be discussing some extra tips and tricks that you can use to improve your whitelist system.

• This is sort of a “bonus” part, you don’t have to follow these tips but they can be useful in some cases.

Tip #1 | Server-side detections

In our whitelist that we wrote during the series, it is possible that we can catch attackers guaranteedly with no margin of error.

This works by creating a new RNG Value we have in our whitelist with a function that returns a float value. Then we can check if the value received on the server-side is a float aswell.

• This is a very effective check to search for RNG manipulation, and it is very subtle to the attacker.

I’ll write the example in a semi-standalone pseudocode, so you can understand it better.

local number = math.random() -- This will return a FLOAT (a number with decimal places)
local sendingNumber = math.random(1,100000) + number -- To help avoid the attacker to spoof the value to a float aswell, add a number to it.

-- Send The number to the server

Now here’s the catchy part:

// Check for float on the server
if (number % 1 !== 0) {
    // Number is a float | Continue checks
} else {
    // Number is not a float | blacklist the player automatically
}

This helps with early attack prevention, and it is one of the only effective yet subtle ways to detect tampering.

Tip #2 | Certificate Pinning

• You need basic comprehension of how HTTPS & TLS works in order to implement this.
• If you want to read more about Certificate Pinning, you can check out this page

What is Certificate Pinning?

Certificate pinning is a security mechanism used in the context of authenticating client-server connections, particularly in the context of secure communication over HTTPS (Hypertext Transfer Protocol Secure) or other TLS (Transport Layer Security) protocols. Its primary purpose is to enhance the security of the connection by mitigating the risk of man-in-the-middle (MITM) attacks and ensuring that the client only communicates with a trusted server.

How does Certificate Pinning Work?

• Standard Certificate Validation: In a typical TLS handshake, when a client connects to a server, the server presents its digital certificate to the client. The client then checks the certificate’s authenticity by verifying that it has been signed by a trusted Certificate Authority (CA) and that it hasn’t expired or been revoked. If the checks pass, the client proceeds with the secure connection.
• Pinning Trust: Certificate pinning takes the trust verification a step further. Instead of solely relying on the CA system, the client’s application or device has a preconfigured list of public keys or certificates that it explicitly trusts.

MITM? What’s that?

MITM stands for Man-In-The-Middle. It is a type of cyber attack where the attacker secretly intercepts and possibly alters the communication between two parties who believe they are directly communicating with each other. This can lead to sensitive information being stolen or manipulated without the knowledge of the communicating parties.

Okay, how does it help?

In our context, the attacker can intercept the communication between the client and the server and read them externally using tools like Fiddler or Wireshark. Which can ultimately negate any sort of Anti-Hook you’ve implemented within your client.

How these tools work is that they act as a proxy between the client and the server presenting a fake certificate to the client, and the client will trust it because it is signed by a trusted Certificate Authority (CA).

By implementing Certificate Pinning, you can prevent this from happening by making sure that the client only communicates with a trusted server. This is done by comparing the server’s certificate with a preconfigured list of public keys or certificates that the client trusts.

• Older gen executors like Synapse X used to run checks for reverse proxies by default, though they were not very effective.

Tip #3 | Raw Implementations

By raw implementations, I’m referring to avoiding the use of direct library functions & methods to help minimize risk of hooks.

For instance, instead of relying on HttpService’s JSONDecode to parse the response body, you can write your own JSON parser or use an external one like this. This would make it harder for the attacker to spoof your response.

Conclusion

With that, we’ve concluded everything necessary for a whitelist system! I hope you’ve learned something new from this series, and I hope you can implement what I’ve provided & also improve on it, good luck!