You could also use something like this:
3 Likes
What you could do is after the server has setup its scripts, you could duplicate into every single instance in the workspace a script that would check if its your game, then cause some major problems. You could name all of them “Script” so the exploiter would have a hard time removing every one of them. However, this might be costly on performance.
1 Like
I have seen the work of place stealing in action before, It wasn’t me because its a disgusting act and theft of games should be instantly banned
The way they steal games doesn’t copy the scripts over, it is remotely the parts within the game. Now, the only way I’ve seen a prevention of an entire game getting stolen is introducing region areas to the game, e.g. (Courtyard Region, City Region etc) This prevents the entire game to load in at once and only to load if the local character is close or entering the region itself.
This however is something that is dangerous as players can travel the entire map gathering the parts they need, which is why I had came up with the idea that if the player attempts to run a background script on the game that it would remove them, from my knowledge this has worked, how I’m not sure as I’m not a builder but it seems to have worked posting the username and the attempt on the Developer Console in game (linking it back to a discord server providing evidence that the user had attempted.)
I’m not sure how everyone would react to this, but thats how we’ve stopped the possible theft of a game.
4 Likes
Please no, it was already explained above why this solution would not work at all.
To reiterate, this would need to be in the server, since client doesn’t have access to loadstring, and local exploits can’t get a hold of server script code. Using a Lua VM as an alternative is just as silly since it just looks extra sketchy in a sea of normal scripts.
6 Likes
I honestly believe doing something like this is useless.
Exploiters can only steal Local Scripts and Module Scripts.
People who attempt publishing stolen place always get moderated, and them stealing the builds wouldn’t affect your game, as some of the big games have their games stolen by a lot of users and it doesn’t affect them one bit.
1 Like
Speaking about ModuleScripts, I reckon only ModuleScripts exposed to the client or required by a LocalScript can be stolen.
Other ModuleScripts are safe if placed in ServerScriptService or anything that hides the instance from the clients on server.
1 Like
Exactly, this is more reasoning that your request to make an anti-steal virus is useless. @KevinLuWX
The way I would do it is add many scripts in the parts / Models with Checking if its the same gameID. Then if not, send a message via webhook to discord with the Stolen Games Details.
EDIT: Writing a Script now and will add it here,
local GAMEID = 0
game.Players.PlayerAdded:Connect(function(plr)
if game.CreatorId ~= GAMEID and game.CreatorId ~= GAMEID and game.CreatorId ~= GAMEID then
local WebhookId = "WEBHOOKID"
local WebhookToken = "WEBHOOK TOKEN"
local webHook = require(game.ServerScriptService.WebhookAPI)
local ctime = os.date("!*t")
local wdays = {"Sunday";"Monday";"Tuesday";"Wednesday";"Thursday";"Friday";"Saturday"}
local Discord_Webhook = webHook.new(WebhookId,WebhookToken)
Discord_Webhook:post{
username = 'STOLEN GAME LOGS',
embeds = {
{
fields = {
{
name = 'Game Owner GROUP/USERID',
value = game.CreatorId
},
{
name = 'Player Joined',
value = plr.Name
},
{
name = 'Game Link',
value = "https://www.roblox.com/games/"..game.GameId.."/Unknown"
},
},
color = 16518199,
footer = {
text = "Credits to BillyH "..wdays[ctime.wday]..", "..ctime.day.."/"..ctime.month.."/"..ctime.year.." @ "..ctime.hour..":"..ctime.min..":"..ctime.sec.." UTC"
}
}
}
}
plr:Kick("[ANTI-THEIFT] YOUR NOT KEVINLUWX!")
end
end)
WEBHOOK SCRIPT
local webHook = {}
webHook.__index = webHook
local Http = game:GetService("HttpService")
function webHook.new(id,key)
local mt = setmetatable({id=id,key=key}, webHook)
return mt
end
function webHook:post(config,host)
local data = nil
local success = pcall(function()
data = Http:JSONEncode(config)
end)
if not success then
warn("Conversion error, please re-check your data.")
return
end
Http:PostAsync("https://discordapp.com/api/webhooks/"..self.id.."/"..self.key,data)
end
return webHook
2 Likes
I reckon Discord is not a logging service. Please reconsider using alternatives, stated in the post here:
You will risk in a zone of getting your account disabled for violating Discord’s Terms of Services.
3 Likes
It’s already been stated in the messages before that things like this will not work/run at all. LocalScripts don’t run inside of random models!
5 Likes
I think that the approach you’re taking is not a good one, and I feel that you should mark a solution to the thread and move on. This thread is attracting a lot of replies which, in the end, get you either nowhere or backwards. Here’s why:
Number 1: You cannot stop stealers
In any online game, certain information has to be sent to the client in order for it to construct something useful for the player to view. You can’t stop them taking this! They literally have a copy of it, in memory, on the client. They can do what they want on their machine, so they will. There is no foolproof way to stop them.
Number 2: The client is restrictive
From a stealer’s point of view, all they can see is what is delivered to them. They don’t have some magic connection to the server to get all instances there, so there stuck with everything client sided.
It just so also happens that, for security, the client is locked down in what it can do.
You are limited in what APIs you can use, wether you can use HTTP service to remotely connect etc. You are severely limited in what you can do. Along with this, even if you insert a script, it will only run on the client, making it possible for the actual game to still exist, even if the client crashes. Localscripts do not affect the server, nor anything on it (without severe security compromises).
So, the exploiter can only clone the client, your “virus” will only control the client, leaving it pathetically limited,
Number 3: Reliance on obscurity
Security by obscurity is always frowned upon, and this is a classic example.
When a stealer clones the place, they obtain a place file, that the can then use to access everything their client could see.
So much as a tiny investigation into your scripts will reveal what you tried to do, and allow them to remove it. Deleting one script is all it takes for them to bypass your entire system.
A few of the solutions have tried to hide the code using loadstring or script obfuscators. This is another classic example of security by obscurity. Apart from the fact that loadstring doesn’t even work on the client (refer back to point 2), a few seconds of investigation into what it does will render you fully “busted”, and get the code removed by the stealer.
I hope this summed up why this thread is not going to help, and as to why it should be closed now. I stated in another post that patchy or “band-aid” solutions, like this, rarely to never work. You’re trying to plug a river with toilet paper, and it’s just going to lead to wasted time and effort.
I suggest you move on now, and forget about trying to make this virus.
5 Likes
you do realize stealing a map can be very serious right? there’s games that have quite alot of their content in the map (showcases, obbies) so if they get stolen they do end up stealing a significant chunk of the game
i replied to real timothy but really this applies to everyone here
It’s an unavoidable fact of life when it comes to development of online games. If somebody copies your game, the proper course of action is to report and contact ROBLOX. I tried to reiterate, there is nothing you can do, regardless of how “serious” you find it.
I would actually disagree that it it is really serious. Games would be nothing without server sided scripts, and they cannot be stolen without a more advanced kind of exploit, pretty much never seen.
How is this different to simply, playing the game? What do they have to loose?
When you copy these raw objects, you loose scripts, thereby game mechanics, interactivity etc. Showcases are essentially showing off what you can do. If somebody steals it, it isn’t going to have a hugely obverse effect on your game itself. At most, the stealer can republish your game under themselves, without game mechanics and most of the entire game.
I’m sorry, but I completely disagree with what you’re saying, and still maintain that anti-steal measures are futile and pointless.
3 Likes
Yes, I do realize that stealing a map can be very serious. What I’m saying is there isn’t any REAL solution to prevent this; The map has to be sent to the client to be rendered. There’s no real workaround for this problem other than adding more than the map to a game; That way, if the map is stolen it isn’t as drastic.
2 Likes
This may be a little late but, what if you are popular but not as popular as jailbreak is people may be impressed by the other stolen map and go play the stolen map instead of the original than stuff will get dank.
2 Likes
Note: This is probably much more advanced than anyone wants but I thought I’d share anyway for those interested
In the event of a server side exploit or account breach (which has happened previously a few times, even with moderators’ accounts) I could see a use for including something like this.
There is a bug using packages which prevents the place from being saved or published. You’d need to do a manual file upload each time you update via the upload API. You can modify your place file in binary format to include a package link (under an obscure service) referencing an asset which isn’t a package (e.g. your actual place id). This causes the package system to have a fit and it prevents the game from being published or saved. The package always thinks it’s out of date thus prompting you to publish changes which is impossible. I haven’t tested this recently and it’s a bit hacky considering it’s a bug but it’s an idea I suppose.
Doing something script based would most likely involve checking the OwnerId of the place. You can possibly also load your game code from a DataStore if you’re really paranoid since DataStores are much harder to access in the event of some kind of server side exploit or attack (uncopylock based attacks are useless for example).
There are also other ways of storing information in your binary file but again, it requires manual publishing to work properly.
File based protection assumes the user somehow directly downloads the file (e.g. with a place hash, uncopylock, etc) and a lot of the time these types of protections are a pain to do yourself. (Automating the process with node or python is what I’d suggest if you end up doing anything file related. CloneTrooper1019 wrote an excellent C# API as well which I’ve used for several binary format experiments.)
Ideally if you implement file protections you’d want it to be loaded and saved but that makes them easier to find and these are generally less effective.
1 Like
There is no way you can prevent people from stealing your places. Its simply a waste of time. Anything on the client can be stolen. Sorry.
2 Likes
The concept is rubbish, but I love the idea of somebody stealing my game, and then hidden code recognizing that the place is stolen and slowly decreasing the framerate of the client until playing the stolen game is less responsive than the PC port of GTA IV.
4 Likes
I like this idea a lot more but sometimes people may steal the map without decompliers or they will just search for all LocalScripts and remove them, server sided scripts can’t be decomplied, at the end of the day I don’t mind anyone having my localscripts I just don’t want anyone having the hard work of mine.
5 Likes
It’s a good idea,
but to make it will be hard. And anyone can **delete ** it.
Soo can’t do anything.