|
| 22 Mar 2012 08:52 PM |
A bunch of places are doing this as part of some ill-conceived copy protection scheme.
Bytecode is not compatible across Lua versions. When we update from 5.1 to 5.2, any place loading persisted bytecode will break.
If we had realized earlier than loadstring allows bytecode to be loaded, we would have intentionally blocked that functionality. It is very poor library design on behalf of the Lua guys. We may explicitly disallow this in the future. |
|
|
| Report Abuse |
|
|
| |
|
LocalChum
|
  |
| Joined: 04 Mar 2011 |
| Total Posts: 6906 |
|
|
| 22 Mar 2012 08:55 PM |
>You guys are upgrading to Lua 5.2
:O |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 08:58 PM |
All I have read: "Lua 5.2"
:OOOOOOOOOOOO |
|
|
| Report Abuse |
|
|
zerothree
|
  |
| Joined: 10 May 2009 |
| Total Posts: 25314 |
|
| |
|
|
| 22 Mar 2012 09:00 PM |
You're actually REALLY planning to update to Lua 5.2? Wait, you're kidding, right? You are REALLY even considering it at all? YAAAY!
If you're actually considering it, then you can't imagine how much that makes me happy. :D
As for bytecode, remove it. I don't need it, I don't want it and I don't use it anymore anyways. Its only real use was to protect code (which there are better ways to do anyways. This will actually force people to turn to better alternatives than precompiling their code to protect it, such as making it unreachable in the first place).
Everyone who has obfuscated something should have the source code, anyways, so these people would just need to replace the obfuscated code by the source code without changing anything, so fixing it doesn't require any effort. As for those who left and therefore can't do that, well, the stuff they made is probably outdated anyways, so it doesn't matter.
I'd totally be happy if you removed bytecode loading. It's removing a feature, but that feature was useless anyways. If it fixes an exploit too at the same time, then I'm totally happy. |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:00 PM |
Go right on ahead if it means that your upgrading :D
~The inner machinations of my mind are an enigma |
|
|
| Report Abuse |
|
|
Legend26
|
  |
