Memory address of Roblox objects is leaked with table indexes

Bug Reports Studio Bugs
#1

Reproduction Steps
The easiest way to reproduce this is to index an RBXScriptSignal and then print it out as such

print{[game.Loaded] = true}

Expected Behavior
I’d imagine the memory location of the object (just like every other roblox object) would be hidden from users since it could possibly be exploited, since I dont see this being exploited outside of Studio, I haven’t tagged it as such

Actual Behavior
The memory location is leaked
image

Issue Area: Studio
Issue Type: Other
Impact: Low
Frequency: Constantly

10 Likes
#2

Turns out this affects all Roblox classes, not just RBXScriptSignal, I cant tell if this intentional or a bug, so I’ve reported it as such
image

4 Likes
#3

As far as I can tell, this is not the memory location of the RBXScriptSignal itself - rather the memory location of the EventInstance. Try printing this out multiple times - you’ll see different memory locations.

I can’t reproduce the print{[Vector3.new()] = true} behavior - for me, I get this:

image

3 Likes
#4

Interesting, I was able to reproduce the Vector issue. Not sure if this is 100% of the time since I just tested from one place file both in Studio and test mode.

image

Sounds related to 481 and the class changes.

3 Likes
#5

Not sure if I am behind, but isn’t native Vector3 still in beta? It was an opt-in beta feature, you may have opted into it

5 Likes
#6

Nope.
image
And as people have pointed out above - your results were different because you were probably opted into native Vector3 beta.

1 Like
#7

This also happens for tables and functions, and doesn’t work with if, in, and more.
image
image

#8

That’s a different test - I’m running print{[game.Loaded] = true}

#9

That’s intentional. Just printing out a table or a function or a raw userdata even without the expressive output does the same. Not sure why you tried with if and in – those are reserved keywords and are therefore not valid identifiers. That is not a bug.

#10

Wouldn’t that invoke the __index metamethod? And thus returning a new event instance? I can’t confirm this, but does =rawequal(game.Loaded, game.Loaded) print false?

#11

Yep - as far as I can tell, that’s exactly what’s going on.

#12

I tried them solely because I was very curious.

#13

Thats actually really annoying, I was using event instances to hook events between scripts but I guess since Roblox gives each new script signal its own object, it doesn’t work

Honestly, I dont get why this is a thing, and honestly should be changed in Luau down the road.

#14

The memory address “leaks” are most likely intentional. Roblox already readily exposes the addresses of tables and userdata* with a simple tostring, and the addresses of other objects are also easily exposed by firing remotes with said objects as table keys.

*User-created userdata

#15

I’m experiencing this as well. I’m trying to create a sort of hierarchy system but it’s hard to keep track when there is no indication of what the instance is. Would be kinda cool if there was a sort of “hyperlink” thing that happens when you try to print an instance.

Screen Shot 2021-06-11 at 11.25.22 PM
Screen Shot 2021-06-11 at 11.25.22 PM934×82 8.27 KB

Screen Shot 2021-06-11 at 11.24.09 PM
Screen Shot 2021-06-11 at 11.24.09 PM838×570 28.1 KB

#16

Memory addresses of objects are readily exposed just by the fact that they are objects loaded into memory.

Indexing an object, even normally, results in a need to load from memory into a register (assuming it is in a table/etc, only local variables stored in registers are exempt). This will not effect whether or not something can be exploited, I can assure you of that.

That being said, not sure if it printing like that is intended or not?

#17

This is a regression. The Expressive Output Window is not properly invoking tostring on userdatas. It used to do this, to my knowledge.