'Locking Down' A plugin to one server?

Discussion in 'Plugin Development' started by stuntguy3000, Feb 6, 2013.

Thread Status:
Not open for further replies.
  1. Offline

    stuntguy3000

    Hello Bukkit,

    Just wondering, how would you go about making a plugin to work only on one server (As in you could give it out and nobody could use it, assuming nobody could open up the source)
     
  2. Offline

    LaxWasHere

    Check the ip?
     
  3. Offline

    Sagacious_Zed Bukkit Docs

    Ip addresses are dynamic.
     
  4. How about checking the MAC address. Not really a secure method as a MAC can be faked as well, but only if you have root access to the server.
     
  5. No matter what you do there will be some way around it.
    You could add a 'secret password' to the config file that only servers that give the correct password will be able to start the plugin.

    If you do add a feature to limit which servers can use the plugin you won't be able to deploy it to Bukkit because they won't be able to approve a plugin that can't be used/decompiled.
     
    Liam Allan likes this.
  6. Offline

    Liam Allan

    AlexLeporiday likes this.
  7. Offline

    !Phoenix!

    The question by stuntguy3000 sounds a little like s.o. made a plugin-request and he wants to limit the usage to the requesting person, which btw. wouldn't require an upload on BukkitDev. But a password wouldn't work out in this case, because the server owner could still give out the plugin and the pw.

    Despite the fact that you can't create java-files which can't be decompiled (-> s.o. can 'unlock' the code), you could really try to stick to unique attributes of the system the plugin is running on. E.g. the IP (if static, simply to grasp) or other hardware-things like the mac-address, but I can't tell how to access those.
     
  8. Offline

    stuntguy3000

    "The question by @stuntguy3000 sounds a little like s.o. made a plugin-request and he wants to limit the usage to the requesting person, which btw. wouldn't require an upload on BukkitDev. But a password wouldn't work out in this case, because the server owner could still give out the plugin and the pw."

    Nope, Just wondering on ways it could be done.
     
  9. Offline

    !Phoenix!

    But the situation I made up could fit your question?
     
  10. Offline

    blablubbabc

    What about simple licensing and suing if somebody else uses it/gives it away? It's no "protection", but you wouldn't have to care about how to protect your code/plugin etc. ..

    Still you could additional try to "pseudo-protect" your code/plugin by obfuscating/sytem-checks/passwords/authentification with your server/whatever.. This will not really "protect" your plugin from being able to be deobfuscated/modified/etc. but will make it maybe more "complicated"/"less fun" for someone to go around your checks. So you can maybe decrease the amount of cases of people disregarding your license you have to look after.

    And you could constantly change and update your plugin, adding new cool features and bugfixes. If you frequently change your plugin, it will again maybe keep people from bypassing your checks etc. cause it's no fun to do this again and again..
     
  11. Offline

    desht

    It can't be done.

    Someone can always decompile the code & remove whatever checks have been added. Obfuscation will slow the effort down, but it certainly won't prevent it (if obfuscation was actually more than a annoyance, CraftBukkit or MCP wouldn't exist).
     
  12. Offline

    travja

    You could create a dummy player using a cracked client, some random name log into the server, then in your plugin check if that random, nonpremium, player has played before
     
  13. Offline

    !Phoenix!

    I haven't dealed with this yet, but in case a publication on BukkitDev isn't required, couldn't there be a way by putting some kind of exe / decompileable code in the jar that is used?
     
  14. Offline

    Rprrr

    Best solution: don't give it to people you don't trust (if a plugin really matters that much to you).
     
  15. Offline

    keensta

    But if they could decompile your obfuscation and remove then checks then surely that person can just make the plugin in the first place and doesn't need your assistance but a norm server owner wouldn't be able to decompile the code.
     
  16. Offline

    desht

    Who says it has to be the server owner? Server owners are running CraftBukkit quite happily, and I'm sure most of them don't know how to de-obfuscate minecraft_server.jar. We can assume that whoever is legitimately receiving the plugin JAR (i.e. the admin of the server it's supposed to run on) can't be trusted, or the protections wouldn't be wanted in the first place. And if the server admin really is untrustworthy, then the plugin will sooner or later leak into the wild, and anyone who wants it will get a copy.
    It only takes one person to crack the plugin and redistribute the cracked version, and it's game over. If the plugin is so good that it needs all this amazing protection, you can be sure it'll get cracked by someone.

    The best protection is robust licensing terms and a credible threat of legal repercussions. In other words, license it, and get a good lawyer. (I say "best" here, meaning "least worst").
     
    Craftiii4 likes this.
  17. Offline

    arrexe

    The only possible way to make it 99%+ restricted that I can think of, is have the functionality of the plugin depend on it contacting an external server that requires the correct password hash to receive a reply. However, this would require a powerful server (depending on the amount of people using the plugin), and would cause a BIG delay to any of your plugins features, as it would first have to authenticate itself, send the information, and wait for a reply.

    Best bet is desht's idea, or just downright don't release your plugin to the public. If something is worth being cracked, it eventually will be.
     
  18. Offline

    Mitch528

    Here's one way you can do it:

    1. Generate a unique key for each server
    2. When the plugin starts, send a request to your web server with the unique key and the server's port number
    3. Server-side validates key
        1. Correct key: Check for an existing IP Address in your database corresponding to the unique key
          1. Exists: Run a query on the existing IP Address/Port to check if it's online (only if the IP Address/Port is not the same as the one requesting access)
            1. Online: Return an error to the plugin
              1. The plugin then disables itself
            2. Offline:
              1. Return a success message to the plugin
                1. Plugin then continues startup as normal
          2. Does not exist: Insert IP Address and Port into the database corresponding to the unique key
            1. Return a success message to the plugin
              1. Plugin then continues startup as normal
        2. Incorrect key: Return an error to the plugin
          1. The plugin then disables itself
    This isn't necessarily the best way, but it should work.
     
  19. Or even if you find a way to some how make it uncrackable... how does that prevent some good coder from re-making it from scratch and release it as their own and they get all the credit for releasing free software ? :p It doesn't even have to be 100% perfect and bug-free, it just has to work in a similar way and people will use it.

    So yeah, use the Law, "Luke" ! =)
     
  20. Offline

    Shevchik

    srsly?
    Decompiling -> changing 1 string -> compiling this class again -> profit
     
  21. Offline

    Mitch528

    I didn't say it was the best solution, but it is a solution nonetheless. All programs can be decompiled. There isn't really a way to avoid that, besides obfuscating it, and even that won't deter someone who is determined.
     
  22. Offline

    jorisk322

    What do you actually want this for? It depends on the situation which solution is best.
     
  23. Offline

    stuntguy3000

    Nothing, as said above

    "Nope, Just wondering on ways it could be done."
     
  24. Offline

    turt2live

    Since a lot of solutions have bee posted (and shot down), here's another one to shoot at:

    Create a way to sign the jar with a unique identifier, then create/edit a second plugin to look for that signature for you. If the second plugin cannot verify the jar of the 'to be secured' plugin, the plugin should disable the zombie plugin.
     
  25. Offline

    RealDope

    lol the second plugin can be decompiled to see what it's looking for, and easily changed or mimicked.

    Face it dude, there's no solution to this. A determined person can edit any code, get around any "lock", and honestly do whatever they want with a plugin.
     
  26. Offline

    Ne0nx3r0

    That being the case, here's something that would be annoying to get around, depending on what the plugin does.

    If you did some of the lighter (but complex and vital enough that the vast majority of coders would give up before recreating it locally) processing at a remote server via a socket and returned the result, you could only talk to specified servers. So if for example the entire plugin were written to use a remote cloud-based API, the "thief" would basically have to write the entire API themselves. As an added bonus with each request you could also send code challenges and if the result doesn't come back correctly stop giving the server the data that is needed. So the server in many ways becomes a client. It would add some latency, but it's probably manageable in most instances. This, combined with obfuscation and/or injection from another language, preferably one that's compiled would create a fairly aggravating plugin to rewrite, enough so that it would basically make more sense to recreate the plugin from scratch. The injection would be especially valuable as the likelihood of finding a developer that is both willing and capable of doing the dirty work is decreased.

    That said, considering the amount of code and resources it would take to make that happen, you're likely better off using basic mitigation techniques and letting them pirate it if they really want to work around the protections. Consider the number of people who pirate Minecraft, compared with their massive profits.
     
    jorisk322 likes this.
  27. Offline

    turt2live

    Who says the server, or developer, knows what the second plugin is?

    You could inject it on first run. Sure people could decompile it before it runs the first time, but in reality people will only decompile it after they realize that they can't use it.
     
  28. Offline

    JeroenV

    There are ways to do this but it depends on how far you'd like to go, I've got one option to add to the list here that should prevent any kind of decompiling nonsense:

    You can make it so the plugin downloads its classes from an online database. You could either encrypt this database or use keys. That should pretty much prevent them from getting into your source code, however persistent people would still be able to reach it eventually. It should put up a nice wall for them though.
     
  29. Offline

    desht

    JeroenV and how are you proposing to prevent decompilation of the plugin and extraction of the database details, including any encryption keys?

    Seriously folks: It. Can't. Be. Done. The entertainment industry still hasn't figured this out, but this is supposed to be a developer forum - people here should know better. If you give someone the code, no matter how indirectly, then it's game over.
     
  30. Offline

    JeroenV

    It's meant as a wall, as long as the plugin can acces it anyone else can.. So yeah it's impossible to do so. Perhaps you could make the plugin send a certain code to a database which will then provide it with some vital class only if the number of instances running corresponds to the amount the developper has set it.

    So if there are already 5 plugin instances running and the developper only gave out 5. You can't send the data to a sixth.


    If all else fails, you could possibly work together with a hosting company that will install the plugin for people with permission but restrict these people from downloading it.
     
Thread Status:
Not open for further replies.

Share This Page