| Joined: 08 Sep 2008 |
| Total Posts: 10586 |
|
|
| 22 Mar 2012 09:02 PM |
Except there always seems to be some magical way to exploit that we have to try and fight against until a fix is out. And then there's another... and another... and another...
I think most of us realize bytecode incompatibility with 5.2, but I don't think many of us expected roblox would update to 5.2. Stravant kept saying something about it being difficult to manage security contexts as you do now (weird stuff in the environment) and getfenv/setfenv were/are awesome :/ no matter how "hacky".
Any time ("in a few months" or "in a year or so" works fine as a reply) set to move to 5.2? Would be nice for some sort of heads up in that form. (Also please don't remove bytecode loading o_o) |
|
|
| Report Abuse |
|
|
MrNicNac
|
  |
| Joined: 29 Aug 2008 |
| Total Posts: 26567 |
|
|
| 22 Mar 2012 09:03 PM |
| To that extent, if anyone is using bytecode and not precompiled chunks, than they could just print it to get their source back. Nothing much. |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:09 PM |
| Can there be some sort of method of obfuscation implimented? It seems like place stealing is so common. |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:09 PM |
"To that extent, if anyone is using bytecode and not precompiled chunks, than they could just print it to get their source back. Nothing much."
Not if they precompiled it without leaving the chunk's name as the source, but, anyways, if they don't have the source code, that means they can't update the game without rewriting everything, and, therefore, their place is doomed anyways.
@Legend26
getfenv and setfenv aren't nearly as good as the environment concept in Lua 5.2. Instead of using getfenv and setfenv to edit the environment, you just do it by manipulating a table. Isn't that A LOT easier? |
|
|
| Report Abuse |
|
|
Legend26
|
  |
| Joined: 08 Sep 2008 |
| Total Posts: 10586 |
|
|
| 22 Mar 2012 09:12 PM |
No, it's not easier.
You can no longer do getfenv(ThisFunction) for instance and it's ambiguous enough to not tell me if _ENV means the environment of the calling function's global environment or the global environment in which it was created. |
|
|
| Report Abuse |
|
|
ENET
|
  |
| Joined: 01 Jan 2010 |
| Total Posts: 4820 |
|
|
| 22 Mar 2012 09:13 PM |
| what about for those of us who use bytecode to store functions in tables... string.dump.... |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:13 PM |
"Can there be some sort of method of obfuscation implimented? It seems like place stealing is so common."
Functions. Just put your code in a function and put that function in _G or in a BindableFunction.
Actually, here's what I suggest:
Every script in your game puts its code in a certain function that it puts in _G. Then, a certain script is used to run all of these.
You can't recover the source, as it won't be in the memory anymore. Yet, you can still run the code. :D
As for scripts that need to run many times, just replace them by a script that runs the appropriate function. |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:16 PM |
@Legend26
I personally consider getting the environment of a function from outside of itself as EXTREMLY bad practice.
A certain function might not expect this or that variable to suddenly change of value and might rely on the fact that only itself these, which is the case, the only exceptions being precisely getfenv and setfenv.
Beside, is there really a case where you would need to edit a function's environment from outside of itself? I myself never use setfenv and getfenv except when using functions that add variables to the environment of the function that called them, and I've recently stopped doing that because I already consider that as bad practice, even though it is actually editing the function from inside of itself. |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:17 PM |
"what about for those of us who use bytecode to store functions in tables... string.dump...."
I don't get it...
What do you mean by that? You don't need bytecode to put a function in a table.. |
|
|
| Report Abuse |
|
|
Ozzypig
|
  |
| Joined: 27 Mar 2008 |
| Total Posts: 4906 |
|
|
| 22 Mar 2012 09:18 PM |
OLOLL THEY ACTUALLY CARE IF THEY BREAK SOMETHING? What has gotten into them? You guys never cared before if you broke something (shall we mention _G or getmetatable?)
anyways....
It is bad to remove that functionality from Lua. They have a reason for having bytecode and a reason to let it be thrown into loadstring(). I don't think you should assume that just because you're upgrading that it means it is bad practice to do so. If it breaks some peoples' things, then that is their problem to fix.
If they obfuscated code and didn't keep the original copy, it's THEIR problem, not yours.
DON'T REMOVE BYTECODE-LOADING CAPABILITIES FROM LOADSTRING()!
Example of a real legit use of that kind of obfuscation: Anyways, obfuscation has its pros and cons, and if this is one of the cons, so be it. If you really obfuscate your code, you should always have a non-obfuscated copy with it. I have a special button in studio that obfuscates all code in the game. I always upload the obfuscated copy and keep the original for editing.
...Though it is good that you're going to 5.2. Yay!!! |
|
|
| Report Abuse |
|
|
Ozzypig
|
  |
| Joined: 27 Mar 2008 |
| Total Posts: 4906 |
|
|
| 22 Mar 2012 09:22 PM |
(Post by response version of what I said above)
"A bunch of places are doing this as part of some ill-conceived copy protection scheme." Actually, it's a relatively convenient and nice way of obfuscating code. Keeps the jareds from copying your place *and editing it*.
"Bytecode is not compatible across Lua versions. When we update from 5.1 to 5.2, any place loading persisted bytecode will break." True, but if it does break, it's everyone elses' fault, not yours. People need to KEEP the code they obfuscate, otherwise it's like deleting the source because you have a binary. It doesn't make sense, so is it really your problem?
"If we had realized earlier than loadstring allows bytecode to be loaded, we would have intentionally blocked that functionality." WHY???
"It is very poor library design on behalf of the Lua guys." 1) Lua version changes 2) "LET'S KEEP THE SAME BYTECODE!" 3) Oh no, now we can't add more detail to the bytecode. 4) We want to be able to add more detail 5) Let's change the bytecode.
"We may explicitly disallow this in the future." WHY??? It'll just turn out the same from other disabled features that have caused everyone woe and despair! :( |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:24 PM |
"They have a reason for having bytecode and a reason to let it be thrown into loadstring()."
In normal Lua, there are many case where you'd want a such feature. In ROBLOX Lua, there isn't a single case where there is no better alternative than using bytecode. ROBLOX Lua doesn't need bytecode.
"DON'T REMOVE BYTECODE-LOADING CAPABILITIES FROM LOADSTRING()!"
What, you'd prefer them spending time and effort on rewriting most of the Lua VM?
I'd prefer them removing a feature we don't even need and that just clogs up ROBLOX Lua and at the same time fix serious exploits that actually allow people to use locked functions in server code.
As for obfuscating, I've already pointed out many ways to protect your code that work far better than obfuscating, as they don't require you to keep two copies or anything.
The way it is done is simple. In all of these cases, you just use functions. Scripts require you to keep the source code to be ran, but functions can be ran even if the source code isn't there. They just need to be ran by another script, and therefore, need to be put in a BindableFunction or in a global table, such as _G or shared.
You don't need two copies of it. When the server runs, and before any player even got the time to connect to the place, the function is stored somewhere reachable by all scripts and the source code is destroyed. Therefore, when the player first loads the place, the source code is already gone. |
|
|
| Report Abuse |
|
|
Ozzypig
|
  |
