Securing External Assets

Because “clients are stupid dumbfucks” and prone to clicking on things they shouldn’t, and messing around with files that are entirely irrelevant to what the project was produced to do (i.e. opening up the transcript.xml file and inadvertently invalidating it, so that when the project is run as intended, the transcript doesn’t work, thus my fault).

How would I go about preventing read access to a folder on Windows such that the Flash projector (the project running as intended) can still get access to those files and this security measure will translate across computers when compressed into a zip file?

At current I have simply made the folder hidden, but I fully expect the client to unzip the folder (they’re total dumbfucks, remember, and we had to explain how a zip file works) and having seen the folder in the zip file, but not when it’s unzipped to come back to us and say “the content folder didn’t unzip properly it’s not there.”

As a nice-to-have, similarly related question:
Is it possible to shove external assets in this manner into the macProjector.app folder (as it appears on Windows) and then reference the file properly inside Flash, such that when published as a mac projector and run on a mac, the assets will still be loadable?

You can set file attributes on files in Windows; read-only as well as hidden. Manually you can do it through right click/Properties; if you want it as part of an install script you might need a trivial program to do it.

Can’t you set the access attributes within a zip file? Mind you, I can’t see how to do that in 7-zip. But try setting the folder to read-only before adding it to the zip. When I do that, and then re-extract it, the read only attribute is preserved.

The user will still be able to remove the read-only flag, but only if they deliberately do so, at which point it’s clearly their fault and undeniably so.

Is encrypting it an option? I think most users wouldn’t even think about touching a file that is encrypted when they open it up. (They see weird characters and leave it alone)

Super Complex: Or host this file on a server somewhere with access only by scripts on the server that would return the data but not allow modification.

Originally posted by UnknownGuardian:

Is encrypting it an option? I think most users wouldn’t even think about touching a file that is encrypted when they open it up. (They see weird characters and leave it alone)

Does flash have an API for loading in encrypted files?

Super Complex: Or host this file on a server somewhere with access only by scripts on the server that would return the data but not allow modification.

No. Primarily because this is not loaded on a sever.

Originally posted by BobJanova:

You can set file attributes on files in Windows; read-only as well as hidden. Manually you can do it through right click/Properties; if you want it as part of an install script you might need a trivial program to do it.

I need to remove the read permissions. Some of these external files are .swfs and “The Goal” is to prevent them from running the swfs without the parent container.

Does flash not have an API for loading encrypted files? Encrypt the data that goes in it through strings (via AS3). Load the file and read the bytes and perform decryption when reading and encrypt when saving.

Originally posted by UnknownGuardian:

Encrypt the data that goes in it through stings (via AS3).

I have a feeling that won’t work on an external swf.

encrypt the file with an external program (perhaps one you write in AS3) then have the SWF parent decrypt the file when it loads it, having done such you’ll need to “load” it via a Loader again to get it as an SWF you can just addChild

a simple XOR cipher would do

That seems a bit excessive. But I’ll pitch the idea.

Can’t an encrypted file be invalidated anyway? For example, lets just say your ‘encryption’ is converting an image to base64 and saving it as a .txt (Why this method? IDK). If I open it up and type random crap in, I’m going to mess up your image.

I guess even stupid people know better then to type random crap in a file full of random characters though… maybe… probably not…

Either way, encrypting it isn’t really preventing anything. Encryption doesn’t protect data from reading (or writing), it just protects it from intelligible reading or writing.

Once again, external swfs. There’s only two text-based files, both XML, and significantly less important (oh noez, the glossary failed to populate).

The goal is to prevent the client from opening the child swfs.

Originally posted by Draco18s:

Once again, external swfs. There’s only two text-based files, both XML, and significantly less important (oh noez, the glossary failed to populate).

The goal is to prevent the client from opening the child swfs.

a simple XOR cipher on each byte (i recommend 128 <= x <= 255) will make the plain-text files unintelligible (and less likely they’ll modify it as with the plain XML) and prevent the child SWFs from being executed without decryption – this is not a security measure, just an obfuscation method. it’ll take someone intelligent less than a minute to fuck around with it, but will keep 99% of users from screwing with it

I’ll suggest it as an option, though idealy I’d love to be able to create a password protected zip file (I did find a zip-file AS3 API, but no password support).

Maybe some sort of communication – validation between the child swfs and the container swf? So if someone tries to open the child swf – it detects no container swf permissions and closes itself and/or does nothing (maybe displays a message “please open via filename.swf”)? Whereas if they open the container swf it loads the other swfs within itself, and sends each an “okay” message?