Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 22 Jul 2012 06:40 PM |
My game is once again full of exploiters. I want a GOOD solution people. Not one that is easy to get around.
And before you ask, no, I am not going to connect to Workspace.DescendantAdded and other places to remove Scripts. My game is such that to do so is unfeasible and my game wouldn't be half as fun. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 06:41 PM |
Oh god no...
Wait, do you mean they've found a way around it or that SelectionChanged doesn't do anything?
~ Do you want fries with that? ~ |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 22 Jul 2012 06:49 PM |
| All I know is a bunch of script kiddies are exploiting my game again. And I want to know an effective means of thwarting them. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 06:52 PM |
Are you sure it's not your script that isn't working?
~ Do you want fries with that? ~ |
|
|
| Report Abuse |
|
|
belial52
|
  |
| Joined: 10 Oct 2009 |
| Total Posts: 8074 |
|
|
| 22 Jul 2012 07:06 PM |
| It is still working, what it is, is that they are getting around crashes. The way they are doing this is by changing a setting in studio. The only way to fix it is to put settings().Diagnostics.InstanceCountLimit = 0 into a core script of roblox. Changing InstanceCountLimit to a large multiple of 2 makes crash scripts ineffective. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:11 PM |
^
Thanks for telling even more people how to get around this. -_- |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:24 PM |
@techboy6601
The right thing to do is to find a solution to this, not to hide it from them hoping they won't discover it.
@Seranok
If I was you, well, I guess I would just wait. The devs are working on many fixes for exploiting.
I know what you're going to tell me.. Your game is very popular and waiting isn't that much of an option, but... you see...
One of the best ways to prevent exploiting is to prevent usage of features that your game itself doesn't need. For example, if your game doesn't ever need to change the TimeOfDay, you could decide to crash the game every time the TimeOfDay is changed because, if it's changed, that obviously means someone has exploited.
The problem with your game is that it allows all gear. And that means there's pretty much nothing you can restrict usage of, except things like the Selection, precisely, which is obviously not used by any gear since its methods are locked anyway.
---
What is happening can happen:
- because they're preventing LocalScripts from running using the ScriptContext; this can be fixed with a ping-like system. - because they're making the SelectionChanged event not fire, by modifying their client; there is no solution to this. - because they are preventing their client from crashing; this can be fixed by using another method of getting rid of them than trying to crash their client.
The first one is easy to fix, the second one is completely impossible to fix...
And the third one can be fixed by using another method to get rid of them.
Of course, just kicking them won't be enough.
There is a glitch that Sorcus said would be fixed but that will probably remain long enough for the devs to get rid of these exploits. It is to make a StringValue (though it also works with Scripts, and probably with other objects too) with a very long string as its value replicate to their client. I forgot the exact length, but this should work:
Instance.new('StringValue', player.PlayerGui).Value = ("a"):rep(1e5)
It will disconnect them from the game. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:29 PM |
@julien
Sorry, I didn't know there was a solution to this. I just didn't want this going mainstream and having a bunch of scriptkiddies undermine anti-exploit scripts. |
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 22 Jul 2012 07:33 PM |
@JulienDethurens
The upper limit on strings is 2e5. However, you first have to determine who is in fact an exploiter before you can kick them from the game.
You are right. Checking for things that shouldn't change is an effective way of determining if someone exploited. However there are problems with it.
1. I don't know who did it. Do I really want to shutdown the whole server just because someone inserted a foreign object into Lighting? 2. ROBLOX-made Gear do a lot of strange things. Believe it or not, there are gear that change TimeOfDay.
So what preventative measures may work for every other game on ROBLOX won't work on mine. What I need is a good method for detecting WHO exploited. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:38 PM |
Even with belial's method, SelectionChanged still runs, doesn't it? It just doesn't crash. So replace the crash code with the one Julien gave you and see what happens.
|
|
|
| Report Abuse |
|
|
Seranok
|
  |
