A more secure anti piracy method?

Discussion in 'Spigot Discussion' started by TJM4, Jun 3, 2017.

  1. Hi,

    Before I start this thread is not about if should you put anti piracy in your plugins, I am posing an idea about how you could make your plugins more secure.

    So all plugins that I know of that have anti piracy send the %%__NONCE__% ID to a web sever (if you have no idea what I'm on about read about it here) and check if it is on a blacklist of pirated NONCE ids. If it is the plugin will disable itself. The problem with this is it can be decompiled and the anti piracy feature removed. Developers try to make this harder by obfuscating there plugins however there are tools to remove this protection (read more about this here).

    I think however that there is a way to make it harder for pirates to remove the anti piracy features from plugins. This idea could be completely floored in some way so please comment if it is. If you make a vital part or your plugin web based (e.g. the plugins config) and the plugin fetched the data from the web server (to access this data it would need to provide the NONCE id and some kind of key to ensure that other people can't steel that servers config), you could restrict if the plugin could access this data at the web server side meaning that a 'pirate' could not remove it. A 'pirate' could create a fake NONCE id however you could easily block an id at the server end of null of whatever that have changed it to. Please note that a 'pirate' could still re-code this vital part of the plugin to be handled at the plugin side - it would just be a lot of hard work and would be a nightmare with updates.

    1. A lot harder to pirate the plugin
    2. If something happens at the Spigot server end the config is still saved and can be recovered
    1. You need to pay for and maintain a web sever (unless you get a free one)
    2. If your web server goes down there will be a lot of angry people who can not use the plugin
    I'm not sure - this was just an idea and could be too much effort to implement. Let me know what you think.

    - TJM4
  2. Mas


    Spigot's premium resource giudelines state that all plugins must be able to function with no internet connection, and you aren't allowed to disable the plugin or any features of it if web connection cannot be established (of course exceptions are made for plugins which need to communicate with external APIs as their sole purpose, eg Youtube/Twitter APIs).

    So this wouldn't be allowed unfortunately.
    • Agree Agree x 3
    • Informative Informative x 1
  3. If you dig through old threads about: anti-piracy, protecting plugins, you'll find that there's no true way to protect your plugin (also due to guideline limitations), as far as obfuscation. And from what i've seen, the plugins that get leaked are costly $$ plugins, so of course they're going to get leaked; Either way, it's unavoidable; and that's why it's not worth going through the trouble protecting some minecraft plugin
  4. Best way to protect premium plugins against piracy is not to. Atleast not in the actual plugin.
    You can send some DMCA alerts if you want to, but most cases that won't help.
    Usally owners that are searching for leaked plugins, won't even buy it anyway.
  5. You can set a built in self destruct thing.
    Make it do it every month or so. Do it for all version so they are forced to update

    Code (Text):
    if(System.currentTimeMillis() >= 55148133600000L) {
    That one is 6/30/2017.
    Do System.out.println(new Date(year - 200, month, day).getTime()); to get the time. Then hardcode it in.
  6. Thanks for letting me know - I was unaware of this

    Yeah I knew it was impossible to avoid, was just trying to make it harder

    This could work but if you released versions of the plugin that do not work with past versions of the game and somebody still ran that version you could run into compatibility issues. Also this feature could just be removed by a pirate


    @ItsMas_ I just read over the guidelines and the only reference I could find was
    If you made the web part of the plugin not part of the plugins main functionality then would this be permitted
    #6 TJM4, Jun 4, 2017
    Last edited: Jun 4, 2017
  7. The disadvantages far outweigh the positives.

    Piracy will always happen, it's part of life. Why are you making it harder for your customers, people who paid money, to use your stuff just to make it harder for people to pirate it - who probably wouldn't have paid for it anyway? This hurts your customers more than it hurts them - it just means they go and pirate something else. Either way, a pirate could just remove all of these checks and add a local config.yml by looking at the used variables.

    Essentially, regular customers suffer and pirated versions end up having a better copy than your real customers. Hardly fair, is it?
    • Like Like x 2
    • Agree Agree x 2
  8. I generally believe that anti piracy should be enforced by the hosting company. However, this is a very nice idea :)
  9. That's a very valid point and I strongly agree with you looking over it. As I said
    What is your opinion on if it was not the config.yml? For example, lets say that there was a web based generator to create yml files for your plugin making it easier for the consumer to generate the file (for example if this was web based). You could then make it so you could send this to the server by pressing a button - of course you would need to do some security stuff to verify the account but that's not what this thread is about. It would be now that you would preform the checks. Of course they could manually make this file, it would just not allow them to have access to this external tool.


    Sadly this would never work - home housed servers etc. Would be nice tho
  10. Hex

    IRC Staff

    It's better to spend your time updating your plugin to keep ahead of leakers than to spend time on an anti-piracy method that's going to get cracked in hours, if not minutes. Nothing you do short of native code will stop someone familiar with Java, and a determined reverse-engineer won't stop there.
    • Agree Agree x 1
  11. That will piss off legit users
  12. Yeah IK but it works.
  13. If anything it'll just encourage piracy or push users to another similar plugin (or make one if it doesn't exist) as the pirate version will likely remove the check are decompiling it.
  14. Yeah lol,
    as I said before, the best way is to use some simple spigot & proguard, then send a dmca alert, to both the site and file hosting service, each time you see your leaked plugin.
  15. There is no way to protect your plugin 100%.

    Keep updating your plugins and everything is good :)
  16. Actually, there is, it would just be very tedious and make your plugin large and possible slow. What if you made a plugin that was entirely on a website, then made another plugin that only sent and fetched values that would tell the spigot server what to do? So if I wanted to make a custom inventory, then I'd have a plugin that simply sent information to the website and retrieved any output which I sent to the client. Therefore, it's like a plugin where you cannot get any actual code that does cool stuff, just the code that sends and received data from the internet to the clients.
    • Funny Funny x 1
  17. I use anti piracy systems in my premiums which are more basic, but my father gave me a quote which someone has said above:
    "Those wanting leaked versions won't ever buy your plugin so don't bother adding anti piracy".
    • Like Like x 1
  18. I feel that it would violate this premium plugin rule

  19. Yes, it may not be allowed on the spigot forums, but once again, that's for the extremist who wants to keep all their ideas safe:rolleyes:. Although, it would make updating it very easy, because all of it is done server-side. Besides, it is technically "plugin based" because you're computing the data on the website, not the server. It could also keep premium plugins from being stolen, because you could have a database of all the registered servers that have bought your plugin:)
  20. I guess it depends how the reviewer interprets "main functionality"
    • Agree Agree x 1