1. Scramble
- Posted by Robert Craig <rds at EMAIL.MSN.COM>
Jan 24, 1998
-
Last edited Jan 25, 1998
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
2. Re: Scramble
At 09:06 PM 1/24/98 -0500, you wrote:
<re: super-shrouding>
>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?
>
Personally, I think it's more trouble to try to figure out
someone's plain English (ok.. Euphorish) code than it
is to write what you need from scratch.
No doubt there are people out there who enjoy a
challenge such as deciphering shrouded code, but
anything you add to Euphoria would just make it
a bigger challenge (they'd love that!).
I don't think it's worth much of your time.
The paranoid amongst us may disagree.
Irv
----------------------------------------------------------------------------
-----------
Congress is good at two things:
Passing laws, and passing gas.
They put numbers on the laws so we can tell the difference.
----------------------------------------------------------------------------
-----------
3. Re: Scramble
At 21:06 24/01/98 -0500, Rob Craig wrote:
>
>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.
>
> -- snip --
>
>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?
>
I think a quick enscramblin' routine would be a good
idea. At present, I suspect EU would currently be quite
easy for any of the smarter hackers around to crack.
The multiple password thing is a good idea but if someone
wants in that badly, they'll find a way. Just make them
work for it a bit.
Graeme.
4. Re: Scramble
Robert Craig wrote:
>
> 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.
...<big snip>...
> If your password were based on a checksum over the proper
> version of ex.exe you might defeat the super hacker, at least
> temporarily.
"temporarily" indeed. You face the same dilema publishers faced
with copy-protection schemes in years past. There is always going
to be someone out there that can get to the machine level of any
code.
> Most encryption algorithms are published, and the security
> depends on the secrecy of the password, not the algorithm.
...<snip>...
> 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?
I think an improved shroud would deture the people that are only
casually cracking your code. I wrote a de-shrowder for Euphoria
some time ago, as I wanted to see how some of the source-less
code on the programmers site was operating.
Simple keyword tokenization is not that difficult to reverse engineer.
It's been a long time standard though for shrinking the space required
for an interpreted language.
Many java (cough) programers are finding that their code is also
being reverse-engineered with little or no effort. I vote for an
improved shrouder, but lots not go so far with this as to have to
re-decrypt the file hundreds of times before execution (as I have seen
some comercial protection schemes written).
Well, I'm finished tambling. I'm off to bed. New job tomorrow at a new
ISP.
J-Shaman
jshaman at phreak.org
5. Re: Scramble
Robert
It would behove RDS to spend development time on something other than the
encryption method you describe. Make Windows pgming easier, provide more
examples, port Euphoria to other platforms, etc.
I expect the Scramble Method would provide a false level of confidence.
The algorithm would eventually be broken and distributed, faster computers
tomorrow allow passwords to be broken, things I need to be secure should be
safeguarded by something more.
RDS should decide what they & Euphoria are going to excel at. It sounds
like you are considering on embarking upon expensive development for
something that will be at best, half baked.
Just my thoughts...
John
6. Re: Scramble
> RDS should decide what they & Euphoria are going to excel at. It sounds
> like you are considering on embarking upon expensive development for
> something that will be at best, half baked.
>
> Just my thoughts...
>
> John
We could really go crazy and resort to
parrallel port Hardware keys like HTBASIC uses, and
use the key s/n in conjuction with passwords and
nose-prints to decrypt the source.