| Joined: 12 Dec 2009 |
| Total Posts: 11083 |
|
|
| 22 Jul 2012 07:39 PM |
> SelectionChanged still fires
Yes, but since there are no LocalScripts connecting to the event nothing will happen. Doesn't matter how good your crash code is if it never fires. |
|
|
| Report Abuse |
|
|
| |
|
|
| 22 Jul 2012 07:44 PM |
"However, you first have to determine who is in fact an exploiter before you can kick them from the game."
You can do that, with the SelectionChanged event and with some other events which should usually never run except if someone is exploiting.
"I don't know who did it. Do I really want to shutdown the whole server just because someone inserted a foreign object into Lighting?"
Yes, you do. If someone exploited, the game is probably doomed anyway, so you might as well shut-down it. Then, the exploiters will realize they can't do anything because it keeps shut-downing, so they'll leave.
"ROBLOX-made Gear do a lot of strange things. Believe it or not, there are gear that change TimeOfDay."
That's what I said.
Read again:
"The problem with your game is that it allows all gear. And that means there's pretty much nothing you can restrict usage of, except things like the Selection, precisely, which is obviously not used by any gear since its methods are locked anyway."
I know there are gear that change the TimeOfDay. There is even a gear which renames your Camera, though I forgot which and though I have no idea why it does that.
"So what preventative measures may work for every other game on ROBLOX won't work on mine. What I need is a good method for detecting WHO exploited."
Meh...
Look through all the events, get a list of those which should never fire or those which should never fire with certain arguments (for example, the Changed event should never fire with a locked property's name as its argument unless someone is exploiting). If any of these fire, or fire with certain arguments, then shutdown the game. In some cases, like in the case of the selection, since the selection is a local service, you can even identify who is exploiting.
|
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:45 PM |
"Yes, but since there are no LocalScripts connecting to the event nothing will happen. Doesn't matter how good your crash code is if it never fires."
LocalScripts CAN connect to it. According to belial, what they're doing is changing a setting so you can't crash their client. They're not preventing your LocalScripts from connecting to it. |
|
|
| Report Abuse |
|
|
belial52
|
  |
| Joined: 10 Oct 2009 |
| Total Posts: 8074 |
|
|
| 22 Jul 2012 07:46 PM |
| @Julien, They aren't using ScriptContext is the thing, they are using the method I just explained. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:49 PM |
@belial52
I know that. Say it to Seranok, not to me! |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:51 PM |
| I don't get it. How can you use ScriptContext if it's locked? Is it possible to get the command bar using the exploit? |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:53 PM |
Wait...
Isn't ScriptContext.ScriptsDisabled unlocked?
Was it locked recently or something? |
|
|
| Report Abuse |
|
|
LocalChum
|
  |
| Joined: 04 Mar 2011 |
| Total Posts: 6906 |
|
| |
|
belial52
|
  |
| Joined: 10 Oct 2009 |
| Total Posts: 8074 |
|
|
| 22 Jul 2012 07:55 PM |
| @Julien, Without an edited RMD how would you change it? And I'm pretty sure it's RobloxLocked, but I can't gurantee that. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 07:57 PM |
http://wiki.roblox.com/index.php/ScriptsDisabled_(Property)
From the page:
Protected:This item is protected. Attempting to use it in a Script or LocalScript will cause an error. |
|
|
| Report Abuse |
|
|
Luc599345
|
  |
| Joined: 25 Jul 2008 |
| Total Posts: 1169 |
|
|
| 22 Jul 2012 10:06 PM |
@everyone who asks for ScriptContext
lrn2asm |
|
|
| Report Abuse |
|
|
agent767
|
  |
| Joined: 03 Nov 2008 |
| Total Posts: 4181 |
|
|
| 22 Jul 2012 10:19 PM |
Exploiter used Placesteal! Placecreator is confused Placecreator used the SelectionChanged-event! It`s not very effective... Exploiter used Crash server! It`s super effective! Placecreator fainted. |
|
|
| Report Abuse |
|
|
|
| 22 Jul 2012 10:36 PM |
Placecreator whited out
Placecreator scurried to Scripters, protecting the exploited places from further harm. |
|
|
| Report Abuse |
|
|
SN0X
|
  |
| Joined: 24 Oct 2011 |
| Total Posts: 7277 |
|
|
| 23 Jul 2012 03:38 AM |
The 3 times this has been mentioned, 10000 people trample over the idea. But...
To detect if Roblox Studio is open, detect a window resize with ScreenGui's AbsoluteSize property.
It would jump in size. Not gradually resize as if you were resizing yourself.
~now let le flame war begin~ |
|
|
| Report Abuse |
|
|