Looking for Beta Testers for DRM

is there not the same leak in security as scriptenforcer? (so i can just search the files and go via browser to the link and copy the text that will be loaded?)

Injecting code/payload/anything into servers isn't the best idea, you're going high end scriptenforcer route rn. The automatic server listing n' shit is completely fine way better than manually doing it.

People don't care about DRMs if they're out of the way and risk-free, when you say shit like "It'll inject a payload/whatever into the server" it makes people say "Hey I don't want that shit on my server, so I'm not gonna buy your product" and you can't hide doing it either cause if someone finds out that you're secretly injecting shit into servers that have your DRM, it'll have a bad backlash.

And on a lower note of security concern, people might get really annoyed that they have to download and configure the script 3 times over if they have 3 servers so I'd recommend finding a system that would work with all their servers and only use 1 download.

Other than those two, everything seems fine.

Edited

btw, when I say injecting code I don't mean from the web hook I'm mainly talking about this:

ByPieCraftedat 26th of July 2017 04:25:05

IF SERVER IP AND LICENSE KEY DO NOT MATCH (see bottom of post) (leak): Function calls web server to obfuscate andinject payload into server for future tracking purposes (also makes you super admin if you enabled it on lumek.co)

when I was bolding the words up top, it's just a literal backdoor at that point, which isn't allowed.

ByJustPlayerat 26th of July 2017 04:38:56

is there not the same leak in security as scriptenforcer? (so i can just search the files and go via browser to the link and copy the text that will be loaded?)

Actually, this isn't possible. I have a couple of proprietary checks in place to verify the the request is in-fact being sent from a garry's mod server from within an unmodified copy of the obfuscated code.

ByLunaversity.xyz 🌸at 26th of July 2017 04:45:22

Injecting code/payload/anything into servers isn't the best idea, you're going high end scriptenforcer route rn. The automatic server listing n' shit is completely fine way better than manually doing it.People don't care about DRMs if they're out of the way and risk-free, when you say shit like "It'll inject a payload/whatever into the server" it makes people say "Hey I don't want that shit on my server, so I'm not gonna buy your product" and you can't hide doing it either cause if someone finds out that you're secretly injecting shit into servers that have your DRM, it'll have a bad backlash.And on a lower note of security concern, people might get really annoyed that they have to download and configure the script 3 times over if they have 3 servers so I'd recommend finding a system that would work with all their servers and only use 1 download.Other than those two, everything seems fine.Editedbtw, when I say injecting code I don't mean from theweb hookI'm mainly talking about this:when I was bolding the words up top, it's just a literal backdoor at that point, which isn't allowed.

You are 100% right regarding the "injection of a payload if check fails". I was a little iffy of it myself, but for whatever reason I felt that it would have been a good idea. I have now updated the code (and this post) to only observe and report when the check fails.

As for the "people might get really annoyed that they have to download and configure the script 3 times over if they have 3 servers", I feel as if I really only have 2 options here. The one I have chosen (1 download per server) severely reduces the chance of a leak because, if it was to be leaked, it would only work one time. Option 2 was generating one license key per user, and this would not effectively work for what I was trying to do with it. Say a customer is a "developer" for a server owner. The "dev" installs one of his scripts on the owners server, but then the owner bans him (and still has your code). I could revoke the dev's license key, but then the dev would never be able to use the script again. Also, if a leaker leaked their license key, everyone would have access to the complete, working addon in the time before I (or the content creator) figure out it was leaked and revoke it. I like to believe everyone is somewhat honest, so by implementing the multi-dl's per server, the dev from example one would still be able to use his script, and the server owner would be left with nothing.

That, and I feel that copy+pasting 1 config file a few times is far easier (and less time consuming) than forcing the customer to logon to lumek.co, link their server, generate a license key, and find out where the script author decided to place the function that calls Lumek.co to replace the license key.

If you have a better idea, I'd love to hear it <3

please stop

Trying to remain optimistic, so here's an idea.

Allow developers to have the config work through your site. It'll keep a cached version of it should your site ever go down, but allow users to change things through the site, and then it'll work across any servers of theirs. Could be an interesting feature that'll make your DRM stand out, and potentially give you greater control over leaks.

ByNookyavaat 26th of July 2017 22:10:14

Trying to remain optimistic, so here's an idea.Allow developers to have the config work through your site. It'll keep a cached version of it should your site ever go down, but allow users to change things through the site, and then it'll work across any servers of theirs. Could be an interesting feature that'll make your DRM stand out, and potentially give you greater control over leaks.

So the customer would go to the site and config his copy? Or am I being retarded?

