Bitmapdatas dynamically loaded from zip are not trusted locally and thus uneditable

[tom_wilson]

This is a very strange problem.

I am using external resources for a game I am making. One of the resources is a zip file containing 100 images (thumbnails). The purpose of this zip is simply that it will make loading these resources much easier, simpler, and as I am storing these resources on Amazon S3, significantly cheaper.

This has been working without a hitch, until I moved and ran the swf in a non-trusted location.

Now, when I try and load the first thumbnail I get this:

Loader/get content()

SecurityError: Error #2148: SWF file file:///C|/Users/Tom/Desktop/Jigsaw.swf cannot access local resource file:///C|/Users/Tom/Desktop/Jigsaw.swf/[[DYNAMIC]]/1. Only local-with-filesystem and trusted local SWF files may access local resources.

This occurs when I try and access Loader.content, which I need to do as some bitmapdatas need to be altered after loading.

I've run into a similar error when originally trying to load external resources and converting them into bitmapDatas. This was fixed using a policy file.

I figured that the policy file was the problem, but then I tried embedding the .zip into the swf instead of loading it externally, like this:

[Embed(source="../res/images/thumbnails.zip", mimeType="application/octet-stream")]

But even that threw up the same error.

What's happening is a byteArray is cleverly being converted into a BitmapData, but in the process it becomes untrusted by Flash.

I cannot find any way of converting this byte.

I've tried using several different as3 zip class packages, but they all fall at the same hurdle.

Here's the essential code:

var zip:FZip = new FZip();

zip.loadBytes(zipData);

var file:FZipFile = zip.getFileByName("image1.jpg");

var loader:Loader = new Loader();

loader.loadBytes(file.content);

root.addChild(loader);

loader.addEventListener("click", function(e) {

          var bd:BitmapData = e.target.content.bitmapData;

          bd.applyFilter(bd, bd.rect, new Point(), new BlurFilter(20, 20, 1));

} );

This is the part that really makes this weird... When I test this, it works fine, when I upload it online, fine. The only time I get the error is when the SWF is being run locally, but in an untrusted location.

Clearly, these security measures are going a bit fudged if it works without a hitch online, but doesn't locally, you'd expect it to be the other way round.

As far as I can tell there is nothing potentially dangerous with my code. It's from a trusted location (policy file is working).

I've found another unfortunate person who came across the same problem but never got an answer:

http://www.actionscript.org/forums/showthread.php3?t=261853

I've tried EVERYTHING. bitmapdatas dynamically loaded from zips are uneditable for no apparent reason.... unless the swf is being opened in a trusted location or anywhere online.

[kglad · Accepted solution]

if you want your local files to be trusted, add it to the trusted files setting:  http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html

[tom_wilson]

I have tried this and it works, but it doesn't solve the problem that anybody who plays the game outside of their internet browser will get errors whenever Loader.content is accessed.

I know this is not a massive problem but it still worries me, also it's apparent that this is a flashplayer bug when generating bitmaps from bytearrays. If the bytearray was loaded from a trusted source, then the bytearrays extracted from this bytearray (ie, images from the zip) should also be trusted.

The fact it works online but not locally is what really makes this look like a bug, also look at the error:

cannot access local resource file:///C|/Users/Tom/Desktop/Jigsaw.swf/[[DYNAMIC]]/1. Only local-with-filesystem and trusted local SWF files may access local resources

It isn't a local resource like it suggests, it could be embedded, it doesn't make a difference. It's treated like an external asset when it's not.

I should also mention that the second loader I try and access produces Jigsaw.swf/[[DYNAMIC]]/2 and the next one Jigsaw.swf/[[DYNAMIC]]/3

Conclusion: FLASH IS STUPID.

I hope this is fixable because I really need all these images as 1 file, and they will need to be updated often. A zip makes itself ideal for this purpose.

[kglad]

it's not a bug.  you're crossing a security sandbox.

[tom_wilson]

I can see no reasons why these would be regarded by Flash as insecure.

I can load bitmapdatas from pngs and jpgs from my server, why is a zip containing the same files insecure?

Anyway, how do I dynamically load resources from a trusted zip file when running the SWF from an untrusted location then?

Or in other terms, is there any way to load a bitmapdata from a bytearray generated during runtime when running the SWF from an untrusted location?

[kglad]

i don't really understand what the security risk is (and whether there is a known exploit or just a theoretical risk), but i know adobe perceives a security risk with bitmapdata loaded across a security sandbox.  from the flash help files (my emphasis):

Loader security

When you use the Loader class, consider the Flash Player and Adobe AIR security model:

• You can load content from any accessible source.
• Loading is not allowed if the calling SWF file is in a network sandbox and the file to be loaded is local.
• If the loaded content is a SWF file written with ActionScript 3.0, it cannot be cross-scripted by a SWF file in another security sandbox unless that cross-scripting arrangement was approved through a call to the System.allowDomain() or the System.allowInsecureDomain() method in the loaded content file.
• If the loaded content is an AVM1 SWF file (written using ActionScript 1.0 or 2.0), it cannot be cross-scripted by an AVM2 SWF file (written using ActionScript 3.0). However, you can communicate between the two SWF files by using the LocalConnection class.
• If the loaded content is an image, its data cannot be accessed by a SWF file outside of the security sandbox, unless the domain of that SWF file was included in a URL policy file at the origin domain of the image.
• Movie clips in the local-with-file-system sandbox cannot script movie clips in the local-with-networking sandbox, and the reverse is also prevented.
• You cannot connect to commonly reserved ports. For a complete list of blocked ports, see "Restricting Networking APIs" in the ActionScript 3.0 Developer's Guide.

However, in AIR, content in the application security sandbox (content installed with the AIR application) are not restricted by these security limitations.

For more information related to security, see the Flash Player Developer Center Topic: Security.

p.s.  i work-around all the flash cross-domain issues by using an executable gateway file on the swf's server which prevents flash from detecting the cross-domain issue.

[tom_wilson]

"If the loaded content is an image, its data cannot be accessed by a SWF file outside of the security sandbox, unless the domain of that SWF file was included in a URL policy file at the origin domain of the image."

This is the thing though, I have provided the crossdomain file and it is working flawlessly when I load images directly, ie: www.gpstudios.com/image1.jpg

However, if I load www.gpstudios.com/images.zip using a class package like FZip and then extract a jpg as a bytearray using a loader to convert it into a Bitmap object, THEN it gives me the security error when I try and access Loader.content, despite having a valid policy file in place. images.zip is trusted, but any image data extracted from it apparently isn't.

Now this is clear, would you not agree this seems like a Flash player bug / problem with their current security policies?

[kglad]

you might be correct, but i can't say.  i can see that you're not using the latest version of fzip, http://www.as3commons.org/as3-commons-zip/index.html

i don't know that using the latest version will obviate the problem you are seeing, but it seems prudent to update.

[tom_wilson]

kglad wrote:

you might be correct, but i can't say.  i can see that you're not using the latest version of fzip, http://www.as3commons.org/as3-commons-zip/index.html

How do you know that?

Edit- Oh I thought this was a different class package to FZip. I tried it and it didn't work either.