Scramble

new topic     » topic index » view thread      » older message » newer message

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

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu