View scripts of my standalone? - Major Security Issue

[Richard Gaskin]

Lyn Teyla wrote:
> If I remember correctly, there is a long-standing security
> issue where anyone can view the stack scripts of ANY Rev
> standalone by doing a "memory dump" WHILE the app is running.
>
> This works EVEN if all stacks are completely password
> protected (and therefore encrypted)!
>
> Apparently this is caused by the RunRev engine decrypting
> and reading the scripts into memory and keeping them there
> in clear text for as long as the app/stacks are open.

That appears to remain the case with the latest version in testing.

This line describes the scope of the problem:

> I have no idea how to do a memory dump

;)

Those for whom dumping memory is second-nature are probably familiar 
with disassemblers as well.  Like trying to protect images on web pages, 
the only way to deploy an app is to expose its algorithms to anyone with 
sufficiently interest in discovering them.

Sure, RevTalk is easier to read than Assembly, but copyrighted code will 
only be stolen by those with an intent to do harm.  Those seeking to 
profit from such theft are probably well equipped regardless of the 
language you're using.  Nothing shared is ever safe - see Jeff Massung's 
notes on algorithm obfuscation at:
<http://mail.runrev.com/pipermail/use-revolution/2010-March/136017.html>

That said, I wouldn't mind seeing this changed myself.  While I feel the 
material risk is minimal, risk is still risk.  If you submit a request 
for this please share the RQCC number here.

One solution for this may have other, bigger benefits:  an option for 
true machine-code compilation.  All desktop platforms are now using the 
Intel instruction set, so while this might have been prohibitively 
onerous before it might be doable today.

Such compilation may also open the door to language options which would 
let us communicate with the OS API directly from within RevTalk, as 
Toolbook has provided for years.

I would imagine that an option for machine-code compilation would carry 
some limitations, but for those who could use it it may be well worth 
working with those limitations.

--
  Richard Gaskin
  Fourth World
  Rev training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
  revJournal blog: http://revjournal.com/blog.irv