CommuteOS, the Linux of ComputerCraft

CommuteOS and the Next Generation of Operating Systems

An idea for ComputerCraft Development.

By: Sledger721

 

 

 

 

        I have recently been anticipating the release of an OS called CommuteOS. Now, I know, I know, there's too many OS', and I've taken my own (fairly succesful) swing at it with RedWorks, but this one is different. It is massive, efficient, open-source, amazing, extensible, and made me think of Linux.

        One thing that caught my eye at first, was that it is completly developed by the community. That is an amazing feat for such a great program, but in this post I'm going to show off each piece of it and why they're so great.

        Piece #1: The Kernel. Most OS' don't have a kernel but embed this straight into the BIOS. In my opinion, the kernel is the way to go. It allows open-source system APIs. Also, the fact that it's so massive is astounding. It even contains built-in graphics commands, therefore simplifying the use and creation of graphics. I find this simply astounding.

        Piece #2: This is the only thing that I wasn't impressed with at all . . . The log-in security. Out of this entire, amazing piece of software, the log-in wasn't encrypted at all. Now, I see why it isn't with it's massive AV, but sometimes that just isn't enough. Not even a hash or something? It just made me kind of sad, but still. If this goes open-source, as a base for people, it'll end up as amazing as it seems, this surely won't hold it back.

        Piece #3: The AV DataBase (AV is Anti-Virus). It consists of a massive amount of efficient AV listings, with efficient code that doesn't interfere with the typical coding and makes sure to monitor all of the HTTP downloads and check them for mal-ware.

        There is an endless amount more that I can write, but it'll all just continue forever. I really to wish the best for CommuteOS, and for it to be the Linux of CC. Thanks for reading :).

 - Sledger721

Tearing Locks Apart

Tearing Locks Apart

An Idea for ComputerCraft Development

By: Sledger721

 

 

        Locks in ComputerCraft are common, and all quite similar. They're used a lot also, which really bothers me. The average fool thinks that because they have a password lock hooked up to an iron door that they're safe, but they've never been more wrong. I've broken many more locks than I'm going to admit too right now, but what's pushed me to write about this is that someone posted a topic to the forums talking about a lock which was almost invincible.



        The lock that I'm going to be tearing apart is the lock from that topic, but I formatted the code: [Pastebin of Lock Code] . It is simple, and yet quite efficient. Now, time to pick it apart line-by-line.

        The first line disables the use of CTRL+T, and the next couple lines are just terminal controls. Then the program gets the input, and says that if it is equal too "Password" then set a redstone pulse on the right side for a wee bit, then turn it off. After that it reboots. The else statement handles any incorrect statements, and then reboots.

        The main way that I would go about getting through this lock is simply placing a disk with an empty startup file on a disk, placing it on the computer and then putting in an incorrect password. Once it rebooted, it would launch with the blank startup and go ahead and skip me straight to the shell. I also like to have my "blank" startup print a line, something along the lines of: print("Disk Bypass Initiated."), just to let me know that it had worked.

        Another way to bypass it is to use a brute-force method, but that's rare, complex, hard and should only be used when a disk-boot can't. I'm not going to go over it, but a Caesarian Shift on each character is a good way to go. It lags, but it's a good way to go.

 

        Thanks for reading guys :).

 - Sledger721

Ghetto "C"

Ghetto "C"

 

 

 

 

Hey guys, I know that this isn't exactly a formal blog-post, but I just had to share this, I was out a'trolling on Pastebin, and I saw this: Ghetto "C". Yet again, my apologies for not giving a formal post, but I just had to share this :). Have a good day. 

The Rune System - RBS

Rune Boot-Loading System and Rune Development
An Idea for ComputerCraft Development
By: Sledger721

 

 

 

        The Rune Boot-Loading System (RBS) is a system of which I've developed to allow booting multiple OS', and all of them from disk. I had the original inspiration for RBS 3 days after ComputerCraft had been published, and I had created RedWorksOS. People wanted a way to boot smooth from both OS', and I simply couldn't find a good way. Someone wrote up a very poor quality boot-loader called FlameBL, but it didn't fulfill it's needed duty.

        The RBS system has it's own methods for the creation of an mOS (Micro-OS). A rune is simply an mOS, but set for the rune platform. Creating a rune is fairly simple. It requires the shell, a ~spark file and a copy of portal. To easy up on the learning, here is a glossary:

• ~spark - A ~spark file is a startup file for a rune. It functions in exactly the same way as a startup file, as the portal program calls it.
• Rune - A rune is a micro-OS, developed specifically for the rune platform. It is all contained within a single folder.
• Disk Booting - To disk-boot (dBoot) is to boot an operating system straight from a disk. It's a very good, safe and portable way to use an OS as it's completly sand-boxed.
• init_rune - init_rune is a system file for the rune system of which loads the APIs and does any other system operations of which are required for the system.
• Portal - Portal is a pre-packaged piece of software of which is on every rune, and is used to jump from one rune to another.

        These are the basic pieces of an RBS. One thing to keep in mind is that each rune has to have some principles in mind: Portability, Efficiency, Speed, Security and Light-Weight.

