51 replies to this topic

[Pharap]

theoriginalbit, on 21 May 2013 - 11:37 PM, said:

Pharap, on 21 May 2013 - 09:12 PM, said:

You'll be happy to know I just submitted a new version that might be faster, assuming an if statement and os.clock are faster than queue event and coroutine yielding.

Bug in the new version. The if statements are missing the () on os.clock.

*sigh* fixed (this is why I don't like rushing out edits every time someone points something out)

Grim Reaper, on 22 May 2013 - 01:30 AM, said:

On your newest version, although I may be mistaken, you never check to see if the path provided is a directory. Nothing wrong with your compiling code itself, but it could crash the program if someone messed up or was deliberately trying to break your code.

Just a suggestion, though.

I'll leave that for people to implement themselves. I can guarantee working code, I'm not going to guarantee error checking for many reasons including performance. Besides, the run program itself implements the minimal error checking required. The messages aren't very informative, but there's only two of them so it's not that bad.

[wilcomega]

i have looked into the code but it seems like it just decompiles it and then running it?
if thats the case you just made a program to make every program open source again

[Pinkishu]

wilcomega, on 28 May 2013 - 02:37 PM, said:

i have looked into the code but it seems like it just decompiles it and then running it?
if thats the case you just made a program to make every program open source again

imo it just loadstring's the bytecode
that loads all the function again but you dont get plaintext lua back

if someone knows their way around in lua bytecode compiling probably doesnt help much though

[Fenthis]

Well... this is bad. And I don't mean your code. Lua bytecode is NOT safe to load. I would consider this a bug in ComputerCraft, a server could easily be owned this way.

Random reference on this subject: http://lua-users.org...8/msg00487.html

[Symmetryc]

Fenthis, on 06 June 2013 - 03:18 PM, said:

Well... this is bad. And I don't mean your code. Lua bytecode is NOT safe to load. I would consider this a bug in ComputerCraft, a server could easily be owned this way.

Random reference on this subject: http://lua-users.org...8/msg00487.html

I don't think that Computercraft uses Lua 5.2 (I'm not entirely sure).

[Jarle212]

So native lua/java functions can not be dumped(fs, term.native, etc)

[Fenthis]

Symmetryc, on 06 June 2013 - 03:38 PM, said:

I don't think that Computercraft uses Lua 5.2 (I'm not entirely sure).

AFAIK it uses LuaJ, a java implementation of Lua. However, I can't find any indication that it's bytecode is any safer than the stock Lua. (It's not just 5.2 that has problems, all versions of the stock Lua does, there is just a proof of concept for 5.2).

[Symmetryc]

Fenthis, on 06 June 2013 - 05:51 PM, said:

Symmetryc, on 06 June 2013 - 03:38 PM, said:

I don't think that Computercraft uses Lua 5.2 (I'm not entirely sure).

AFAIK it uses LuaJ, a java implementation of Lua. However, I can't find any indication that it's bytecode is any safer than the stock Lua. (It's not just 5.2 that has problems, all versions of the stock Lua does, there is just a proof of concept for 5.2).

Oh, sorry, the link sort of implied that it was only in 5.2.

[Engineer]

However this tool is awesome, it is useless. :/

Lyqyd, on 20 May 2013 - 01:39 PM, said:

This is an interesting tool, but all programs for ComputerCraft posted to the forums need to be in plain Lua due to the rules regarding malicious code.

[Lyqyd]

Fenthis, on 06 June 2013 - 03:18 PM, said:

Well... this is bad. And I don't mean your code. Lua bytecode is NOT safe to load. I would consider this a bug in ComputerCraft, a server could easily be owned this way.

Random reference on this subject: http://lua-users.org...8/msg00487.html

That reference suggests that it wouldn't be a problem on ComputerCraft. If you can get an exploit to work, please message the developers, though! I'm sure they'd love to hear about it.

[ElvishJerricco]

Fenthis, on 06 June 2013 - 03:18 PM, said:

Well... this is bad. And I don't mean your code. Lua bytecode is NOT safe to load. I would consider this a bug in ComputerCraft, a server could easily be owned this way.

Random reference on this subject: http://lua-users.org...8/msg00487.html

I've been studying lua bytecode extensively for the past week to make an assembly language and rest assured, bytecode is not dangerous. What that page is referring to is some kind of code signing or verification, which default lua doesn't do, and CC certainly doesn't do. The bytecode language is actually very similar to lua. It's really just a reorganization of the language that's harder to code and difficult to manage (although the management part is fixed by using an assembly language with higher level features). There is no risk to running bytecode. It only has access to the same stuff a normal lua program has access to.

[Pharap]

Ok, just checking up on this topic and I would like to make a few things clear.
Firstly, the purpose of compiling to bytecode in this case is not the same as with most compiled languages.
The idea is firstly to save memory (servers should be thankful for this, transferring bytecode instead of the sourcecode will provide all sorts of benefits) and secondly so that the Lua VM does not have to compile the program every time it runs. Compile once, run many more times as opposed to compile every time.

Elvish Jerricco speaks quite a bit of sense here.
I also have looked into Lua Bytecode, and I would like to debunk the idea that Lua bytecode is in anyway dangerous.
In itself, Lua bytecode is completely harmless. Any possible harm that could arise will be from any native calls made.
Even with that in mind, the worst someone could do is delete all files or swap out the start up file.
The former isn't rectifiable but the latter is. Beyond that, any computercraft lua code is completely harmless.

Jarle212, on 06 June 2013 - 03:53 PM, said:

So native lua/java functions can not be dumped(fs, term.native, etc)

No, because dumping a lua file only dumps lua bytecode, it can't dump Java bytecode. Lua runs in a virtual machine that runs on top of the Java VM. Native calls are just ways of interfacing with the Java functions that can provide functionality that Lua itself does not contain natively such as bit manipulation and file IO.

Pinkishu, on 28 May 2013 - 07:22 PM, said:

if someone knows their way around in lua bytecode compiling probably doesnt help much though

The purpose of compiling is not obfuscation, that's just a side effect.

wilcomega, on 28 May 2013 - 02:37 PM, said:

i have looked into the code but it seems like it just decompiles it and then running it?
if thats the case you just made a program to make every program open source again

Wrong way around. This is a compiler and a runner. The compiler compiles source code to byte code. The runner runs the bytecode.
These things occur naturally when you use computercraft anyway, but by using these two programs you can reduce the size of programs because bytecode is smaller than sourcecode and you can cut out the stage before running a program where the VM has to compile a program every time before it's run.