Standalone Application Security

Richard Gaskin ambassador at
Thu Mar 31 10:32:53 EDT 2011

Warren Kuhl wrote:
> I have a application that I am rolling out shortly.  The stack includes a
> key to access an excrpyted Valentina DB.  From what I read with other posts
> on the list, RunRev applications are not that hard to decrypt?  If this is
> the case, what are the best pays to protect myself from having someone
> to "break down" the Runrev application to get the key to decrypt the
> database?

Stacks can be protected with a password property (settable at build time 
in the Standalone Builder or at any time using the Message Box).  This 
will make scripts in accessible in the IDE, and will make both scripts 
and custom props unreadable on disk.

In older versions (pre-4.0?) the encryption scheme was described by 
Scott Raney as a derivative of DES -- more than enough to keep out 
script kiddiesm, but only about a weekend's work for a professional cracker.

In more recent versions scripts are protected with a much stronger algo 
(triple DES?) and are considered much more secure.

In the saved stack file not only are your scripts encrypted but also 
custom props are no longer readable in a binary editor.  However, keep 
in mind that those properties will still be available in unencrypted 
form in any LiveCode editor.

That should only be a concern for data stored in custom props within 
stack files other than the standalone, since the new standalone format 
makes extracting the stack file from the executable much more difficult 
than it used to be.

You can hard-wired things like passwords into scripts to have them 
protected, or for larger or more complex data store them in custom props 
after running them through LC's encryption functions (which offer 
Blowfish and other good options).

If your stack involved nuclear secrets or other similarly critical 
information, note that no code is ever truly safe from the 
sufficiently-motivated cracker.  Low-level debuggers can disassemble any 
code written in any language to derive both algos and data at runtime, 
no matter how secure the storage format is.  Anything that can be run 
can be disassembled.  Obfuscation can slow them down, but nothing can 
stop a skilled cracker from learning the inner secrets of any app.

If you were dealing with data or algos that critical, controlling 
physical access to the application is the only way to minimize risk (and 
as the Pentagon's showed us, with random USB thumb drives staff 
mindlessly inserted into systems at CENTCOM and the occasional briefcase 
left in a hotel restaurant, even attempting to control physical access 
is not without risk).  As they say in the security forums, "physical 
access = root".

  Richard Gaskin
  Fourth World
  LiveCode training and consulting:
  Webzine for LiveCode developers:
  LiveCode Journal blog:

More information about the Use-livecode mailing list