Theft-proofing a SWF file

If you have been around the web for any length of time, you know how easy it is to grab a SWF file. In fact, a very common discussion around this practice is, "Hey, I have a SWF file I have grabbed. How do I decompile it to get at the source code?" I am not going to get into the morality of this discussion because there are very specific and valid cases for this practice, but, on the whole, decompiling a SWF file is not regarded as acceptable.

This raises a rather interesting question: "I have invested a lot of time and money into the development of the SWF file. How do I stop it from being decompiled?" If you use the Flash Media Server 3.5, this is extremely easy.

Here's how:

1. Create a new Flash CS4 Professional document.
2. Add an FLVPlayback component to the stage and set its source parameter to rtmpe://localhost/vod/mp4:Vultures
3. In the skin parameter, select SkinUnderPlaySeekFullscreen.swf.
4. Add a new layer and add some text to the top of the stage or draw a simple shape into this layer. This text or shape will become massively important at the end of this exercise.

5. Go ahead, test the movie. Everything works well and the text is above the video (see Figure 3).

   

   Figure 3. The video playing as expected

   Note: Remember, as I pointed out in a previous installment of this series, you link to MP3 and MP4 files in the vod folder by adding the media type followed by a colon and the file name, without the extension. If the file doesn't work, check to be sure that you have not added a space between the colon and the file name.

   Protecting the SWF file from theft or decompiling is a really nifty feature of the Flash Media Server 3.5. The thing about this feature is, it is not enabled by default. You are going to need to make a couple of changes to enable it.

   The first change is to the XML file that drives this feature. If you are not terribly comfortable with playing with application files, feel free to copy the file you'll be changing to the desktop beforehand. This way, if you make any mistakes, you can simply replace the changed file with the original on the desktop.

6. Save the file and navigate to C:\Program Files\Adobe\Flash Media Server 3.5\conf\_defaultRoot_\_defaultVHost_ and open the Application.xml document in the _defaultVHost_ folder.

   Note: I will be using Dreamweaver CS4 to display the XML. Feel free to use this application or any other text editor to make the changes.

7. Scroll down to line 726. If you don't have line numbering, simply use swf as the search term and you will be taken to this section.

8. All you need to do now is to change the word false to true, as shown in Figure 4, in the <SWFVerification enabled="false"> tag.

   

   Figure 4. Changing the value to true to turn on SWF verification

   Don't save the file just yet. There is another aspect of this process you need to know.

   You can't just merrily turn on SWF Verification and expect it to work. You also need to place a copy of the SWF file in a very specific location. If you scroll down through the XML document you will notice there is a <SWFFolder></SWFFolder> tag. If you read the commented text in front of the tag (see Figure 5), you will realize you need to create a folder—the suggested name is SWFs—and place the SWF file you will create into this folder. What will happen is, the server will first go to the folder containing the SWF file and validate that it is, indeed, the correct one.

   

   Figure 5. "Locking down" a SWF file by putting it in a specific folder

9. If you scroll down to the next section of the XML file, you will discover that you can also specify the Flash Player version to be used. Don't play around here. The only version that can be used is Flash Player 9,0,115 or later. This feature is here in order to accommodate future versions of the Player.

10. Scroll down to the <Cache> tag area. You will see that the SWF file will live—the TTL tag actually means Time To Live—in the cache for 1440 minutes, which is 24 hours. If you think this is a tad long or you are overly paranoid, you can change the value. In fact, change the value to 5. What you have done is to say the SWF file will only live in memory for five minutes (see Figure 6).

    

    Figure 6. SWF living in the cache for only five minutes

11. Save the file and quit the application used to edit it.

Having changed the server configuration, you are going to need to restart your FMS 3.5 server. Here's how:

1. Launch the Flash Media Server Admin Console and, when it opens, click the Manage Servers button.

2. At the bottom of the servers pane are five buttons. The one in the middle, (it looks like a circular arrow; see Figure 7) is the one you need. It is the Restart server or vhost button. Click it. You will be asked if you want to restart the server. Click Restart. This will turn on SWF Verification.

   

   Figure 7. Clicking the middle button to restart the server

3. Return to Flash CS4 and publish the Vultures movie. Open the HTML file in a browser. The video won't play. In fact, what you are supposed to see is the bars. What you are seeing (as shown in Figure 8) is exactly what happens when a SWF file can't be validated and the server denies the stream.

   

   Figure 8. What you see when the SWF file can't be validated (you've done nothing wrong)

4. Now, to get this thing working, you need to copy and paste the SWF file from this project into the folder you pointed to when you were enabling SWFVerification in the Application.xml file. To create that folder, navigate to C:\Program Files\Adobe\Flash Media Server 3.5\applications\vod and create a new folder in the vod folder named SWFs.
5. Get yourself back to the folder containing the HTML file you published and open the HTML file in a browser. The video plays!

6. To really see how this feature rocks the house, return to the Flash project and move the object in layer 2 to another location on the stage, as shown in Figure 9. What you have just done is simulate a "burglar" swiping your SWF file, decompiling it, and otherwise playing with it.

   

   Figure 9. The burglar in the house

7. Publish the file using the same name and open the HTML file in a browser. What you will see is shown in Figure 10. Essentially, FMS 3.5 has looked at the current SWF file, headed over to the SWFs folder and asked a simple question: "Does the SWF file in this folder match the SWF file that is currently playing?" The answer is a resounding "No," and the result is the denial of the connection request.

   

   Figure 10. Stream denied because the two SWF files don't match and can't be verified

Finally, here are a few details you need to know:

• If you set the <SWFVerification enabled="true"> tag, then you have turned on this feature and all SWF files you create locally will need to be verified. If you don't think you will ever use this feature, set the value back to false when you finish this tutorial.
• If you leave the verification feature turned on, make sure that every SWF file that uses FMS 3.5 is copied to the SWFs folder. If you don't, nothing will work—and I suspect Adobe tech support is in for a few irate phone calls.

I have shown you in this article how to work locally. If these two features are critical to you, talk about them with your ISP or FVSS providers regarding what you need to do in order to keep the "burglars out of the house."

Where to go from here

This tutorial has shown you a couple of ways to protect your content. One of them is relatively simple—RTMPE encryption of the video stream—while the other uses the new SWF verification feature of Flash Media Server 3.5. If this subject has caught your attention, here are a couple of other articles that will get you going:

• Lisa Larson-Kelley goes into greater depth around this subject in Scaling and securing streaming media applications with Flash Media Server.
• If you really need industrial strength protection, you might want to look into Flash Media Rights Management Server. Read Laurel Reitman's overview.

The next article in this loose series covers basic audio streaming using the FLVPlayback component as well as ActionScript 3.0.

Page 3 of 3

Previous Page