Scramble
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jan 24, 1998
- 789 views
Hello All, I've been pondering the issue of security for bound/shrouded code and I've got a tentative solution, but I'd like to hear if anyone has any better ideas before I go ahead and code it. Currently, when you shroud (or bind) a program, all comments are removed and almost all routine and variable names are converted to short meaningless names. Optionally you can convert strings such as "ABC" into sequences such as {65,66,67} so they aren't readable. Furthermore keywords are replaced by single-byte codes, but this can be reversed by someone who takes the time to figure out the code assigned to each keyword. Binding is the same as shrouding, but the shrouded file is tacked onto the end of the PD ex.exe. There's currently a problem in 2.0 if you use routine_id() and then bind or shroud your program. Most routine names will be shrouded, so routine_id will fail to find the routine name when the code is shrouded. To get around this I will probably have a bind/shroud option to not shroud *any* routine names. You would use this option when you are using routine_id. If bind/shroud notices that you are calling routine_id it will warn you to use this option. To improve the security of bound/shrouded code, I am considering a "scramble" option to bind.bat/shroud.bat that will take the shrouded form of your program and apply an encryption algorithm (Let's not use the word encryption - just "scrambling") to make it totally unreadable to anyone who doesn't know the algorithm. Furthermore I might allow your program to optionally change the "password" used by the algorithm. Initially, bind/shroud would choose a password at random to protect the initial part of your code. During the initial part of your code, you could calculate in some devious way a new password for the rest of your program. You would have to tell bind/shroud what the value of this password (number) will be. e.g. bind myprog -scramble 99999 Your code would call set_password(99999) at some point. Or it could call set_password(33333) set_password(33333) set_password(33333) at various places. ex.exe would sum all of the calls to set_password so it isn't obvious what the final value will be. With this approach, your program could only be unscrambled by someone who has the algorithm, *and* who can determine the new password that your program calculates. The initial password word be stored in your code by the shrouder/binder - it wouldn't be a secret - the algorithm would be a secret. Someone who knows the algorithm could unscramble the first part of your program. He would then have to inspect or run your program to get your new password. The advantage here is that there could never be a simple program that could automatically unscramble all scrambled programs. It would take a bit of unique work for each individual program, to inspect it or run it to get the new password. You could use your creativity to try to hide the new password, or you might simply require the user to type it in. I could also set things up so your program would be somewhat tamper resistant using checksums etc. The major drawback to this is that RDS would know the algorithm. Another drawback would be that theoretically some super hacker might hack his (or her) way into ex.exe and somehow figure out the algorithm, or more likely modify ex.exe into spitting out the unscrambled source as it runs your program. This would be quite a feat of hacking (not that I'm encouraging anyone to try it!) If your password were based on a checksum over the proper version of ex.exe you might defeat the super hacker, at least temporarily. Most encryption algorithms are published, and the security depends on the secrecy of the password, not the algorithm. In this case the Euphoria interpreter must ultimately be able to "understand" your program, no matter how clever you are. So, unless you want your user to type in the password, it will have to be "told" to ex.exe somehow. Either RDS or the super hacker could therefore, with a bit of work, reverse the scramble and get back your shrouded source, which is certainly not as bad as getting your original source, but might be upsetting if you have secret algorithms or other information in your code. Is this worth it? Should I forget about the second password? Are there people out there who are reluctant to distribute their program because the current shrouding isn't good enough? Regards, Rob Craig Rapid Deployment Software