Protecting SmileBASIC programs

It just isn't possible to run a program without giving the user access to the code. Even if you write the code to a slot, run it, then clear that slot while it's running, someone could just modify the code to NOT delete it.

Yes, but look at amihart's demo code. It's incredibly hard to read and modify from first glance, though I see a few things that might make it a bit easier to read. If we keep out speed, some kind of JIT compilation system would definitely work, just with the loss of defining functions and labels. Then again, functions are usually meant to make the code shorter and easier to read.

It just isn't possible to run a program without giving the user access to the code. Even if you write the code to a slot, run it, then clear that slot while it's running, someone could just modify the code to NOT delete it.

And then what? You now have broken code that crashes immediately. You've accomplished nothing.

It's possible to make a program that looks like amihart's spaghetti stew which is mixed in with some useless functions and variables and loads code from an array and translates it into a slot, executes that code then the code in the slot clears both its slot and the launcher's slot. It's still possible to get at the code and modify it but it's just a bit more annoying to do so unless you know exactly where to look.

Remember that you only need one person to crack a program for everyone to have the cracked version.

Or have one person buy the password and tell everyone lol

Hmm small-scale piracy...

It's possible to make a program that looks like amihart's spaghetti stew which is mixed in with some useless functions and variables and loads code from an array and translates it into a slot, executes that code then the code in the slot clears both its slot and the launcher's slot. It's still possible to get at the code and modify it but it's just a bit more annoying to do so unless you know exactly where to look.

My idea isn't just turning it into spaghetti code. It calculates some values initially when generating the obfuscated program then attempts to incorporate those values into the program's structure. The reason my program requires two slots is simply for the purpose of copying to read its own source code which it then uses to recalculate those values which are essential to the structure of the program to function correctly, thus if the source code is altered, the values will be calculated incorrectly and the program will no longer function. The challenging part is incorporating those initially calculated values into the program in some way that it is very difficult to reverse. The way I did it in my first attempt wasn't too difficult to reverse once you could figure out what was going on, but that doesn't mean better methods aren't out there.

Or have one person buy the password and tell everyone lol

I already mentioned how that could easily be worked.

How could you stop someone from sharing their copy of the program along with the password? Even if the key works for just a week, you could just share your new key every week.

Maybe it's possible to make a password/security system which changes itself based on time? The launcher loads itself into another slot, edits the code where it does its security stuff, saves it, then does its normal stuff after clearing the slot it loaded itself into.

How could you stop someone from sharing their copy of the program along with the password? Even if the key works for just a week, you could just share your new key every week.

Then you just ban their account.

I look into other's programs and see if they have any declaration of use before I use. For example, I'm using Simeon's SIM.3D library and it has no rules on usage, so I use it any way I wish. If he updates the program and it has something, I'll surely credit him.

My idea isn't just turning it into spaghetti code. It calculates some values initially when generating the obfuscated program then attempts to incorporate those values into the program's structure. The reason my program requires two slots is simply for the purpose of copying to read its own source code which it then uses to recalculate those values which are essential to the structure of the program to function correctly, thus if the source code is altered, the values will be calculated incorrectly and the program will no longer function.

I just realized there's a huge flaw in this approach. So you read the program's source code and perform various checks to make sure it wasn't modified. But the key issue here is "read the program's source code". If I can get the program to read another unaltered copy of the source code instead of itself, I can modify the code to my heart's content, no matter how many checks you put in.

How could you stop someone from sharing their copy of the program along with the password? Even if the key works for just a week, you could just share your new key every week.

Then you just ban their account.

Only if you know who it is. You could set up some multiple password scheme where each person has a different password, but then, if I can figure out the program, I can trick you into banning other people by using other people's passwords. Doesn't seem like a very ideal system.

How could you stop someone from sharing their copy of the program along with the password? Even if the key works for just a week, you could just share your new key every week.

Then you just ban their account.

A non-SBS user could still take the program and upload it. Granted, it might not get the traffic as programs available through SBS but it can still be done whether you would know it or not.

They mean prevent them from accessing their password.

How could you stop someone from sharing their copy of the program along with the password? Even if the key works for just a week, you could just share your new key every week.

Then you just ban their account.

A non-SBS user could still take the program and upload it. Granted, it might not get the traffic as programs available through SBS but it can still be done whether you would know it or not.

They mean prevent them from accessing their password.

woops I definitely did not understand. I get it now, thanks for clarifying.