Market Antileak

[IWolfZ]

Feature request

Checklist

• I have read and agree to the README (found on https://github.com/Minehut/Meta)
• This is not a bug report, support request or plugin request
• I have searched the Issue Tracker to make sure this is not a duplicate issue
• This issue does not contain any sensitive information

Platform

Website

Describe the feature

Okay so Minehut market should have an antileak which skript creators have an to turn on/off antileak for that item that they are selling. What the antileak basically does is it makes it so you cant touch the skript code it would just be a file on skript but you wouldn't be able to edit or look into the code, but you can disable or delete it.

How the feature is useful

This would be very helpful to many Market Creators because people wouldn't be able to just copy the code and send it to their friends.

---

Use 👍 and 👎 reactions to indicate you agree or disagree with this suggestion! Feel free to discuss the idea in the comments.

[ghost]

some scripts have configurations in the file, which disallows people to change options

this could be solved with external configs (.yml), however, minehut still does not support any skript addons that modify files

[CerialPvP]

some scripts have configurations in the file, which disallows people to change options

this could be solved with external configs (.yml), however, minehut still does not support any skript addons that modify files

also you could make the skript disable the PlayerServer plugin which Minehut doesn't want (obv)

[IWolfZ]

some scripts have configurations in the file, which disallows people to change options

this could be solved with external configs (.yml), however, minehut still does not support any skript addons that modify files

I said the creator has an option to turn it on or off

[IWolfZ]

Lmao why do you all down vote it when you like all dont know the perspective of a market creator. Like put ur shoes into the market shoes, Basically Imagine if you're selling a big skript and you don't want it getting leaked their is current no antileak so it can get leaked

[TrueReassembly]

Privating wouldn't work for minehut, since it would rule out file configuration, but maybe obfuscation would work

[IWolfZ]

Privating wouldn't work for minehut, since it would rule out file configuration, but maybe obfuscation would work

Wdym privating would work , the file wouldnt be edit able in skripts so no one can see the code

[TrueReassembly]

But some devs want you to configure it, and most do it through options

[ghost]

some scripts have configurations in the file, which disallows people to change options
this could be solved with external configs (.yml), however, minehut still does not support any skript addons that modify files

I said the creator has an option to turn it on or off

so creators will have to choose to either disallow customization for people who want to make subtle changes or make extra sales off unsuspecting people?

[ghost]

Lmao why do you all down vote it when you like all dont know the perspective of a market creator. Like put ur shoes into the market shoes, Basically Imagine if you're selling a big skript and you don't want it getting leaked their is current no antileak so it can get leaked

you're just whining that some people just disagreeing with your suggestion. Also, your suggestion doesn't really solve the problem of leaking files and giving users customizations

[CerialPvP]

But some devs want you to configure it, and most do it through options

ofc they do
for example: if there will be a discord skript at the market then you cant have like "TOKEN_HERE" as the token for the bot, because Vixio will look for any bot tokens matching that. Ofc if it finds the token in the Discord API it will make the bot online, but obv "TOKEN_HERE" is not a token, it's just a placeholder for you to replace it with the actual bot token.

Also they are not gonna disable copy & pasting skripts because most of the people do that.

[CerialPvP]

so I don't think Minehut will be disabling:

1. Customization (i explained ^^
2. Copy pasting (because ppl use that in their daily basis)

[Shigbeard]

This is a problem that Scriptfodder (a gmod LUA scripting marketplace) encountered a while ago. They used a slightly different solution.

While the raw code for the addons was still available, most of the functionality was hosted behind a restful API. When you download the skript to your server, the Marketplace would add some sort of unique ID to the code in a specific spot (pretty much a text replacement, replace {USER_ID_HERE} with the id). The code you'd load into your server would contain (obfusicated) instructions to retrieve this code on start using the user id. The server would then be responsible for logging information about who's requested the code, whether the request is authorized, and to deliver the code, which would then be executed on the server remotely.

Now I'm not too familiar with Skript, nor if there is functionality for controlled remote code execution, but that's the best bet at trying to control leaks without negatively impacting flatfile configurations. The API would need to be able to limit concurrent uses, or log unique uses. Skript devs would then be able to revoke access to their skripts to people they suspect of leaking (based on the number of uses).

It's not an easy nor perfect solution, and it might not even work in Skript.

EDIT: It's worth mentioning that with this solution, Skriptfodder did not provide a means for end users to customize addons they received. Rather, it was on the addon developers to decide whether to share the non-obfusicated code with users upon request. Many refused, stating that it put their livelihoods at risk of being leaked.

[quick007]

This is a problem that Scriptfodder (a gmod LUA scripting marketplace) encountered a while ago. They used a slightly different solution.

While the raw code for the addons was still available, most of the functionality was hosted behind a restful API. When you download the skript to your server, the Marketplace would add some sort of unique ID to the code in a specific spot (pretty much a text replacement, replace {USER_ID_HERE} with the id). The code you'd load into your server would contain (obfusicated) instructions to retrieve this code on start using the user id. The server would then be responsible for logging information about who's requested the code, whether the request is authorized, and to deliver the code, which would then be executed on the server remotely.

Now I'm not too familiar with Skript, nor if there is functionality for controlled remote code execution, but that's the best bet at trying to control leaks without negatively impacting flatfile configurations. The API would need to be able to limit concurrent uses, or log unique uses. Skript devs would then be able to revoke access to their skripts to people they suspect of leaking (based on the number of uses).

It's not an easy nor perfect solution, and it might not even work in Skript.

EDIT: It's worth mentioning that with this solution, Skriptfodder did not provide a means for end users to customize addons they received. Rather, it was on the addon developers to decide whether to share the non-obfusicated code with users upon request. Many refused, stating that it put their livelihoods at risk of being leaked.

Pretty sure skript has read and write but I believe it's disabled on minehut.

[malloryhayr]

It's impossible to fully protect anything that has to be made available at runtime. This conversation has been had many times before.

[Shigbeard]

It's impossible to fully protect anything that has to be made available at runtime. This conversation has been had many times before.

The idea isn't to protect it as much as it is to trace unauthorized use of it. If you can identify 100 servers that pull the code as using a license for a particular user, surely you could revoke that user's license and suddenly 99 users who were using leaked code now need to pay for a license. But again, this is entirely dependent on 3 things:

1. Can Skript query a remote API at run-time to retrieve and execute external Skript code? When I ask this, I don't just mean "can Skript query a webpage", but also "can Skript interpret a response from a webpage as executable code, and then execute it?" and "Will this block Minecraft from behaving properly?" or "What can and cannot be done this way?"
2. Can Skript be obfusicated so that it's difficult to read or understand? Not just to secure the server-side code that would be delivered via API, but also the client-side code that is responsible for requesting the code from the server with a valid license. If so, it would combat dumping attempts, and make it harder for lesser skilled leakers to leak paid-for skripts without leaving some sort of tracing code that can be used to identify those responsible for leaking.
3. Can an API tell the difference between a user trying to pretend to be a Minehut server running Skript trying to retrieve code and a malicious third party trying to simply dump the code to file?

In Gmod's case, all code that was delivered to remote servers via the API also included some diagnostic code that could be used to read information about the server. What's in its data folder? What's in it's addons? Who is on the server? Who's license is this? This information was then analyzed and would raise alerts if a dumping attempt was in progress. I'm not sure if the same is possible in Skript.

In the end, you are right. Preventing leaks outright is impossible. But if we can identify people who leak skripts, we can flag those users and make it harder for them to leak other skripts. And if we can require a license key to request code, we can make it so leakers must leak a skript multiple times, each time a license gets revoked (or failing that, spend the time and energy to deobfusicate code)

[quick007]

Can Skript query a remote API at run-time to retrieve and execute external Skript code? When I ask this, I don't just mean "can Skript query a webpage", but also "can Skript interpret a response from a webpage as executable code, and then execute it?" and "Will this block Minecraft from behaving properly?" or "What can and cannot be done this way?"

I believe its possible, just not w/minehuts version of it.

Can Skript be obfusicated so that it's difficult to read or understand? Not just to secure the server-side code that would be delivered via API, but also the client-side code that is responsible for requesting the code from the server with a valid license. If so, it would combat dumping attempts, and make it harder for lesser skilled leakers to leak paid-for skripts without leaving some sort of tracing code that can be used to identify those responsible for leaking.

due to skript being a language that relies on indentation to work, I don't think its possible, there are some skript obfuscators, but its really easy to read and you can tell what they added to make it harder to read. The only way it would work is if skript allowed you to replace the : with { and }, like this:

going from:

command /amongus:
    trigger:
        message "&cimposter is sus?"

to:

command /amongus {
    trigger{
        message "&cimposter is sus?"
    }
}

in which you can minify like so:

command /amongus{trigger{message "&cimposter is sus?"}}

Can an API tell the difference between a user trying to pretend to be a Minehut server running Skript trying to retrieve code and a malicious third party trying to simply dump the code to file?

Really can only see what it sends over, and the IP as well- maybe minehut could bundle in a secret when it goes to fetch the code..? Again, not sure if API fetching is even possible in minehut without janky methods like vixio and mongo db, although I believe skjade has pastebin (unless they removed it).

[drtshock]

Is it worth doing this much work to prevent leaking, when people that really want to leak will still get around all of the methods mentioned here? Like iGalaxy said, the code still needs to be available at runtime so it's available on the server. We're working to unlock the file manager and add custom plugins, these types of DRM would make that harder for us to do from what I've seen so far.

I understand the desire for DRM. I sell premium plugins on spigot that have all been leaked. In my experience, legit buyers will still purchase it, and leakers will still leak no matter the effort you put into DRM. Though I'm happy to to continue the discussion to see if there are any methods that might be worthwhile.

[quick007]

Honestly there literally just skripts, many of them low quality, if content creators want to secure their work, maybe allow them to do it themselves, but it could just become a hassle for minehut. I would still love to see minification on skript though tbh.

[malloryhayr]

Even if you find a way to add DRM to scripts, what about other Market content such as worlds?

[ghost]

Is it worth doing this much work to prevent leaking, when people that really want to leak will still get around all of the methods mentioned here? Like iGalaxy said, the code still needs to be available at runtime so it's available on the server. We're working to unlock the file manager and add custom plugins, these types of DRM would make that harder for us to do from what I've seen so far.

I understand the desire for DRM. I sell premium plugins on spigot that have all been leaked. In my experience, legit buyers will still purchase it, and leakers will still leak no matter the effort you put into DRM. Though I'm happy to to continue the discussion to see if there are any methods that might be worthwhile.

Yeah, your items will still be leaked no matter what you do to protect them.

[malloryhayr]

A few more things -
Skript is not able to be obfuscated. Skript relies on specific word-for-word syntax from addons.
At this moment, I don't think it's possible to execute Skript scripts at runtime.

[quick007]

Skript is not able to be obfuscated. Skript relies on specific word-for-word syntax from addons.

there are some obfuscators, but there bad bc they just add in random local variables

[Blocksnmore]

There's also ones in stuff like skrayfall but they've already been bypassed

[ahoulton]

Not sure if I'm being dumb but, using Skript options; could you hide the code that isn't indented in (outside of the options indent)?

Then again, this depends on if the market creator enables it for that file.

[drtshock]

Not sure if I'm being dumb but, using Skript options; could you hide the code that isn't indented in (outside of the options indent)?

Then again, this depends on if the market creator enables it for that file.

That would be easy to bypass with custom plugins though.

[ahoulton]

Not sure if I'm being dumb but, using Skript options; could you hide the code that isn't indented in (outside of the options indent)?
Then again, this depends on if the market creator enables it for that file.

That would be easy to bypass with custom plugins though.

Talking about now, without custom plugins. The truth is, we will never be able to protect market content with custom plugins, so what can we do?

[Shigbeard]

I guess ultimately if we want to add DRM to Skripts, at that point the files shouldn't be Skripts as it's much easier to create a DRM workflow for JARs. Minehut could even develop a specialized workflow for adding JARs that are custom built by a DRM service to include embedded license information etc. But @drtshock is both right and wrong. Yes, leakers are everywhere, and no matter how much work you put into stopping them they will still get around it from time to time.

But the more work you put into it, the less likely they will successfully leak. When I was selling a discord relay for gmod, I added a basic license verification drm to the addon. Basically all it did was pull like 3 lines of a chat hook from the DRM service. Without it, wouldn't function. One day I was browing a popular leak forum and found my addon leaked. The idiot didn't even remove the license verification, even though it would have taken someone like 5 seconds to replace the hook without the DRM. From that i could identify the culprit, terminate his license, report his account to the store admins who then blocked him from buying any future addons.

Again, it's a matter of how much effort you want to put in vs how much effort the leakers will put in.

[IWolfZ]

Im saying like why cant they just make it so its something like how where you couldnt be able to edit serverprop.ymls but in skript folders

[ghost]

Im saying like why cant they just make it so its something like how where you couldnt be able to edit serverprop.ymls but in skript folders

Trent already said:

Like iGalaxy said, the code still needs to be available at runtime so it's available on the server. We're working to unlock the file manager and add custom plugins, these types of DRM would make that harder for us to do from what I've seen so far.

I don't think this is possible at this moment.

[ExtraSmartMiner]

This would be very nice to add to skripts, you would just have 2 skript files, 1 for the file (Locked) and 1 for the config (Unlocked).
This would allow someone to only view the config and not be able to steal the skript.

[CoreyShupe]

This breaks down with custom plugins. I know you can jar a skript and heavily encrypt it from my experience with skript. Maybe this will become an option. I'll have to look into if skript still supports this though.

[ExtraSmartMiner]

Like if the maker could make a skript/plugin file look like a locked file such as "server.jar" or "server.properties" so that it cannot be viewed

[CoreyShupe]

Like if the maker could make a skript/plugin file look like a locked file such as "server.jar" or "server.properties" so that it cannot be viewed

But when custom plugins are released it could just be downloaded via a plugin

[BennyDoesStuff]

There was quite a long conversation that happened on this issue. I'm going to be closing this as a result of the recent file manager and custom plugins update we released. It's not going to be possible to start restricting access to market material on someone's server as there will be too many ways to bypass it. People now have full access to their server, it's not a viable option to try to limit that for a specific file.

If you have any different ideas on how to potentially stop the leakage of market material, feel free to make a new issue and suggest your ideas.