| Joined: 27 Mar 2008 |
| Total Posts: 4906 |
|
|
| 22 Mar 2012 09:28 PM |
And a response to an earlier post:
"As for bytecode, remove it. I don't need it, I don't want it and I don't use it anymore anyways." Just because you don't, means everyone else doesn't? Ahem, we exist.
"Its only real use was to protect code (which there are better ways to do anyways. This will actually force people to turn to better alternatives than precompiling their code to protect it, such as making it unreachable in the first place)." Who said that was the only use? The problem is that we can't guarantee that it is unreachable in the first place, but precompilation adds in a nice hump (a crossable hump or not).
"Everyone who has obfuscated something should have the source code, anyways, so these people would just need to replace the obfuscated code by the source code without changing anything, so fixing it doesn't require any effort." Maybe so, but those some people might not want to replace it with the source code for other reasons.
"As for those who left and therefore can't do that, well, the stuff they made is probably outdated anyways, so it doesn't matter." Then this is OK?: "Crossroads is outdated, so it doesn't matter!" Anyways, the only people who cannot do that is those who don't have the original source code to re-compile into 5.2 bytecode, which that is no big deal. Removing the bytecode-loadstring-ing (?) would make that all sadfaic :(
"I'd totally be happy if you removed bytecode loading." You ~= Everyone
"It's removing a feature, but that feature was useless anyways." No, it wasn't.
"If it fixes an exploit too at the same time, then I'm totally happy." It doesn't fix an exploit at the same time, so don't be happy about it! |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:31 PM |
"WHY??? It'll just turn out the same from other disabled features that have caused everyone woe and despair! :("
Actually, if you're talking about locking the Source property and changing the way _G works, then I actually agree with these updates. When you think about it, you realize the admins have actually done a logical choice in both of these cases. I prefer _G working as a global table that every script can access rather than scripts being able to use it to make variables magically and randomly appear in my scripts's environments. The point is, in my opinion, scripts should be isolated, just like functions. You shouldn't be able to change the behaviour of a script from outside of itself in any way. In fact, I'd almost say they should remove the Disabled property so you can't disable a script from outside of itself, because, after all, a script might not expected to be randomly forced to stop running, which could result in it having to stop doing something in the middle of doing it. Scripts usually expect to run from the start to the end, not to be randomly stopped.
As for the Source property, well, again, I think scripts should be isolated. Beside, why would you want to edit the game's code at runtime? You're not supposed to edit the code at runtime!
And, if you think about it, did the change in the behavior of _G, the removal of the Source property make it harder for us to create good games? Not really. And will the removal of bytecode loading make it harder? Neither. It will just make us unable to obfuscate code using compilation of it, but there are better ways to protect your code anyways. |
|
|
| Report Abuse |
|
|
Ozzypig
|
  |
| Joined: 27 Mar 2008 |
| Total Posts: 4906 |
|
|
| 22 Mar 2012 09:34 PM |
"In normal Lua, there are many case where you'd want a such feature. In ROBLOX Lua, there isn't a single case where there is no better alternative than using bytecode. ROBLOX Lua doesn't need bytecode." ROBLOX Lua doesn't *need* metatables either, so let's remove them too. That's not a good reason to remove it.
"there isn't a single case where there is no better alternative than using bytecode" Yes, place obfuscation so possible thieves cannot edit the code. That's one legitimate use, explained in an earlier post.
"DON'T REMOVE BYTECODE-LOADING CAPABILITIES FROM LOADSTRING()!"
"What, you'd prefer them spending time and effort on rewriting most of the Lua VM?" No, I'd like them to not spend time on removing something that shouldn't be removed in 5.2! They don't need to support 5.1 bytecode (that comes with updates, outdated final products), but they do need to support 5.2 bytecode.
"I'd prefer them removing a feature we don't even need and that just clogs up ROBLOX Lua and at the same time fix serious exploits that actually allow people to use locked functions in server code." ROBLOX Lua, clogged? Funny, but loadstring() doesn't cause exploits. It returns a function which as to be ran in the current thread of execution, which is still under security limitations.
"As for obfuscating, I've already pointed out many ways to protect your code that work far better than obfuscating, as they don't require you to keep two copies or anything." Oh really? Name five, and make 'em good. I'd like to hear them.
"The way it is done is simple. In all of these cases, you just use functions. Scripts require you to keep the source code to be ran, but functions can be ran even if the source code isn't there. They just need to be ran by another script, and therefore, need to be put in a BindableFunction or in a global table, such as _G or shared." That may be true and possible, but the original source code has to be there. It's either source code or bytecode. It's also a ridiculous workaround and you're using BindableFunctions for something that they shouldn't be used for.
"You don't need two copies of it. When the server runs, and before any player even got the time to connect to the place, the function is stored somewhere reachable by all scripts and the source code is destroyed. Therefore, when the player first loads the place, the source code is already gone." The source code won't even be there if you used bytecode. And really, is it that hard to have two copies of a place, a production version and a final version? |
|
|
| Report Abuse |
|
|
|
| 22 Mar 2012 09:35 PM |
"Just because you don't, means everyone else doesn't? Ahem, we exist."
In that specific sentence, I was talking about myself and my own position and opinion about it.
"Who said that was the only use?"
I said it was the only real use. Of course, you can use it for a few other things, but the thing it is by far the most used for is obfuscating code.
"Maybe so, but those some people might not want to replace it with the source code for other reasons."
Such as? The only reason I could see is obfuscating...
"You ~= Everyone"
That's why I said that _I_ would be happy if it was removed, and not that everyone would be happy if it was removed.
"No, it wasn't."
Well, there are better alternatives for anything you'd ever want to do with it.
"It doesn't fix an exploit at the same time, so don't be happy about it!"
It does... There are some exploits related to bytecode loading and there are two ways to fix these:
- Remove bytecode loading. - Rewrite most of the Lua VM.
Since the second option is ridiculous, we are left with two choices:
- Remove bytecode loading. - Ignore the exploits (everyone can use any locked function). |
|
|
| Report Abuse |
|
|
Legend26
|
  |
