Making a floppy read-only?

Okay, so I've been trying and trying and searching and searching to find a way to do this.
Basically, if you wanted to make a floppy from which you could run a program, but you couldn't copy it onto your console.
For instance, if you made some software on a server and wanted to sell the discs individually, as opposed to people buying one and reproducing them.
Anyone be able to help?

Hmm. The only way I can think of is to create a hash of the file, which allows the program to run. Then, when the program cannot find the hash, it won't work. You could still edit and such, though.

This isn't possible even in principle. If data can be read, it can be copied. If it can be copied, it can be altered. This is pretty fundamental to what makes information information.

You can make it so that a program will only run on a specific computerID. And you could also make it so that a program required authentication (over rednet, perhaps) in order to run. Integrating either of those into a program so as to make it very difficult to remove takes a lot of effort, but it probably should.

Probably the best bet is distributing a "client" program that receives and runs the actual program over rednet. Someone could still modify the client in such a way as to copy your program as well as run it, though.

before distributing the disk:
set the disk label with a one-of-a-kind program and a tile that just looks like, well, a title using "disk.setLabel(string side, stringlabel )"

when the on-disk program is runing:
then check if the disk is mounted to the path the program is running from (so you can't copy it to the computer and run it if the disks in the drive
​then check the label of the disk = the label of the original disk using "disk.getLabel(string side )"
if ether of the above two lines = false refuse to run the program

in the code in-case they look:
bind the disk to a variable called something like "PasswordFile"
then have a file on the disk called password that relay has no purpose,
​or even make a fake function (one that is never called) named something like "verification" and make it look like your reading the "password file" but it's fake because it is never called and put it at the top so they read it before reading anything else

wouldn't work on a seasoned coder but the people you sell it to should'n be smart enugh to know, and will be to lazy to cair

tebbenjo, on 30 November 2012 - 03:04 PM said:

before distributing the disk:
set the disk label with a one-of-a-kind program and a tile that just looks like, well, a title using "disk.setLabel(string side, stringlabel )"

when the on-disk program is runing:
then check if the disk is mounted to the path the program is running from (so you can't copy it to the computer and run it if the disks in the drive
​then check the label of the disk = the label of the original disk using "disk.getLabel(string side )"
if ether of the above two lines = false refuse to run the program

in the code in-case they look:
bind the disk to a variable called something like "PasswordFile"
then have a file on the disk called password that relay has no purpose,
​or even make a fake function (one that is never called) named something like "verification" and make it look like your reading the "password file" but it's fake because it is never called

That's not going to stop you from removing the disk, putting it in a new computer that is already on and doing "edit disk/programName".

There is no way to make anything read only in CC.

That's not going to stop you from removing the disk, putting it in a new computer that is already on and doing "edit disk/programName".

There is no way to make anything read only in CC.

that doesn't matter; if they only kind-of know what they are doing then copying it fully will not work and changing the fake function will not work because it doesn't do anything.

tebbenjo, on 30 November 2012 - 03:22 PM said:

That's not going to stop you from removing the disk, putting it in a new computer that is already on and doing "edit disk/programName".

There is no way to make anything read only in CC.

that doesn't matter; if they only kind-of know what they are doing then copying it fully will not work and changing the fake function will not work because it doesn't do anything.

That's still not going to do what the user wants which is to prevent the contents of the disk from being copied onto a computer or another disk.

Edit: Just realized that this first method would still leave the user able to copy the unencrypted program from the disk. *facepalm*. The second method is possibly valid though. Also a quote from here: No matter which technique you use, you are still vulnerable to hacking on some level. The only thing you can do is raise the level of sophistication and time required to compromise the system.

Encrypt the file using some method of your choice that relies on a password or hash (maybe not easy to do, but pretty secure). Use another program that comes prepackaged with your encrypted program to check a temporary password you give them against a rednet server password and if it is right then send them a decryption program (pretty easy to transfer files over rednet) which will execute and decrypt the file before executing the main file which will delete the decryption software. You could actually package the decryption program in the main program by use of comments which would be deleted later (maybe too much complication? I don't know but you can never really have too much I would say). Although this is not an unbeatable system, I would say it is pretty secure.

Want to add another layer of complexity to this? Make a program that takes code line by line (or chunk by chunk if you prefer) from a server and executes it with loadstring. Require the program to have a password that is unique to the user's computer ID sent every time a line is requested and maybe add a few security checks into the downloaded code such as detecting whether or not the file has been copied to the computer.

Maybe this is beyond the scope of what you are wanting to do, but my head sort of ran away with this one and in fact I'm beginning to think that I may try to make an implementation of this myself.

well one highly complex and over engendered method comes to mind.
users are given a disk with a program on it. this program is the client side of a remote shell program like nsh. The user logs into your servers using a user pass unique to them. the remote shell application then starts the program and delivers the term calls to there computer and the client send back key presses. You would need to lock down the fs api so the user has no file system access to your servers files. the only way a person could run your application would be to have a disk with the client application and a password. they would at no point have access to the file its self from a computer system perspective. They would be able to access your data center by breaking the wall's with TNT or a pick (dependent on the configuration of the minecraft server) another advantage of that system would be that updating the program would happen in one central location. down sides would be needing repeaters for far away residents and chunk unload issues.

BigSHinyToys, on 30 November 2012 - 06:17 PM said:

well one highly complex and over engendered method comes to mind.
users are given a disk with a program on it. this program is the client side of a remote shell program like nsh. The user logs into your servers using a user pass unique to them. the remote shell application then starts the program and delivers the term calls to there computer and the client send back key presses. You would need to lock down the fs api so the user has no file system access to your servers files. the only way a person could run your application would be to have a disk with the client application and a password. they would at no point have access to the file its self from a computer system perspective. They would be able to access your data center by breaking the wall's with TNT or a pick (dependent on the configuration of the minecraft server) another advantage of that system would be that updating the program would happen in one central location. down sides would be needing repeaters for far away residents and chunk unload issues.

Hmm I especially like this method. Just save all of the IDs of users who have connected to your remote shell and you've got a pretty good protection system. Also I would recommend just going ahead and sending the user all of the outputs directly rather than giving the user remote access through nsh which could possibly be hacked in some way.

You can configure nsh to run a program for inbound connections rather than running a shell session, so using nsh isn't necessarily a security hole in this case. That's probably the only reasonably workable suggestion. A customized nsh-compatible server could keep track of connecting client information so that unique sessions can be ensured (one connection per unique code, one code per disk).

i think this be over complicated, i think the op sould clarify what he/she is trying to prevent from someone from copying

Or you can do something like in the reality : the program need a one use key to run it.

bjornir90, on 30 November 2012 - 07:16 PM said:

Or you can do something like in the reality : the program need a one use key to run it.

Anyone could edit it and view the password/code, so that wouldn't work

Bubba, on 30 November 2012 - 07:33 PM said:

bjornir90, on 30 November 2012 - 07:16 PM said:

Or you can do something like in the reality : the program need a one use key to run it.

Anyone could edit it and view the password/code, so that wouldn't work

Yes but it doesn't matter because it has only one-use so, like in reality other people can see it but they can't use it :)/>

bjornir90, on 01 December 2012 - 04:51 AM said:

Yes but it doesn't matter because it has only one-use so, like in reality other people can see it but they can't use it :)/>/>/>

If a person can edit the code then they can get rid of the one-time-use feature, and because there is no edit protection that means anyone can edit it.

bjornir90, on 30 November 2012 - 07:16 PM said:

Or you can do something like in the reality : the program need a one use key to run it.

Yeah, this wouldn't work. No matter how you slice it, if you give them the code to execute, they can copy it and execute it as much as they like. The only way to restrict use of the program is to not give them the code, and an nsh session is probably the easiest way to accomplish that.

I wanted to say the code is server-side, not client-side. I mean something like a code that you give to the user, he enter it to use the program and the code is sended, then the server send an encrypted validation key and allow the user to use it/install it.

bjornir90, on 01 December 2012 - 07:33 AM said:

I wanted to say the code is server-side, not client-side. I mean something like a code that you give to the user, he enter it to use the program and the code is sended, then the server send an encrypted validation key and allow the user to use it/install it.

Still wouldn't protect the guy from somebody buying the program once and then giving the code to everyone else. nsh or some variant of nsh is really the only conceivable way to do this.

Bubba, on 01 December 2012 - 09:44 AM said:

bjornir90, on 01 December 2012 - 07:33 AM said:

I wanted to say the code is server-side, not client-side. I mean something like a code that you give to the user, he enter it to use the program and the code is sended, then the server send an encrypted validation key and allow the user to use it/install it.

Still wouldn't protect the guy from somebody buying the program once and then giving the code to everyone else. nsh or some variant of nsh is really the only conceivable way to do this.

I still don't see the probleme because the code has only one use. If a user install it, the code aren't good anymore so you must buy another key to be able to copy it. Even if people has the code, if it was used once it can be used a second time.

No, the problem is that there's nothing you can do to keep them from copying it once they have the program code. Even if they "need an install key", they can just strip out the key-checking code from the rest and use it freely.

Hmm compiled lua code? :3 atleast makes it harder

This is a problem that any software company encounters; how to prevent pirates. The best way is to compile it, as Pinkishu said, and add security keys, but of course Lua code isn't exactly compilable.

No matter which technique you use, you are still vulnerable to hacking on some level.

In the 1960's, "hack" was defined as a clever or elegant technical accomplishment.
In the late 1990's, "hack" was redefined as breaking and bypassing computer security.
Today, "hack" means editing a plain text file.
:{

Yeah, I feel your pain, dissy.

I don't favor the idea of having the client remotely access the server, that's not at all what I was suggesting. Lyqyd was recently helping someone do something more like what I was thinking, which would be to have the client program wait for a rednet message and then loadstring(message)(). This way you could also do some preliminary checks on whether the receiving computer was set up right, whether the floppy was in the disk drive and contained the original program, for instance. It shouldn't be too hard to figure out whether someone was trying to find a way to steal your program…and you could have a loaded program go through and find everything locally stored on the client computer (and delete it all from their end) and send it back to you so you could steal their tools if you found indications they were hacking you.

You do have a lot of power over people who are dependent on you for programs to the point where they have to buy them from you. But it's not absolute. If they were clever and patient enough to set up a fake client that deleted itself at the outset but kept all the messages you sent, well you'll have a hard time catching them and they can steal your stuff.

But at some point they're probably just doing it because they can, not because they actually need your code.

I think we can probably say that the idea of a read-only floppy is almost impossible in ComputerCraft, and the only methods of making a read-only floppy are either hackable or wouldn't work quite as you wanted them to.

Yes, agreed.

read-only floppies are trivial to do and pretty easy, with access to the host file system.

However the feature being requested is not related to read-only floppies, but instead wanting uncopyable floppies, which is impossible to do.
Literally the only way to not let a user copy the program, is to not give the user the program.