How to use Afar Shield

Using Afar Shield helps to protect your products against leaking and unauthorized copying. In this guide, we will demonstrate how to use Afar Shield to protect your products.

DISCLAIMER: Although we have added security features to Afar Shield to make it more difficult to bypass the whitelist verification, no obfuscation tool can be completely secure, and a determined and skilled attacker may still be able to bypass the protections we have in place. However, we believe that Afar Shield provides a significant improvement in security compared to the other solutions currently available, and it should deter most leakers who don't have the technical knowledge to bypass the protections. The hope behind any obfuscation tool is to make it sufficiently difficult and time-consuming to bypass the protections, so that leakers will be deterred from attempting to do so in the first place. Because of this, we do NOT guarantee that Afar Shield is perfectly secure and impenetrable.

Step 1: Configuring your Scripts in Studio

Afar Shield supports ServerScripts, LocalScripts, and ModuleScripts. However, we also offer three different levels of protection, which you can choose for your scripts.

Protection Level	Speed	Security	Whitelist	Intended Use Case
Level 3	🔴 Slow	✅ Fullest	✅ Cross-Verified	The core Server Scripts that are the first to run.
Level 2	🟢 Fast	🟡 OK	✅ Cross-Compared	Module Scripts, Local Scripts, and duplicated scripts.
Level 1	🟢 Instant	🟡 Least	🔴 None	Scripts that need to run immediately.

To set a protection level for the script, add an Integer Attribute to the script with the name afar-shield, and set the value to the level of protection you want for that script.

For example, if you want to set the script to have level 2 protection, add an Integer Attribute with the name afar-shield and the value 2 to the script.

Note on Speed

Please note, Afar Shield can be computationally-intensive, so on startup, it may take some time to load your scripts, especially with levels 2 and 3. Please keep this in mind with the way you set up your code to run, as it may take up to a minute for your code to start working in extreme cases.

Step 2: Adding Whitelist Failure Behaviour

When a client tries to use your product without owning it, they will fail the whitelist verification. In such cases, you can choose to set what should be ran when the whitelist verification fails.

Add a String Attribute with the name afar-shield-whitelist-failure to the script you want to set the failure behaviour for, and set the value of that attribute to the code you want to run when the whitelist verification fails.

For example, you can set the value of that attribute to error("You do not own this product!") script:Destroy(), so when someone who doesn't own the product tries to use it, it will print an error message and destroy the script.

Feel free to customize the failure behaviour however you want, such as deleting the product or adding your own custom error handling. Please note, for failure behaviours set on LocalScripts or ModuleScripts required by LocalScripts, the failure behaviour will be ran on the client, which may not have the same access to libraries as the server.

Step 3: Export your Product

Right click on your product, and choose to Save to File. Save this in a place where you can find it to upload it to Afar.

Step 4: Uploading to Afar

For a new product

If this product has never been made before, you can simply upload the file you exported when running the /admin product create command in the file parameter.

Setup the details for the product, then, when prompted, ensure all the scripts you have attributed with afar-shield have been recognized. If not, you may have to go back and ensure you have attributed the correct scripts, and that the attributes are named correctly.

For an existing product

If you are updating an existing product, then you can simply upload the file you exported when running the /admin product update command in the file parameter, and select the product you want to update.

When prompted, ensure all the scripts you have attributed with afar-shield have been recognized. If not, you may have to go back and ensure you have attributed the correct scripts, and that the attributes are named correctly.

Final Notes

The afar-shield attribute and the afar-shield-whitelist-failure attribute will be removed from the scripts when the product is uploaded to Afar. This means the file your clients receive will not contain the attribute.

In addition to the previous statement, this means that the failure code cannot simply be "deleted" by the client, as we will embed it within Afar Shield's runtime environment. This means in order to remove the code, the leaker would have to bypass the obfuscation techniques we have put in, which should deter most leakers who don't have the technical knowledge to do so.

Your whitelist failure code will run if the server returns a failed response, or if there is a failure to communicate with the server. This means that if for whatever reason, our servers are down, your code will default to running the whitelist failure behaviour. We have done this so if an attacker tries manipulating the script environment (such as blocking communication), the product will still be protected.

Bug Reports and Feedback

As Afar Shield is an obfuscation system that creates its own runtime environment, there may be some bugs that occur when your scripts are ran in that environment. If you encounter any bugs, please report them to us immediately so we can diagnose and fix the issue as soon as possible.

A good way to check if there is an issue with Afar Shield is to download a copy of the product file after uploading it to Afar, and then replace the erroring script with the original code. If it errors with the obfuscated code, but not with the original code, then it is likely an issue with Afar Shield, and you should report it to us.