Currently, the Changed event fires for property changes outside the context-level of any typical Script/LocalScript listening to them and also fires for unscriptable property changes that we cannot access, by default.
I personally believe that, with these properties being “untouchable” to us, that the changed signal should not fire for them.
This behavior leads to confusion among developers encountering this event for the first time, and also allows people to exploit this behavior maliciously, as it fires for property changes outside the context-level of any usual Script/LocalScript that so happens to listen to the event.
As of now, I have discovered that this event allows one to listen to the GuiService’s SelectedCoreObject property changing and gives the ability for malicious scripts to forcefully rejoin players for interacting with the CoreGuis at all.
Hello, Kampfkarren. What I was saying currently applies to just regular script access.
As of now, it still fires for out-of-context-level changes and just allows for some malicious scripter to put a script in their game that can be used to stop mobile players from leaving the game or stop people from even using the report feature at all. I do not understand what “hacking” has to do with this.
This has also caused issues in the past where EchoReaper had to say this:
This just serves nothing but to cause unnecessary confusion among new developers and allow malicious script developers to render Roblox’s “safety precautions” that usually prevent these things from happening, useless.
I can’t reproduce what you just said. SelectedCoreObject is not firing in a LocalScript Changed hook. Maybe it’s because I’m not using an Xbox controller?
However, I found that the GuiService.MenuIsOpen property can be abused the way you described.
Also, wait wut?!
I did this with an alt account present. Otherwise, I would’ve gotten a shutdown message upon reconnect.
Last I checked, it worked with the old menu. Also, this fires for many other changes that are usually out-of-reach for us script developers. The way it’s in right now opens the way for potentially malicious utilization. It just a matter of time before someone happens to find another way to spin this unintentional functionality around.
There are some legitimate uses for detect when the player is interacting with the CoreGui. For example, if you had a singleplayer game, you could pause the game while the menu is open, or you could muffle the music.
Of course, the feature is probably going to be removed in response to all the abuse. Oh well. That’s life.
Also, there’s an event called ItemChanged that’s under the DataModel. One could probably exploit this to a greater extent than Changed and could probably use this to detect changes done to Core instances by checking if indexing the Instance errors and then by checking the property name.
I think that Changed can expose information that can sort of be used maliciously, however, I personally do not think the information that can be exposed is particularly dangerous or anything. I think that the example for detecting the opening of the menu is definitely undesirable and can be used maliciously, but, again, personally I think that even then there’s not much of a danger.
Either way, I do agree with this change overall and think that it might be necessary to filter the Changed event a little more to prevent these types of things, as well as it just being sort of annoying to use pcall for certain things using Changed.