If that's the case, I personally disagree with this. Imo, the best DRM is when the customer doesn't even know there's a DRM.

ByNookyavaat 26th of July 2017 22:10:14

Trying to remain optimistic, so here's an idea.Allow developers to have the config work through your site. It'll keep a cached version of it should your site ever go down, but allow users to change things through the site, and then it'll work across any servers of theirs. Could be an interesting feature that'll make your DRM stand out, and potentially give you greater control over leaks.

I can agree with this, but I (and maybe this is just me but idk) do agree with phrase "The best DRM is one the user never knows existed". Sure, you could say that this is not the case with my x downloads for x servers setup, but in the end, I would prefer not to have them need to logon to my website just to configure something. Integration should be seamless. To be honest, I am just getting all of my ideas for the DRM from the mountains of posts on this forum and fp saying why ScriptEnforcer sucked. The one I keep seeing mentioned over and over was the fact that users had to logon to SE to "activate" their servers. In my head, I think "Why have users activate their servers if their server can activate itself".

I do agree with a cache, but not in the way you explained it. I was thinking more along the lines of an epoch check, if the cache is over 3 days old, delete the cache. The cache would be refreshed every time it connects to lumek.co. My current issue with this is that clients could change the server time, rendering this useless, and would open the door to leakers.

ByOwain Owjoat 26th of July 2017 22:35:22

So the customer would go to the site and config his copy? Or am I being retarded?If that's the case, I personally disagree with this. Imo, the best DRM is when the customer doesn't even know there's a DRM.

I couldn't agree with you more.

EDIT: Also, as a reply to the very first post, along with what I said above, Lumek.co (unlike SE) obfuscates the developers code before it is sent to the client, and a check is preformed to make sure it is unmodified. If someone really wanted the source, they would have to crack 3 layers of obfuscation just to get to the code that actually makes the plugin run (which includes the lua for the server verifying the key with lumek.co, the server requesting a download of the developers code, and the developers code itself (which has a check injected into it aswell)).

This service seems completely useless compared to securegmod and will just be another shitty ScriptEnforcer

I would like to see some of ur obfuscated code to prove me wrong

Also user agent spoofing can literally be done with browser extensions

ByVELkonat 27th of July 2017 04:46:47

This service seems completely useless compared to securegmod and will just be another shitty ScriptEnforcerI would like to see some of ur obfuscated code to prove me wrongAlso user agent spoofing can literally be done with browser extensions

Isn't it your task to prove that it's as shitty as ScriptEnforcer? I mean these are serious accusations, you should really proof them.

-snip-

By𝐌𝐨𝐦𝐨𝐱 | MomoxStudios.Netat 27th of July 2017 12:45:54

Isn't it your task to prove that it's as shitty as ScriptEnforcer? I mean these are serious accusations, you should really proof them.

If his code turns addons into something better than this (securegmod) Then he won't be another shitty scriptenforcer. If it doesn't, then it won't be able to even compete with securegmod.

Also if it http fetches the code to load it then it's already shittier than securegmod, because securegmod only needs http for authentication.

Also if you want to see more then buy Trixter's Discord relay which is where this screenshot is from

ByVELkonat 28th of July 2017 00:24:39

words

Not until the leaker figures out whatever the decryption key is.

EDIT: Or pastes it into a base64 decoder.

Sure, want to bet for $20 you can't just "decode" securegmod? I'll give you access to the script and if you can't decode it with base64 decoder, i win?

ByPieCraftedat 28th of July 2017 13:30:27

Not until the leaker figures out whatever the decryption key is.EDIT:Or pastes it into a base64 decoder.

ByPieCraftedat 28th of July 2017 13:30:27

Not until the leaker figures out whatever the decryption key is.EDIT:Or pastes it into a base64 decoder.

And what protection do you have in place to make sure people don't grab the decryption key?

ByLingat 28th of July 2017 14:14:38

And what protection do you have in place to make sure people don't grab the decryption key?

@VELkon

ByPieCraftedat 28th of July 2017 14:21:06

@VELkon

No... I was talking to you

ByPieCraftedat 28th of July 2017 14:21:06

@VELkon

I didn't make securegmod but you can take trixters offer and find out for yourself. The man behind securegmod is meepen.

ByLingat 28th of July 2017 14:23:21

No...I was talking to you

Ahh, okay. My service doesn't use a decryption key, so that is why I assumed you were talking to the other guy. I refer you to my earlier posts if you would like to know how my obfuscation solution works.

EDIT: It uses a "Product Key" (think windows) to verify in the database that the user has access to the script in question and then it sends the serverside files to the customer. Obfuscated, of course.