'hack' test results

Ken Ray kray at sonsothunder.com
Sat Apr 20 15:51:01 EDT 2002


John,

Suppose if you have an application that can load any stack that you issue
"lock messages" before opening the stack. This way, the opened stack won't
get any messages to start hacking the app. This is a pretty secure way to
go, IMHO.

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/

----- Original Message -----
From: <JohnRule at aol.com>
To: <use-revolution at lists.runrev.com>
Sent: Saturday, April 20, 2002 12:23 PM
Subject: 'hack' test results


> > The only data they should be seeing is the data I want
> > to show to them.  Other data is all in hidden fields.
> > Could you be more verbose?
>
>
> I just did another 'hack' test...with MCRipper this time:
>
> http://www.inspiredlogic.com/mc/ripper.html
>
> It cannot 'rip' password protected stacks (at least I couldn't get it to)
so
> that is a relief.
>
> MCRipper will 'rip' invisible objects (including any text or scripts) even
if
> the stack is password protected. So the conclusion...any information in
text
> fields (even hidden fields) is not totally safe.
>
> Solution:
>   Load the information from the field into a variable...then delete the
text
> from the field. You are still susceptable to any 'prying' if you give the
> users the capability to load any stack (i.e. I could load a stack that
> searches all variables). You may have to go so far as to binaryConvert
your
> data to/from the variable, and even further encryption for 110% protection
> (maybe break the data into pieces, and put it into multiple variables). I
> wish we didn't have to worry about this...it kind of kills the 'creative'
> juices.
>
> MCRipper looks like a useful tool actually (I think the authors intentions
> are honest)...nice work!
>
> I wonder if I can 'rip' MCRipper...hmmm.
>
>
> JR
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>







More information about the use-livecode mailing list