| Joined: 08 Sep 2008 |
| Total Posts: 10586 |
|
|
| 22 Mar 2012 09:37 PM |
@Julien,
Loading a custom library without relying on the loader to pass the correct arguments for one, sandboxing certain functions for another.
Also, "need" is opinionated. I use obfuscation to protect certain models from tampering (an "admin" thing for a group). It wouldn't be exactly the best thing ever for anyone to be able to change it and make it their own for another group.
You're thinking from your own point of view, be open minded for once.
You want them to remove the Disabled property? You really are insane. Have you ever even used it? It has its uses and wouldn't fix anything as they can still easily be disabled and reenabled by cloning and then destroying the old one. If you want them to change that too, you're an idiot. Not all of us want to have all the scripts roblox puts in a character when the spawn and some want our custom versions. The health bar for instance, or animate script, or the health regenerator. |
|
|
| Report Abuse |
|
|
Ozzypig
|
  |
| Joined: 27 Mar 2008 |
| Total Posts: 4906 |
|
|
| 22 Mar 2012 09:41 PM |
"Actually, if you're talking about locking the Source property and changing the way _G works, then I actually agree with these updates. When you think about it, you realize the admins have actually done a logical choice in both of these cases. I prefer _G working as a global table that every script can access rather than scripts being able to use it to make variables magically and randomly appear in my scripts's environments." True, but there was a lot of "playing around" with _G that was not documented well at all, and it did cause things to break.
"The point is, in my opinion, scripts should be isolated, just like functions. You shouldn't be able to change the behaviour of a script from outside of itself in any way." I agree that scripts should be isolated, but that's also design preference. You could have someone who firmly believes in using _G for what it was meant to be used for.
"In fact, I'd almost say they should remove the Disabled property so you can't disable a script from outside of itself, because, after all, a script might not expected to be randomly forced to stop running, which could result in it having to stop doing something in the middle of doing it." Now you're just crazy. A script should have to disable itself in the first place, but script should be able to disable/enable other scripts apart from itself. I teach against scripts doing self-disabling.
"Scripts usually expect to run from the start to the end, not to be randomly stopped." Usually the stopping isn't random and has a purpose, but again, I don't advise stopping a script that way.
"As for the Source property, well, again, I think scripts should be isolated. Beside, why would you want to edit the game's code at runtime? You're not supposed to edit the code at runtime!" Again, true for most cases, but there's points where you might want to execute a string as Lua code. For that we do have loadstring(), but .Source could be used for otherthings (ie, multiline output (a different story)).
"And, if you think about it, did the change in the behavior of _G, the removal of the Source property make it harder for us to create good games? Not really. And will the removal of bytecode loading make it harder? Neither. It will just make us unable to obfuscate code using compilation of it, but there are better ways to protect your code anyways." No, there's not a better way than not even having the source code of the game in the game itself. That obfuscation is useful, whether you use it or not. It matters if it is used, and it is.
I'd like to keep using loadstring() in the canon way it can be used. |
|
|
| Report Abuse |
|
|