Standalone Application Security
Richard Gaskin
ambassador at fourthworld.com
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: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
More information about the use-livecode
mailing list