Check the HTML. I have come across simple meta tags that prevent any files
from being cashed or delete them imediatly after use. But even with that,
you may still be able to find a path to the internal _levels that are played
and go directly to them, outside of HTML and once you do, you cashe them and
they can be decompiled. I have also heard of programs out there the scramble
the AS and supposedly dont prevent it from working properly. But I have
never really hunted them down to see how they work.

--
Regards,
--Vern
===========================
onClipEvent(doSomethingStupid){
setProperty("Face", color, #FF0000);
_root.audio = "uh oh!";
}

Problem:
I found several programs "out there" that decompile Flash aps (SWFs). In the
Flash authoring environment, I password-protected my ap and selected "protect
from import". I downloaded "Flash Decompiler" (Eltima software), and opened up
my ap swf and was able to do the following:
1. veiw all my code, with most function and variable names intact.
2. see, edit, and export any resource in the file (that's everything other
than code).
3. swap resources! (I can change my logo to "Fred's WebTools", or change the
shapes to animated pornographic cartoon characters).
4. write out a modified version that runs just like my ap (with the mods).
So obviously I am motivated to find a solution to this glaring issue. My
solution so far is to create an "empty" swf (call it "loader") that just has
commands to load a preloader and the ap swf into higher levels. The loader
executes the preloader (once the preloader has loaded completely), which then
executes the ap (once the ap loads completely).

I used the Flash Decompiler on the loader, and I only see the code to load and
execute the other two swfs. One can easily infer the complete path to these
files, but that's about it. So, if Flash can load these files and no one else
can, I think I am home free.

Can one set permissions on a folder and/or file so that only Flash can read
it? Maybe I use the back end and "serve" Flash the file? I need to protect my
IP (mostly frame 1 code).

Anyway, I am doing some research on how best to solve this delightful issue.
I set up the "system" I described above (with the preloader) and tested it.
All the swfs still show up in my temporary Internet files (the loader, the
preloader and the ap), and all can be decompiled and manipulated (so this may
not be the solution).

HELP!

Doug

There is no solution. The swf is an open source format, and so extremely
vunrebale in this sense. there is NO proven way I know of to absolutely
secure your swf.

Sure there is (but rather pointless); buy the best vault you can find; store
your swf files in there, and then either throw away the key or run into a
bus for some memory loss. Although: that would be painfull; stick to the key
operated vault and throw the key away. As an extra safety measure; throw the
vault into Loch Ness or some other really deep water.

Peter is right; there is no fullproof way of protecting swf files. Better
live with it and spend time in the sun instead of trying to find that
fullproof solution.

John

--
----------------------------------------------------------------------------
-----------
RESOURCES
http://groups.google.com/advanced_group_search?hl=en&as_ugroup=*flash
----------------------------------------------------------------------------
-----------
TUTORIALS at
www.laiverd.com
Flash & PHP Emailform
Using textfiles in Flash
----------------------------------------------------------------------------
-----------

Dude, are you trying to say that what you have created is SOOOO far beyond
what anyone else has done, that people are going to be standing in line to
steal it? If that is the case, SELL THE THING and make some money.

But geez, if people wanna steal it, their gonna! Deal with it.

--
Regards,
--Vern
===========================
onClipEvent(doSomethingStupid){
setProperty("Face", color, #FF0000);
_root.audio = "uh oh!";
}

I am a little freaked out by all this. So it seems like it's a war of
attrition. You can make it harder and harder to get to, but never impossible.
There must be a point of diminishing returns on the "my effort" vs "their
difficulty" graph. I seek that point.

Okay, so WHAT is secure in Flash? Is data transfer secure? Can I get code
dynamically through XML? So far, my efforts tell me I can assign string
variables this way, but nothing else. About 2 years ago, I developed a Flash
ap for Wells Fargo that compares bank account typs in any state (lots of XML).
Recently I visited the site, and I was able to grab my app (the swf) out of my
temporary files, decompile it, change the logo to "Bank of America", and point
it to a different XML source in about 5 minutes. Hmmm....

No wonder no one's using Flash for Enterprise solutions where security is an
issue!

The problem with protecting SWF files is that there is always a cached version
somewhere on the machine, at some point or another. If there was a truly
unbreakable method of preventing the existence of a cached version, it would be
a fairly simple matter to prevent the SWF from being downloaded directly, that
would work in nearly all cases. (somebody really determined could probably
spoof their way into it).

There should be an online competition for creating the most secure method.
(just a suggestion)

Okay, so WHAT is secure in Flash?

I would say that for flat-out 100% security, the only really secure thing
would be core business logic. For instance, if you are doing a project for a
bank and they use a proprietary/secret formula for calculating XYZ, you can
make sure the entire calculation for this is all server side, and that Flash
only sends the originating variables, and receives the results, but does no
actual computation itself. This would be secure (or at least *could* be
secure, if done correctly).

Flashguru's website discussed a 'competition' a couple of years ago through a
company that produced one of the "obfuscators" that a previous poster
mentioned. (an obfuscator scrambles the actionscript to make it difficult to
read) The goal of the competition was to bypass the obfuscation block, and
determine a predetermined password. Bypassing the obfuscation block was
simple, so there was no real protection of the contents of the swf. But the
password was being verified with an MD5 hash algorithm, which is a type of
one-way encryption. The password wasn't 'secured' by the swf, because it
wasn't even included in the swf -- the swf only included the password's MD5
hash for comparison.

So, because the password was irretrievable, nobody won the competition even
though the actual password was bypassable and irrevelant. The point is, there
was no data actually contained within the swf file that was unreachable by the
obfuscation.

This upset quite a few people (myself included) who had risen to the
challenge. We all thought it was pretty stupid of the company to try to sell a
product whose only real accomplishment was porting MD5 (which has been around
for years and years) to actionscript.

Flash security is exactly the same as any other web technolgy, including HTML.

- anything that finds itself in the cache is insecure, so you should not embed anything important in
a swf
- anything that comes over a http server is insecure

For all web design, your site design IP is *never* secure, so I dont see why you are specifically
pointing at Flash.

Most competent flash actionscripters can deconstruct and replicate a design without having to
decompile it, so you cant expect a totally new and novel design to stay that way for long. FWIW, my
opinion is that you're better off being creative enough to keep ahead of the curve, rather than
worrying about this.

Everything gets copied in time.

S



[quoted text, click to view]

Potential Solution?

Okay, so I am accepting that anything in the Flash file is wide open. What if
I exploit the use of XML to pass critical data into Flash (only existing at run
time).

For example, in the Flash app I have a MovieClip called drawPane sitting on
the _root. In drawPane, I have another MovieClip called drawLayer, that has
the method clearCanvas();. I can pass string values like drawCanvas =
"drawPane.drawLayer" (via XML) and reference drawLayer's methods and properties
like eval( drawCanvas ).clearCanvas(); This might effectively hide the pointer
to drawLayer, and thus fail the ap if you didn't have the XML, which I am
hoping can be made secure. I can also hide the method by passing the method
name as a string in a similar fashion (i.e. clearIt =
"drawPane.drawLayer.clearCanvas" and then I use eval( clearIt )(); Now without
the XML, you know even less.

Okay, I set this up and it works (sort of). When I decompile the flash I
can?t see the variables loaded in and created by the XML. The problem is I can
just grab the XML file from my temporary files and voila: I have all the
correct references. Is there a way for me to pass xml (via a socket server,
Flash remoting, etc.) that won?t place the xml file in my temporary files?
Basically is there ANY known method of passing ANY info securely into Flash?

Doug

Your right,
I would MUCH rather spend my time developing whippy new Flash aps vs. worrying
about someone trying to steal my code. I am not personally worried. However,
I am an independant subcontracter working for companies who want their stuff
protected. If there's a way to do it, they can weigh the difficulty vs. the
roi. I can also move some of the code onto the server-side (php, .NET, etc).

Fortunately, Flash Obfuscator may be a good solution.
http://www.genable.com/aso


Doug

[quoted text, click to view]

This is unfortunately true.
there are ways to make swf as streaming files using server site , automatically prevented from
caching, dumped after playing instantly.
Sites like www.bigshotmedia.com practice that because they make living on frame by frame animation
in SWF format. I have been regular client on this site and in touch with the team from time to time.
They did have many people still finding ways and make custom buttons from flash which would execute
the database commands to produce links and make the SWF directly download to their computers.
They aware of it from server logs. There really is nothing you can do as THERE IS ALWAYS way and the
more you try to protect it the more you challenge the individual who try to get it and he or she
will make sure to prove you wrong. Out of fun for the challenge sake.
There are some things flash can't be use for.
--


Regards


urami_*

<hol>
http://flashfugitive.com/
</hol>


By The way:
If you try to mail me , DO NOT *laugh*

[quoted text, click to view]

XML isn't the "perfect" solution, either....because XML files can also be
downloaded and viewed, right? If you have apache, you can put the XML file
in a directory that is locked down with an .htaccess file or something like
that, I'm sure. I think that if you're trying to protect your flash work in
terms of it's uniqueness, you're going to have to live with the fact that it
can be "borrowed" from the Internet. If you're trying to protect your data,
keep it all in .php, .asp, .jsp or whatever and #include those files at
runtime or something like that. And if the data is THAT critical for
security, etc...why are you putting it on the Internet in the first place?

Jon

You can do all you want to protect your actionscript, or fancy design
or whatever, but like everybody else said, its pointless. The whol
purpose of flash is user interfacing. You make a site that looks cool
is interactive, ect. It does what html couldnt, but is meant to be use
in about the same ways.

If you are doing display stuff and dont want people to have access t
something until they buy it? Go ahead and make a low quality o
incomplete version for your website.

Things to not do with flash? Store sensitive data. Do computations
Check passwords. First of all, flash is incredibly inefficient at thes
things, so it would be bad programming practice to do them. Ther
already good ways to do these things. Use server side scripts that d
computations, databases to hold the data (or other secured files), etc
Use flash solely as a user interface. And in the end, if you dont wan
anybody to steal your flashy new design, then dont show it to anybody
-
austina
-----------------------------------------------------------------------
Posted via http://www.forum4designers.co
-----------------------------------------------------------------------
View this thread: http://www.forum4designers.com/message101369.htm