Bypass disk startup?

I found out that if you use mkdir to make the folder "disk" the disk startup doesn't work so combined with a login program, it could be a really secure computer!

Are you running server with modified ComputerCraft rom stuff? Cause that is not how startup works and this would not stop it from working on vanilla CC. It looks for actual disk drives not for disk folders.

wojbie, on 27 September 2015 - 08:19 PM said:

Are you running server with modified ComputerCraft rom stuff? Cause that is not how startup works and this would not stop it from working on vanilla CC. It looks for actual disk drives not for disk folders.

Well, when I tried it I inserted the disk in with the login program installed and the disk folder on, rebooted and it stayed at the login screen.

Did you put a startup file into that disk?

Well, I just tried it and not only does it bypass disk startup, the directory overrides the entire disk completely, meaning there's no way to access its contents, too.
EDIT: Also happens with no mod except ComputerCraft installed.

Lignum, on 27 September 2015 - 09:01 PM said:

Well, I just tried it and not only does it bypass disk startup, the directory overrides the entire disk completely, meaning there's no way to access its contents, too.
EDIT: Also happens with no mod except ComputerCraft installed.

What version did you test on? I tested on 1.74, and it just created a disk2 instead, and still ran the startup.

edit:

Interested… I tested it again, and it bypassed disk startup this time.

edit2:

Tested again on a different comp and it didn't work. IDK anymore lol

valithor, on 27 September 2015 - 09:08 PM said:

What version did you test on? I tested on 1.74, and it just created a disk2 instead, and still ran the startup.

I also tested on 1.74. It also seems to replace the disk contents with the directory's contents once you take it out…

MKlegoman357, on 27 September 2015 - 08:55 PM said:

Did you put a startup file into that disk?

Yes, I did put one into the disk. Also, I was using the latest version of CC. (for everyone else)

I discovered this when I did mkdir disk by accident(don't ask how)

Just to reproduce it:
Step 1: do mkdir disk on the computer
Step 2: install login program
Step 3: reboot with a disk in that has a startup on it
Step 4: If you did it right it should stay at the login.
EDIT: my login program that I used to reproduce it:
http://pastebin.com/vTNF0Bx1 (it is a function in the api)

wojbie, on 27 September 2015 - 08:19 PM said:

Are you running server with modified ComputerCraft rom stuff? Cause that is not how startup works and this would not stop it from working on vanilla CC. It looks for actual disk drives not for disk folders.

Well, sort of. While it's true that it checks to see which disks are connected, to get the path to the startup files stored on them, it still ends up appending "startup" onto whatever disk.getMountPath() returns. See here.

valithor, on 27 September 2015 - 09:08 PM said:

What version did you test on? I tested on 1.74, and it just created a disk2 instead, and still ran the startup.

This is my finding as well - my systems correctly mount disks to an untaken folder name, and boot startup from them if present.

So presumably there's a way to get a computer to incorrectly mount a disk to an already taken folder name. I can't figure out what that is, though.

Lignum, on 27 September 2015 - 09:19 PM said:

It also seems to replace the disk contents with the directory's contents once you take it out…

Are you saying you've found a method allowing you to bypass the space restrictions on floppy disks…?

I am very interested in the results of these tests. Bug or not I may use them to increase my security.

TYKUHN2, on 28 September 2015 - 02:47 AM said:

I am very interested in the results of these tests. Bug or not I may use them to increase my security.

Anyways, Even if it is a bug maybe we should just keep it as a feature so we can use to our advantage.

Before adding disk folder: [attachment=2386:Screenshot (17).png]
After adding disk folder: [attachment=2387:Screenshot (18).png]

Bomb Bloke, on 28 September 2015 - 01:41 AM said:

Lignum, on 27 September 2015 - 09:19 PM said:

It also seems to replace the disk contents with the directory's contents once you take it out…

Are you saying you've found a method allowing you to bypass the space restrictions on floppy disks…?

The floppy disk had the contents of the "disk" folder he made before he inserted the disk.

Wait when I insert disk its getting assigned disk2 name and its content are in disk2 folder cause disk was taken by already made folder. And startup correctly used disk2 folder ignoring disk one. Can anyone confirm this thing cause for me it seems to work correctly?

wojbie, on 28 September 2015 - 10:07 PM said:

Wait when I insert disk its getting assigned disk2 name and its content are in disk2 folder cause disk was taken by already made folder. And startup correctly used disk2 folder ignoring disk one. Can anyone confirm this thing cause for me it seems to work correctly?

I tested it again and I can confirm this because apparently deleting and remaking the folder a few times immunizes the computer making the glitch not work and it will ignore the disk folder and register it as disk2.

Now I'm so confused :P/>

As I was saying, there's presumably a circumstance - such as a specific order of operations - that triggers the bug. Beats me as to what that'd be.

valithor, on 28 September 2015 - 09:44 PM said:

The floppy disk had the contents of the "disk" folder he made before he inserted the disk.

Which, given that you could stick more into the computer's "disk" folder than you usually could into an actual floppy disk, would mean that this could be used to create "jumbo" floppies, yes?

Assuming the "files end up on disk when disk is removed" part holds true.

Initial inspection of the startup script within computercraft.jar suggests it should not be affected by mkdir disk.

Further inspection of the disk API and the peripheral API suggest it should not be affected by said method.

Experimental inspection involved editing the startup file to print debug data and repackaging computercraft.jar and upon testing this method did not work.