This article describes how you can use SWF files as widgets in BEML that have been protected by utilities that prevent decompilation. Before we start, just a couple of things I’d like to point out:
- This article is NOT a review of the effectiveness of SWF Protection tools, there are plenty of (endless) discussions on that topic on specialized forums.
- This approach is NOT my recommended one for creating User Generated Content upload widgets. I still believe using a secured mid-tier upload server is a better model. Event with a protected SWF, a proxy tool like Charles or WireShark will give a hacker all the information he needs to get your token if you do not protect your sensitive Widget/Server communications.
Why would you do this?
The short answer is that the SWF format is a pseudo-compiled, documented file format. This implies that it is relatively easy to reverse engineer a SWF file. Just Google “swf decompilers” and look at the results. There are literally dozens of tools that allow anyone to retrieve the complete source code of a SWF. Regarding BEML Widgets, this may pose some security threats if for example you want to:
- Create a video upload widget that uploads straight into your Brightcove account. Again, SWF protection by itself is NOT the approach I would recommend, as this requires including/sending a Write Token to use the Media API in your SWF.
- Create a widget that interfaces with your backend and that contains configuration information you want to give some level of protection
- Create a widget that represents a considerable investment or effort, and by consequence you want to protect from being duplicated
to name but a few.
Read the rest of this entry »
No Comments »
Simple example of how to make the video played dynamic for a Brightcove Video Player without a Play List.
Read the rest of this entry »
No Comments »

This code snippet shows how to create a Brightcove player plugin for the WordPress CMS that allows easy placement of videos within posts using the syntax [ brightcove video="123456" /].
Read the rest of this entry »
2 Comments »
Like most Flash developers, I was grinding my teeth when MySpace unilaterally decided to disable getURL() calls from Flash movies on their network. I was -and still am- convinced that the least MySpace could have done was to set up a program for Flash widget designers with good intentions in stead of hurling everyone back to the stone age (read: HTML links).
Today I finished a new artist site for MySpace and I decided to dig a little deeper into the problem. But first, maybe for those not familiar with the origin of the problem, a little overview.
Read the rest of this entry »
8 Comments »
PEAR is a framework and distribution system for reusable PHP components. The code in PEAR is partitioned in “packages”. Each package is a separate project with its own development team, version number, release cycle, documentation and a defined relation to other packages (including dependencies). Packages are distributed as gzipped tar files with a description file inside, and installed on your local system using the PEAR installer.PEAR contains PHP classes that are perfect for serializing data to be passed to a Flex application. Unfortunately, there is currently no package that would allow automatic installation for a Flex/PHP developer that wants to use the PEAR XML Serializer functionality.
In this article, I am going to describe how to do a local tweak and installation of the PEAR XML classes on a server that does not have PEAR pre-installed. Even if your server has PEAR installed, this approach will work. Read the rest of this entry »
1 Comment »
I’ve been creating Flash / PHP web sites and applications for years, but I am relatively new to Flex. After browsing the Adobe PHP samples for Flex earlier this week, I couldn’t help but notice that some of this code could prove extremely hazardous if used in a public Flex site. This is no criticism, but since these examples will be read by virtually anyone who want to use the PHP / Flex tandem, it’s probably not a bad idea to go over the security basics. I just love PHP. It’s a great language for rapid development of dynamic site and application backends. Combined with the RIA power of Flex 2, there’s no end to what you can do. But – as for every web programming language, security considerations for designing even the simplest web sites with Flex and PHP are crucial and often overlooked. This article makes some assumptions that on first look may linger on paranoia, but you should always remember the following when developing PHP / Flex apps:
- It’s dead easy to decompile a Flex or Flash file. The file format is public and many decompilers exist.
- It’s equally easy to monitor requests and results from a Flex app to and from the server. This and the above make it a breeze to get the URI’s and expected parameters for your PHP scripts.
- Most Flex/PHP tandem applications will expect and return clean, simple XML data. This data can be parsed easily to see if any security holes can be exploited.
Many PHP features can lead to security holes. The PHP.net site as well as independent security initiatives (such as phpsec.org, the PHP Security Consortium) have identified a small dozen of “Top Security Blunders” that keep popping up. We’ll go over these from a Flex perspective in this article. Understanding each possible flaw will help you avoid making the same mistakes in your PHP applications. Read the rest of this entry »
3 Comments »