12 replies to this topic

[darkrising]

Hello, I'm trying to secure one of my programs from the dreaded [ctrl] + T.

It originally used pcall to stop [ctrl] + T on the read function however in the latest versions of computercraft pcall is not working as it used too.

I have tried to use os.pullEvent = os.pullEventRaw however my program is running in parallel so I get a "parallel: 22 Expected string" error.

I could write a coroutine function myself but I have little understanding (even after reading a tutorial) of how they work.

Any help is much appreciated

Edit: I also tried making a loop that listens for the [ctrl] key and shuts down straight away, but it proved to be very unreliable.


----------------------------------------------


The fix for this was quite simple.

• Declare os.pullEvent = os.pullEventRaw
  
• Make sure all your event driven loops check the event they are driven by!
  
• £££ Profit!

[Zudo]

I did this too, I have a script here:

Spoiler

local function create( first, ... )
if first ~= nil then
return coroutine.create(first), create( ... )
	end
	return nil
end

local function runUntilLimit( _routines, _limit )
	local count = #_routines
	local living = count

	local tFilters = {}
	local eventData = {}
	while true do
	 for n=1,count do
	 local r = _routines[n]
	 if r then
	 if tFilters[r] == nil or tFilters[r] == eventData[1] then
	local ok, param = coroutine.resume( r, unpack(eventData) )
if not ok then
error( param )
else
tFilters[r] = param
end
if coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 end
	 end
for n=1,count do
	 local r = _routines[n]
if r and coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 eventData = { os.pullEventRaw() }
	end
end

function waitForAny( ... )
	local routines = { create( ... ) }
	return runUntilLimit( routines, #routines - 1 )
end

function waitForAll( ... )
	local routines = { create( ... ) }
runUntilLimit( routines, 0 )
end

It is safe against ctrl-t and works the same as the original parallel api

[darkrising]

Thank you that looks promising, however something I noticed was by changing the order of the functions passed to the parallel api, [ctrl] + T doesn't have an effect.

I have no idea why.

Edit: Maybe not, on further testing I could not replicate the same outcome

[darkrising]

ZudoHackz, on 05 July 2013 - 11:40 AM, said:

I did this too, I have a script here:

Spoiler

local function create( first, ... )
if first ~= nil then
return coroutine.create(first), create( ... )
	end
	return nil
end

local function runUntilLimit( _routines, _limit )
	local count = #_routines
	local living = count

	local tFilters = {}
	local eventData = {}
	while true do
	 for n=1,count do
	 local r = _routines[n]
	 if r then
	 if tFilters[r] == nil or tFilters[r] == eventData[1] then
	local ok, param = coroutine.resume( r, unpack(eventData) )
if not ok then
error( param )
else
tFilters[r] = param
end
if coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 end
	 end
for n=1,count do
	 local r = _routines[n]
if r and coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 eventData = { os.pullEventRaw() }
	end
end

function waitForAny( ... )
	local routines = { create( ... ) }
	return runUntilLimit( routines, #routines - 1 )
end

function waitForAll( ... )
	local routines = { create( ... ) }
runUntilLimit( routines, 0 )
end

It is safe against ctrl-t and works the same as the original parallel api

Where does this differ from the parallel api?

[Lyqyd]

Please post your code.

[darkrising]

Lyqyd, on 05 July 2013 - 10:24 PM, said:

Please post your code.

https://raw.github.c...security/client

It's one of my base security programs, I used to use pcall but it seems to be the parallel api that is exiting.

[Zudo]

darkrising, on 05 July 2013 - 12:50 PM, said:

ZudoHackz, on 05 July 2013 - 11:40 AM, said:

I did this too, I have a script here:

Spoiler

local function create( first, ... )
if first ~= nil then
return coroutine.create(first), create( ... )
	end
	return nil
end

local function runUntilLimit( _routines, _limit )
	local count = #_routines
	local living = count

	local tFilters = {}
	local eventData = {}
	while true do
	 for n=1,count do
	 local r = _routines[n]
	 if r then
	 if tFilters[r] == nil or tFilters[r] == eventData[1] then
	local ok, param = coroutine.resume( r, unpack(eventData) )
if not ok then
error( param )
else
tFilters[r] = param
end
if coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 end
	 end
for n=1,count do
	 local r = _routines[n]
if r and coroutine.status( r ) == "dead" then
_routines[n] = nil
living = living - 1
if living <= _limit then
return n
end
end
end
	 eventData = { os.pullEventRaw() }
	end
end

function waitForAny( ... )
	local routines = { create( ... ) }
	return runUntilLimit( routines, #routines - 1 )
end

function waitForAll( ... )
	local routines = { create( ... ) }
runUntilLimit( routines, 0 )
end

It is safe against ctrl-t and works the same as the original parallel api

Where does this differ from the parallel api?

There is a line, I can't remember where, which was different. I think it waited for an event, and then checked to see if it was the correct event before terminating.

[theoriginalbit]

ZudoHackz, on 06 July 2013 - 10:27 AM, said:

There is a line, I can't remember where, which was different. I think it waited for an event, and then checked to see if it was the correct event before terminating.

Nope, looks identical to the parallel API to me!

[Zudo]

theoriginalbit, on 06 July 2013 - 10:39 AM, said:

ZudoHackz, on 06 July 2013 - 10:27 AM, said:

There is a line, I can't remember where, which was different. I think it waited for an event, and then checked to see if it was the correct event before terminating.

Nope, looks identical to the parallel API to me!

It works for me though!

[darkrising]

ZudoHackz, on 06 July 2013 - 11:32 AM, said:

-snip-

Doesn't work for me, on further testing it seems that it is only when the username and password loop + disk checking loop are running together the program can be [ctrl] + T however when both options are running by themselves the program seems to be quite secure.

I don't know why it is doing this.

[Lyqyd]

Line 54 allows it to terminate. When that function receives a terminate event, line 54 will throw an "expected string" error, since you aren't verifying that you're actually getting a disk event.

[Zudo]

Lyqyd, on 06 July 2013 - 02:49 PM, said:

Line 54 allows it to terminate. When that function receives a terminate event, line 54 will throw an "expected string" error, since you aren't verifying that you're actually getting a disk event.

That is weird, because it has always worked for me.

[darkrising]

Lyqyd, on 06 July 2013 - 02:49 PM, said:

Line 54 allows it to terminate. When that function receives a terminate event, line 54 will throw an "expected string" error, since you aren't verifying that you're actually getting a disk event.

Thank you very much, the problem is now solved. I didn't realize os.pullEventRaw responds to the terminate event aswell.

A short loop to check the event later and the probem has been solved.

Thank you to all that helped