Massive improvement of (BuiltByBit) anti-piracy placeholders

[strom]

Problem with the anti piracy placeholders is that someone can find user id or username in string editor and just change user id (or username) to some other user id (or username) of someone who posted an review on your plugin.

Very simple and effective solution is to add optional encryption + base64 to placeholder values where user will have key which can be used with (AES) encryption to decrypt placeholder values. This is effective because key doesn't need to be provided in jar file and plugin can just send the encrypted value (which got encoded from the placeholders) to some backend and decrypt it there, it is impossible to know what was the value, therefore string editors become pretty much useless.

The key could be 16/32/64 bit value in string representation (initiation vector must be the same as the key)..

 

[Simon]

This literally exists. It's called hash. I recommend you to give it a second read.

 

[strom]

This literally exists. It's called hash. I recommend you to give it a second read.

There is only download hash and file hash which aren't encrypted and that's unique and not good for efficient ban system as it's unique and data behind it can't be "decrypted" (since it's hash) as it can be done with static flags like username or user id on the backend if it was encrypted with the AES method. User id and username also stay the same with the every download, they are static and therefore good for tracking specific users

User id and username still can be spoofed quite easily and the hashes will not help.

 

[Simon]

How will someone benefit from all of that? And how many people will? Just you, for some reason?
Because nonce and file hash are enough to ban and don't allow for framing.

 

[strom]

How will someone benefit from all of that? And how many people will? Just you, for some reason?
Because nonce and file hash are enough to ban and don't allow for framing.

With nonce and file hash you can ban only a specific file that got leaked. Even such hash values can be changed(spoofed) easily with string editor, however encrypting them with the same method as for user id, it would require someone to find the encrypting key in order to change them as the decryption would fail if they just change the string value to something else.

- Every creator that wants better anti piracy would benefit from this solution.
- BuiltByBit would also benefit from the change, as there would be less leaks.

I am also willing to create this feature for BuiltByBit, they could make a contract with my company.

 

[Tini]

User id and username still can be spoofed quite easily and the hashes will not help.

The hash do help as you can use it to validate the entire license data using the API. If any placeholder value is spoofed then the validation will fail.

"Retrieve a resource license by member"
https://builtbybit.com/wiki/v1-endpoints/

 

[strom]

But why would you change them instead of just removing them and reverse engineering the code. It's much easier than decrypting a base64/encrypted string, and is what already happens.

This change would literally make resources no more secure than they already are, they'd just avoid users reading some of the information (that they can still remove, and still work around in an anti-piracy system).

If you can give an example of an actual use case maybe I'll reconsider.

Just removing the code is not always easily done as code might have strong obfuscation and there might be checks which detect missing code parts.

 

[strom]

The hash do help as you can use it to validate the entire license data using the API. If any placeholder value is spoofed then the validation will fail.

"Retrieve a resource license by member"
https://builtbybit.com/wiki/v1-endpoints/

My solution is more simple and superior as it doesn't require an API and it's not prone to reversing how hash is being created.

Post automatically merged: Mar 2, 2024

I just wanted to inform you that the method leakers use 90% of the time is just entirely removing the licensing system you're using, it doesn't matter how obfuscated your code is.

As most licensing systems are not properly protected.

 

[Tini]

My solution is more simple and superior as it doesn't require an API and it's not prone to reversing how hash is being created.

Your "solution" is not even a solution but actual trash and if somebody wanted to skip your "validateStuff" method they can strip off the entire method body and replace it with a simple "return true;" statement. An actual leaker will either remove your entire licensing system from your .jar or dumb-ify it to always "return true". Current system is more than enough to stop decent people, and I assume the "hashes" are just randomly generated for every download so it wouln't be possible to even "reverse" them. Better use your time in providing a high quality, up-to-date resource than wasting it with implementing licensing systems.

 

[strom]

Your "solution" is not even a solution but actual trash and if somebody wanted to skip your "validateStuff" method

I never spoke about my integration method, however someone could do integrity + outside-of-function reference (function modifies the reference) value checks to handle just returning true.

With my placeholders system solution (I suggested to BuiltByBit as improvement to the current system) the in-plugin integration is the same as current (hash) one, but easier on the backend you use for your plugin as you don't need API to extract user id or other values, and more safe than hash or requires less data (BuiltByBit wouldn't need to track hashes).