Security Flaws in RypNet

Security Flaws in RypNet

An idea for the development of ComputerCraft.

By: Sledger721

        With my recent work developing Rypnet (RN), I've found quite a high amount of security flaws. I've never, in all of my time with ComputerCraft seen a secure network, and this surely doesn't make one either, but just in-case someone needs these (for good or bad), here is a list of as many security flaws as I could think of.

        Security Flaw #1, Host Theft: Stealing Sites. Lets say that your buddy runs a pretty nice site with good amounts of traffic and influence, you can run a series of $RIP commands to get copies of all of his files, and then $REGISTER the url to your own ID.

        Security Flaw #2, Anonymous Deletion: Any site can be deleted, by anyone with: $DELETE.

        Security Flaw #3, DS Overflow: The DS is the Data Stack, and to overflow it is to have it perform so many table operations that it almost performs a DDoS on the server. It will also flood any attempts at a $GET from anyone.

        Security Flaw #4, Foreign File Placement: The $PUT command is extremely dangerous. The fact that someone can place a file in there, then place another one so that it is ran means that your computer is essentially a remote control. They could insert false data, or mal-ware to the computer. My original idea was that someone could easily launch a fork-bomb in there, a self-replicating file. It would fill up the host's HDD within seconds.

        Solution to Every Issue: Just create an admin list and only let those on your admin list issue commands. And don't put shadier people on it, be strict. It solves every issue.

        Thanks for reading my blog :). Please use these for the right reasons.

 - Sledger721

Internals of a RypNet Server

The Internals of a RypNet Server

An idea for the development of ComputerCraft.
By: Sledger721

        When I speak about the internals of a RypNet Server (RN Server), I don't mean the one that I wrote. I mean the basic systems of which would make up a good piece of server software, and in this article I'm going to go over each piece that I can think of during the time period of writing this.

        The first piece is the data stack. The data stack (DS) is a table that the server holds, and can be effected by any incoming signal. It does seem quite insecure, I know, but so does everything. The DS' purpose is to hold any foreign data, and you could have a server application that constantly checks the DS to see if there is a certain key, or simply to keep check on all foreign signals incoming to the server. A fairly useful tool.

        The second piece, one that I have yet to implement is a sandboxed database. The $PUT and $RIP commands are quite insecure on my server, and I was thinking about running a pcall() and having everything in the server/database folder as a root.

        Another one would be extensible instructions. Before I had created the server, I was thinking about having a folder with each instruction, and having a file for each one, like, a $GET file with the code inside for the $GET command, etc. But I decided to go hard-coded until I get the markup language for this system out.

        The last piece that I want to mention is the sponge. A sponge gets any signal that is broadcasted or sent, and logues it with os.clock() and os.time(). It is useful to monitor the entire area of rednet, instead of just locally your server.

        Thanks for sitting through all of this guys :).

 - Sledger721

Release of RypNet Systems

RypNet Systems

An idea for the development of ComputerCraft.
By: Sledger721

        I have found a gaping hole in the standardized technologies of CC, a standardized form of networking. When I say that, I'm not addressing things so low down that RedNet solves them, but issues such as a protocol. I took it upon myself to build the next level up from RedNet, a level of DNS and Server control of which hasn't yet been created, so I made RypNet.

        RypNet got it's name from my original idea, FrostNet. Ryp is Afrikaans for Frost however, so I decided to use that. I've been pondering this idea for quite a while, and I still have to create a markup language to show people just what can be created for a true internet, but for now, it's down at a much deeper level.

    Here is a list of functions within the RypNetAPI:

DNS Commands:

dns.register(iDNSID,sUrl) - Register the URL


dns.delete(iDNSID,url) - Deletes the URL


dns.find(iDNSID,url) - Finds the ID of the URL


RDNT COMANDS:




rdnt.post(iServID,sData) - Posts "Data" to the server's stack.


rdnt.putFile(iServID,sPath,sData) - Creates a file in the server's directory at sPath, with sData inside of it.


rdnt.putDir(iServID,sPath) - Creates a directory in the server's directory at sPath.


rdnt.rip(iServID,sPath) - Downloads the data from a file, returns it.


rdnt.check(iServID,sPath) - Checks for if a file or directory exists, returns two bools.


rdnt.obtain(iServID,sSetting) - Returns the specific setting. Right now the only setting is SERVER.ID, the id of the server, but it's somewhat self-explanatory if you're sending that.


        Rypnet is also packaged with a pre-made DNS and Server, of which are tailored to the specifications of the protocol. These may in turn be used as a base for future networking software based around this protocol.


        Thanks for sitting through all of that :).






 - Sledger721