TKO | Root Method And Eventual SuperUser layer for O | Operating system

Hurry with the superuser access or O3 will beat you to turning O into a platform :P/>

You need to be more specific with the installer, due to people using different operating systems.

Change

os.run({},"/patcher")

To

os.run({},"/Patcher")

Edit: Thanks for updating it. :D/>

Update: Currently working on the superuser side of TKO. It will have an SUReq API call to request being able to call the other SU functions, such as writing to files and such. This will include the default edit program which i will personally modify the default API calls to block it from working without the user letting it. Version 1 will include some basic calls.

A root API? Good idea. Is this rooting also applicable for other OSes?

Creator, on 29 December 2015 - 09:05 PM said:

A root API? Good idea. Is this rooting also applicable for other OSes?

This exact program? no. Although if you want me to i can try to make a universal unlock tool for OS's? Honestly i can just have the user input the pastebin code for the OS instead of wrapping the O installer the entire time, that might work. Ill experiment and get back to you :D/>.

Feel free to destroy OmniOS! :P/> I have not abandoned it, just curious how resistant it is.

I will be opening up a sort of "beta" edition of TKO to those who want to see how its coming along. Click HERE to see the new SU program (not implemented into TKO yet, the basics of it are barely finished)

GREAT FIGHTING! YOU WON BY TKO!

PUSH START

I would recommend having TKO do minimal modification out of the box to O, and then what I would recommend is that you should integrate with O's PIN system.

So it would go like this:

Ask for user PIN > Hash input with salts (ask ProjectB for details) > Check against user's PIN > If PIN is correct, return a read-only version of the fs API that has root access.

And then if the user doesn't have a PIN I would recommend disabling superuser entirely (for security) or warning the user against it.

Just some thoughts, hopefully this is semi-useful to you.

cyanisaac, on 11 January 2016 - 03:04 AM said:

I would recommend having TKO do minimal modification out of the box to O, and then what I would recommend is that you should integrate with O's PIN system.

So it would go like this:

Ask for user PIN > Hash input with salts (ask ProjectB for details) > Check against user's PIN > If PIN is correct, return a read-only version of the fs API that has root access.

And then if the user doesn't have a PIN I would recommend disabling superuser entirely (for security) or warning the user against it.

Just some thoughts, hopefully this is semi-useful to you.

I'm making TKO completely independent from O eventually.The SU will have seperate passwords and all that will be done is have special variables added to O's startup to allow SU to give SU access, as well as have SU create a background coroutine that stops you from removing it without also wiping the variable backups to prevent full root without you specifically requesting full system root.

CloudNinja, on 11 January 2016 - 11:28 AM said:

cyanisaac, on 11 January 2016 - 03:04 AM said:

I would recommend having TKO do minimal modification out of the box to O, and then what I would recommend is that you should integrate with O's PIN system.

So it would go like this:

Ask for user PIN > Hash input with salts (ask ProjectB for details) > Check against user's PIN > If PIN is correct, return a read-only version of the fs API that has root access.

And then if the user doesn't have a PIN I would recommend disabling superuser entirely (for security) or warning the user against it.

Just some thoughts, hopefully this is semi-useful to you.

I'm making TKO completely independent from O eventually.The SU will have seperate passwords and all that will be done is have special variables added to O's startup to allow SU to give SU access, as well as have SU create a background coroutine that stops you from removing it without also wiping the variable backups to prevent full root without you specifically requesting full system root.

Hmm, okay. I don't know why TKO would be made independent from O, it sounds like you're making a new OS instead of a tool ;P.

as well as have SU create a background coroutine that stops you from removing it without also wiping the variable backups to prevent full root without you specifically requesting full system root.

That sounds like a bad idea. I'm not too familiar with how coroutines work (I've only used parallel), but definitely add in other layers of security like read-only tables (proxy tables) into your code. I feel like someone could figure out how to bypass something somehow, and then make changes before halting the system. This happened when I tried adding security to OTOS long ago - people could make changes before the background process could catch up to restore it.

cyanisaac, on 12 January 2016 - 05:56 PM said:

CloudNinja, on 11 January 2016 - 11:28 AM said:

cyanisaac, on 11 January 2016 - 03:04 AM said:

I would recommend having TKO do minimal modification out of the box to O, and then what I would recommend is that you should integrate with O's PIN system.

So it would go like this:

Ask for user PIN > Hash input with salts (ask ProjectB for details) > Check against user's PIN > If PIN is correct, return a read-only version of the fs API that has root access.

And then if the user doesn't have a PIN I would recommend disabling superuser entirely (for security) or warning the user against it.

Just some thoughts, hopefully this is semi-useful to you.

I'm making TKO completely independent from O eventually.The SU will have seperate passwords and all that will be done is have special variables added to O's startup to allow SU to give SU access, as well as have SU create a background coroutine that stops you from removing it without also wiping the variable backups to prevent full root without you specifically requesting full system root.

Hmm, okay. I don't know why TKO would be made independent from O, it sounds like you're making a new OS instead of a tool ;P.

as well as have SU create a background coroutine that stops you from removing it without also wiping the variable backups to prevent full root without you specifically requesting full system root.

That sounds like a bad idea. I'm not too familiar with how coroutines work (I've only used parallel), but definitely add in other layers of security like read-only tables (proxy tables) into your code. I feel like someone could figure out how to bypass something somehow, and then make changes before halting the system. This happened when I tried adding security to OTOS long ago - people could make changes before the background process could catch up to restore it.

You know how someone could bypass something somehow? Just look at my code and rebuild it. It isnt hard :P/>

TKO Is making a comeback everyone. I took a break from lua to learn python a little bit and im coming back to at least build a working version of TKO's SU binary