Unusable mode

I have a sensitive computer that has a password system already on it, complete with os.pullEventRaw(). I want to have it become completely unusable until a repair disk is inserted. I have some ideas, such as

while true do
  os.pullEventRaw("disk")
  if fs.exists("disk/recover") then
	file=fs.open("disk/recover")
	local test=file.readAll()
	file.close()
	if code==test then
	  break
	  shell.run("disk/recover")
	end
  end
end

The code should wait for a disk to be inserted, check if its a recovery disk, compare the code on the disk to a variable containing sample code, and if it all checks out, recover the computer.
1. Is this the right way to use os.pullEventRaw()?
2. Would anyone still be able to get into the computer while os.pullEvent was waiting for a disk?

They can easily get into the computer by shutting it down, then inserting a disk of their own and starting it again.

To make programs non-terminatable, use

os.pullEvent = os.pullEventRaw

at the top of your program. Then you can just use the standard os.pullEvent , it won't make a difference. The way you have it, your program can be terminated.

awsmazinggenius, on 08 February 2014 - 12:03 PM said:

The way you have it, your program can be terminated.

Nah. Check the code again. The OP uses os.pullEventRaw. I repeat, OP, your program cannot be terminated in its current form. But as D3matt said, it could be broken by other means.

LBPHacker, on 08 February 2014 - 02:15 PM said:

awsmazinggenius, on 08 February 2014 - 12:03 PM said:

The way you have it, your program can be terminated.

Nah. Check the code again. The OP uses os.pullEventRaw. I repeat, OP, your program cannot be terminated in its current form. But as D3matt said, it could be broken by other means.

Most of the yielding commands in computercraft have an os.pullEvent() in them so he should really consider overriding os.pullEvent with os.pullEventRaw manually anyway.

6677, on 08 February 2014 - 02:42 PM said:

-snip-

Right. If he had a read("*") or something like that in there, I wouldn't have said anything. But he doesn't have one.

LBPHacker is correct in that, since this script never calls os.pullEvent() (neither directly nor otherwise), it's immune to Ctrl+T.

Ctrl+R can be used to straight up reboot it. If a disk with a "startup" script is inserted in the drive at that time, it'll boot from that instead of your own code. The only way to block that is to ensure no character gets access to the computer itself - you can't code around it.

Bomb Bloke, on 08 February 2014 - 07:23 PM said:

LBPHacker is correct in that, since this script never calls os.pullEvent() (neither directly nor otherwise), it's immune to Ctrl+T.

Ctrl+R can be used to straight up reboot it. If a disk with a "startup" script is inserted in the drive at that time, it'll boot from that instead of your own code. The only way to block that is to ensure no character gets access to the computer itself - you can't code around it.

LBPHacker, on 08 February 2014 - 04:02 PM said:

6677, on 08 February 2014 - 02:42 PM said:

-snip-

Right. If he had a read("*") or something like that in there, I wouldn't have said anything. But he doesn't have one.

But we dont know that the script he then proceeds to call himself doesnt use os.pullEvent and control-T behaviour may not be desirable in that.

Use a computer that you can break, terminate or kill as the password entry computer which just sends whatever the user typed in off to your actually well protected, user-unreachable control computer. That computer will receive everything and then issue appropriate door open commands. Even if they break the input computer, there is no chance of them getting to the control computer.

It is possible that they could try and get at the code that is in the input computer, however, you could have as part of your startup routine on the input computer a handshake with the control computer where the control computer sends a pseudo-randomized encryption key and all messages will be encrypted using that key. Then it take an incredibly determined user to spoof your computer, obtain a key, encrypt messages and send false messages. Your control computer would receive only encrypted messages after that, and decrypt them before attempting to process the passwords. Since no passwords are stored and no valuable information (other than the encryption algorithm) is stored on the input computer, you are fairly safe.

Again, there are plenty of coders here that could get around this, but it would take quite a bit of effort just to get to the point that we could send password attempts to the control computer. From there, we would still have to guess the password.

If you also sent a timestamp (or your handshake was fast enough to deal with mine craft HH:MM and you used the timestamp in generating the encrypted password along with the encryption key), you could easily make the encryption time sensitive, so even if encrypted passwords were intercepted, they would be useless (they are single use at that point).

You can go to as much trouble as you would like. No one is passing judgment on practicality here – we all build silly things just for fun.

6677, on 10 February 2014 - 02:42 PM said:

But we dont know that the script he then proceeds to call himself doesnt use os.pullEvent and control-T behaviour may not be desirable in that.

We don't, and why would he or anyone care? If the correct disk has been inserted, it dosen't matter if you can terminate it, since you'll have gained acess anyways.