Anti-piracy placeholders

To offer BuiltByBit’s resource creators the utmost means of self-protection when publishing their resources, all resource categories offer placeholders which will be used to inject the download information at their locations every time the resource is downloaded.
This information can be used to identify any users who have leaked your product, identify the exact version which was leaked, and even develop your own DRM system.

Placeholder Identifiers​

The following placeholder identifiers are available for usage in all resource categories:

%%__BUILTBYBIT__%% - ’true’ for all resources downloaded through our platform
%%__USER__%% - Downloader’s user ID
%%__USERNAME__%% - Downloader’s username
%%__RESOURCE__%% - Downloaded resource ID
%%__VERSION__%% - Downloaded resource version
%%__TIMESTAMP__%% - Download epoch timestamp
%%__FILEHASH__%% - A unique hash representing the download Deprecated: Use NONCE instead
%%__NONCE__%% - A secondary unique hash representing the download *

* Only NONCE is suitable for anti-piracy measures. Other data is already known to the downloader and is easily searched for and modified. Avoid placing other injected data, such as username or user, alongside NONCE, as it may give away their location.

More placeholders may be made available at a later date. Please create a suggestion if you would like additional placeholder identifiers.

Usage​

If you’re going to use these placeholders for anti-piracy purposes, we strongly recommend that you utilize several of them, in order to ensure that misleading information cannot be edited into your resource prior to it being leaked, in an attempt to frame another downloader.
Note that the username and user id placeholders are very poor choices as an anti-piracy measures, since they're so easily identifiable to crackers.

Files are read in UTF8, and if an occurrence of these placeholders is found, it is replaced with the respective download value. The exceptions to this are .zips, .jars, java .class files, and .rars.
.zips and .jars are opened and processed as directories.
Java .class files have their bytecode processed, and string constants read for placeholders.
.rars are simply copied over. More info under the Limitations section.

Hiding placeholders​

You can take advantage of the variety of scanned files by opening up non-text files in your text editor, and hiding a placeholder in there. Some file formats will corrupt with the inclusion of additional data, however, you will find that many do not, especially if placed in the correct locations.
For the sake of not providing leakers with a definitive list of file extensions and locations to check, we will refrain from providing an “official” list of file extensions to hide data in, but please do your own individual experiments.
It is recommended that you use your anti-piracy placeholders in multiple hidden locations to reduce the chance of them all being found and removed. Moreover, as previously stated, avoid placing anti-piracy data next to known data such as usernames, as the leaker will be able to search for this and it may give away the position of your anti-piracy data.

Tracking downloads​

Much of the download information used for injection can be found in the transaction tracking page for each resource purchase. NONCE and HASH are excluded to ensure that sellers are incapable of framing their buyers for leaking. Please use those placeholders in any anti-piracy measures you employ.

Staff members on BuiltByBit will be able to view this information and ban any users found to have leaked your product. Please open a Support Request to report any external violations of your rights as a content creator.

Building a DRM system​

If your product is a running program, you might consider utilizing the injected information to identify and automatically perform actions upon the leaked copy.
The most important thing to realize is that there is no copy of a product that cannot be cracked. Any file is just a collection of data, and once that data gets into the hands of an end user, there is nothing preventing them from manipulating it. Our goal as content creators is to make it as difficult as we can for them to remove our protections while maintaining a working copy.

If you attempt to utilize an external server to validate a product copy's unspoofable file signature, they can remove the validation step.
If you attempt to add an integrity check, to determine if the copy has been modified, they can remove that check.

Our most effective option is to ensure that whatever DRM systems we include in our product, they are well hidden and or very difficult to remove without impairing the functionality of the product.
Be creative. Be unique. If you follow suit with what every other developer is doing, crackers will expect those methods to be used, and will know what to look for when opening your product. It is for that reason that we are not listing specific methods here, nor do we offer a standard injected DRM system.

If you do have your DRM system disable, delete, or otherwise change the experience of the product when a leak is detected, it is recommended that you keep identifiable data separate from that functionality, so that the data needed to trace back the copy to its original downloader is not removed, and the leaker’s BuiltByBit account can be banned.

Limitations​

.rar files​

The rar format is a proprietary archiving format specific to winrar. Modifications to these rar files cannot be made without the winrar software. Currently, support for rar archive placeholder injection is not available. This may change in the future, however, for the time being, if you would like to archive files that should be scanned for placeholders, please use the opensource .zip archive format.

If you have files which you would like to not be scanned and injected, you may wrap those files in a rar archive. It will not be touched.

Reliability​

BuiltByBit cannot guarantee that all of your placeholders will be found and replaced. Especially in cases of corruption that commonly results from obfuscation, some files may be skipped and thus copied over. Moreover, not all strings in your java class files are recorded by the compiler as constants, and thus cannot be edited on our end through reasonable means.

Please always verify that all of your placeholders are being replaced as soon as you upload your resource by downloading it for yourself and checking the relevant locations.

Obfuscation​

Obfuscation and encryption is a great way to make reading your code more difficult for crackers. However, if you use these, be sure to exclude the placeholder identifiers so that BuiltByBit can identify them and replace them with their associated values.
Most obfuscation/encryption tools will have a means to exclude string patterns, so do reference the instructions for whichever tool you’re using.

Note that by nature, this string injection does directly modify the contents of your files. The resulting downloaded file is different from the one you uploaded. Ensure that if you add integrity protection, you are properly accounting for the modifications to the file’s contents.
If you have any issues getting your resulting downloaded product to function as the uploaded product does, and you require assistance, we encourage you to create a Support Request so that we may assist you to the best of our abilities with your circumstances.

Stay safe, and protect yourself.