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 _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
