37 replies to this topic

[Konlab]

For me os.unloadAPI worked.

[apemanzilla]

Konlab, on 21 May 2014 - 12:35 PM, said:

For me os.unloadAPI worked.

Not what I meant, I meant I couldn't remember if it unloaded the APIs globally or for the current environment only.

[Konlab]

Globally, naturally :-)
os.loadAPI loads the API globally
os.unloadAPI unloads the API globally

[logsys]

Konlab, on 21 May 2014 - 12:41 PM, said:

Globally, naturally :-)
os.loadAPI loads the API globally
os.unloadAPI unloads the API globally

The virus I found has to do with that, but it can't be bypassed after correctly triggered(log out and log in or chunk unloading should work to bypass). It also can prevent other computers from turning on even. So I guess, now that I am thinking, the virus I found will, probably, not be getting fix, just the vm crash, which disabled the bypass

[apemanzilla]

Konlab, on 21 May 2014 - 12:41 PM, said:

Globally, naturally :-)
os.loadAPI loads the API globally
os.unloadAPI unloads the API globally

Are you sure? By globally I mean across all function environments. Because, arguably, as long as any one environment has access to the unloaded functions and the current one has access to getfenv, setfenv, and pcall, you can always get access to the APIs again.

[Konlab]

If you unload an API that computer can't use that API to next API loading.
I don't know what is getfenv or setfenv, but as I know pcall() is a Lua function, and as I know you can't unload Lua's functions.

[apemanzilla]

Konlab, on 21 May 2014 - 01:02 PM, said:

If you unload an API that computer can't use that API to next API loading.
I don't know what is getfenv or setfenv, but as I know pcall() is a Lua function, and as I know you can't unload Lua's functions.

You're not understanding it. If you unload it for only that ENVIRONMENT, the coroutine or function cannot access it but others can. If you unload it GLOBALLY, NOTHING can access it.

To "unload" a function you can just set it to nil.

[Konlab]

One ENVIRONMENT is one terminal?

[apemanzilla]

Konlab, on 21 May 2014 - 01:11 PM, said:

One ENVIRONMENT is one terminal?

Absolutely not. On environment is one set of functions for a thread or function to use.

[Konlab]

Sorry, I thought Environment = Integrated Development Environment

[apemanzilla]

Konlab, on 21 May 2014 - 01:12 PM, said:

Sorry, I thought Environment = Integrated Development Environment

No, and even if it did it would still have nothing to do with a CC terminal.

[Konlab]

Then if you unload an API globally than you delte it?

[theoriginalbit]

apemanzilla, on 21 May 2014 - 12:49 PM, said:

-snip unload in env statements-

doesn't matter. run this code

print(getfenv(0)['fs']) --# bios.lua env
print(getfenv(1)['fs']) --# shell env
print(getfenv(2)['fs']) --# program env
getfenv(2)['fs'] = nil
print(getfenv(0)['fs'])
print(getfenv(1)['fs'])
print(getfenv(2)['fs'])

doesn't matter what env you nil it, whether its the bios env or the program env, its gone. why do you think that when newbies override a function like read the shell and/or bios gets effected?

Edited by theoriginalbit, 21 May 2014 - 01:17 PM.

[apemanzilla]

theoriginalbit, on 21 May 2014 - 01:16 PM, said:

apemanzilla, on 21 May 2014 - 12:49 PM, said:

-snip unload in env statements-

doesn't matter. run this code

print(getfenv(0)['fs']) --# bios.lua env
print(getfenv(1)['fs']) --# shell env
print(getfenv(2)['fs']) --# program env
getfenv(2)['fs'] = nil
print(getfenv(0)['fs'])
print(getfenv(1)['fs'])
print(getfenv(2)['fs'])

doesn't matter what env you nil it, whether its the bios env or the program env, its gone. why do you think that when newbies override a function like read the shell and/or bios gets effected?

I'd also want to point out that this should only happen because tables are passed via pointer. If you take a hard copy of the table, it should be safe from environment hacks like the above.

[ardera]

apemanzilla, on 21 May 2014 - 01:26 PM, said:

I'd also want to point out that this should only happen because tables are passed via pointer. If you take a hard copy of the table, it should be safe from environment hacks like the above.

Thats true, tables are passed byref, and it's good that they're passed like that. Any type of synced thing would require global environments otherwise, which CC doesn't like it seems. (Global table is "read-only" (rawset!), has a protected metatable, every program modifies it's own environment instead of _G, and the environment has _G as an index)

As the "developer" said this program is for cc noobs: People are using CC because they want to program. Not because they want stuff to delete their virusses, or because they want to watch their OS doin' nothing (many OSes have the same usefulness as this program)

[apemanzilla]

ardera, on 21 May 2014 - 01:47 PM, said:

apemanzilla, on 21 May 2014 - 01:26 PM, said:

I'd also want to point out that this should only happen because tables are passed via pointer. If you take a hard copy of the table, it should be safe from environment hacks like the above.

Thats true, tables are passed byref, and it's good that they're passed like that. Any type of synced thing would require global environments otherwise, which CC doesn't like it seems. (Global table is "read-only" (rawset!), has a protected metatable, every program modifies it's own environment instead of _G, and the environment has _G as an index)

As the "developer" said this program is for cc noobs: People are using CC because they want to program. Not because they want stuff to delete their virusses, or because they want to watch their OS doin' nothing (many OSes have the same usefulness as this program)

And the functionality of this program can be recreated with five key presses in CraftOS anyways.

[logsys]

Being that way, I will change the home screen to say a possibility instead of downloading all of this, after that, I might as to lock this thread.

[Cranium]

Locked upon request.
For future reference, logsys, please use the report option on your topic, instead of PM'ing a moderator.