OpenEuphoria

Re: Scramble and routine_id

• Posted by David Cuny <dcuny at DSS.CA.GOV> Jan 27, 1998
• 583 views

I've read the suggestion on scrambling code a number of times through, and
each time I like it less and less. So I vote a strong no against it.

I would be reluctant to develop code without the ability to shroud the
source. Many of my programs make heavy use of routine_id() - for example,
Win32Lib. According to your scheme, that would mean that if I wanted any
real hiding of my source, I'd have to use passwords.

I certainly don't want to start messing with passwords, either by hiding
them in code, or requiring the user to type them in to use my program.

As I understand it, the problem to be solved is to balance the need to hide
source code against routine_id()'s need to use the unencrypted routine
name. I'd far prefer:

   unshrouded function foo()  -- flags shroud to leave it alone
      <code goes here>
   end function

Or better:

   public foo, bar       -- tells shroud NOT to shroud these names
   include stuff.e       -- foo is defined in here

   function bar()        -- this name won't be shrouded
      <code goes here>
   end function

   public grill          -- another name NOT to shroud
   function grill()      -- defined here
      <code goes here>
   end function

The only requirement here is that the routine name be declared as public
*before* the name is encountered by shroud. For example, foo() is defined
in the included file stuff.e.

I think that shroud provides the right level of security. If you wanted
another level on that, I'd just indirect the keywords tokens to a lookup
table, and "encrypt" that table. That would make it much more difficult for
someone to decode than it is now, without radically changing very much
code. You'll never really be secure against a "super hacker" anyway.

On a similar thread, just how expensive is a call using routine_id? I
haven't bothered to benchmark it, but Pete tells me that it's 2 1/2 times
slower than a regular call. I was under the impression that there was
closer to a 10% overhead cost. Any estimates?

-- David Cuny