Articles Archive
Articles Search
Director Wiki

Stopping DCR Thieves

January 6, 2004
by Gary Rosenzweig

As a Shockwave game developer, one of my many concerns is protecting my games from DCR thieves. It can be extremely easy for someone to take your Shockwave content and place it on their own site, taking the credit and profit from you.
My methods for protecting my Shockwave games have evolved throughout the years and I now have a variety of techniques that I use. But first, lets start by looking at who steals Shockwave content and how they do it.

Who Are These Thieves?
I can divide the types of people who steal Shockwave content into three groups. The first is the "Completely Clueless" group. These are people who actually don't realize that they are doing something wrong. They see the Internet as filled with free content and it doesn't matter where the content is or who owns it. If they see a cool animated GIF file or a sound, or a Shockwave game, they think that it is OK to serve it up on their own site. People in this group are rare today, but were common back at the start of the Internet.
The second group, which I call the "Harmless Crime" group, is made up of people who know it is wrong to put someone else's games on their site, but see it as a harmless crime, like driving 1 mile per hour over the speed limit. They don't think about the fact that someone has put a lot of work into making the content and that by stealing the content they are hurting the value of the content. Or, perhaps they just don't care. They see themselves as the "little guy" and you as some faceless corporation and think that you won't notice or care if they steal your content.
The third group is the "Professional Thieves" group. These are people that know perfectly well what they are doing and that it is a crime. But they are doing it anyway to try to profit from the content somehow.
The first two groups are easy to stop. Even the slightest security measure will prevent them from stealing your content. If they do steal an unprotected piece of content, usually a simple email will bring an apology and immediate action. The third group is usually also easy to deal with -- except for a few.

How Do Thieves Steal Your Content?
An unprotected game is easy to steal. There are two basic ways of doing it. The first is to take your OBJECT/EMBED tags right from your Web site and place that code in HTML pages on the thieves' site. If you use absolute URLs (starting with http:// and containing the complete path to the .dcr file) then they don't even need to alter the code. Even if you use relative URLs, all they need to do is to change the "src" tags to the full path that leads to the .dcr and they are set. The content now appears in their Web page, on their site. To their visitors, the game appears to be on their site completely.
This type of stealing is a double problem. First, the thief gets your content. Second, the bandwidth expense is all yours. Some of these stealing sites get a lot of traffic (you might too if you had 1,000+ games) and you can suddenly find yourself serving up your own content 10,000 times a day, but not benefiting from any of it since it appears on someone else's site.
This method of stealing is also very easy to prevent, after-the-fact. Since the thief is linking to content on your Web site, all you need to do is to change the location or name of the .dcr file. Now the thief is no longer linking to your content, but has a broken link. You can even substitute a .dcr that will use gotoNetPage to redirect the user to your site, and the real location of the game.
The thief can strike back by altering the OBJECT/EMBED tag to match your new URL for the .dcr, but that is unlikely. All three groups of thieves tend to rarely update their sites and don't seem to check for broken links very often. If they do play hide-and-seek with your changing URL, they will most likely stop after the first two or three leaps as it becomes a hassle to them. They want free content, so working for their content is not very appealing.
The second method of stealing content is the most problematic one. This is when a thief will take your .dcr file and place it on their server. They can do this by finding the .dcr in their browser cache, or they can use a network program to download it given the URL of the .dcr. Heck, Director can be used to do this with the downloadNetThing command.
Another way that thieves get content is by downloading .dcr files from pirate FTP sites or buying cheap CD-ROMs filled with pirated .dcr content. These things exist. I've gotten "apology" responses from people who I have sent warning messages to that claim that they got my .dcr file from a CD-ROM that they purchased that contained hundreds of such files and claimed they were free to use on their site. This turns some in the "Professional Thieves" group into the "Completely Clueless" group as they think they have purchased the games legitimately. Although I would tend to put these people more in the "Harmless Crime" group as I'm sure that somewhere in the back of their mind they known that the games are stolen.
The stolen .dcr file is a much harder type of thievery to deal with since you must have placed any security measure in your content prior to the act of piracy. Once an unprotected game has been stolen, the only way to deal with the thief is by using nontechnical means.

Protecting Your Copyrights
Copyrights are automatic. When you create something, it becomes yours. Any lawyer will tell you that it is a good idea to register your copyright, especially if you plan on suing someone. But suing is not a concern with most .dcr thieves since they don't have any defense -- they are guilty and they know it.
It is always a good idea to place a copyright notice on your .dcr. So at least no one can claim you are lying when you say they stole the content. I also like to include logos and "create by" text in the content. This makes it obvious to many people that see the stolen content that the content is in fact stolen. Professional thieves may decide to stay away from your content as they think you might be trouble. If you have a trademarked logo, you should include that in the content as well, since it adds to the list of crimes that a thief is committing.
The first thing I do when I find a stolen piece of content on a site is to check out the whole site. I try to get an idea if this is a personal homepage, a small one-man operation, or the work of a group or company. For the smalltimers, a simple small email is all that is usually needed. To get their email address, I search the site. If it is not there, I search a whois database for the domain name owner.
In the email, I try to be polite. My goal is to get the content removed, not to start a war. Half the time I get an apologetic email response, and the other half of the time I get no response, but the content is quickly removed.
For the sites that look like they are a bit professional, or at least the work of someone trying to profit from the content, I send email to a wider group. I usually look for all of the email addresses I can find at the site. I also grab any email addresses from a whois lookup on the domain. From the whois lookup, I can usually tell where the site is hosted and then go to that Web host's homepage. Often, I find an email address for their legal department or such. I include all of these addresses in the email "to" list so that the real thief can see that I am serious. I make this email much more professional and to-the-point. I usually give a deadline, like 48 hours, to remove the content. I also correctly state that the content is protected by International Copyright Laws. If you have a lawyer at your disposal, you may want to get him or her to draft your a short simple statement to send to these people.
This gets most of the thieves to stop right away. A few persist. But then I usually get in touch with someone at their hosting company and then the pressure is really on. I've never had to resort to an actual legal action, but I'm sure that day is coming and I'm ready for it.
All of these problems stem from old copies of my games that were originally stolen many years back, before I implemented my technical security measures. If you start using these measures from the beginning, you shouldn't have any problem.

Securing Your Shockwave Content
There are many techniques I use for securing my games. Each one has its flaws. But used in combination, they can stop thieves quite effectively.

Technique Number 1: Using Only Relative Paths
When you specify your URL in the OBJECT/EMBED "src" tags, you should never use absolute paths (like ""). Instead, your .dcr should be at the same domain as the Web page, and your should use a relative path (like "content/mygame.dcr").
Then, inside your content, you can use externalParamValue("src") to get the content of the "src" tag. If the "src" tag starts with "http://" then you know that the OBJECT/EMBED tag calling it is not yours and someone is trying to steal your game and make it appear in their Web page.
This almost completely eliminates the first type of stealing, where someone tries to use the .dcr on your site, instead of stealing the .dcr itself.

Technique Number 2: Checking the Movie's Path
You can use the Lingo property the moviePath to see where the .dcr file is located. If it is not your domain, then you know the content has been placed on another site.
Be careful to check the path thoroughly. For instance, you may be used to going to your site at, but others may try it at So use the Lingo starts comparison to check for both. Using the Lingo contains comparison doesn't work as well as a thief can simply make a path like "".
By using technique numbers 1 and 2 combine, you can take care of 90 percent of the problem. But there are ways for clever thieves to get around them. Other techniques act as backup.

Technique Number 3: Security-Enhanced Loader Movies
A loader movie is always a good idea, even if it is just to show a progress bar as the larger .dcr loads. But you can also do your security checks, like the "src" tag and the moviePath check, in the loader movie. Then, simply set a global, like "gSecurityPassed" to TRUE before using gotoNetMovie to jump to the content-containing .dcr with the content. The content .dcr will then check this global and only play if it is set to TRUE.
Global variables can be a little insecure as well, so you might even want to get more complex. For instance, you can set a global to an instance of a parent script. The script can gave a "checkSecurity" hander in it that performs techniques 1 and 2. But the loader doesn't run that code, instead, the content .dcr does it on prepareMovie. If that function doesn't return a TRUE, then the movie doesn't play. If the global containing the instance of the script isn't set, then it also doesn't play.
The great thing about using a loader movie is that you can have one loader movie that works for all of your content. You can use the "sw1" tag or another tag to pass the name of the .dcr to load. Then, then loader movie performs the security check. Each content .dcr must get the proper signal (either a global or instance script) or it doesn't run.
Then, since all of your security is centralized, you can build in other things like a timer. A timer would check the date using the systemDate and then fail if the year is not the current year. For instance, a loader movie might be set to only work in 2004. Once Jan. 1, 2005 comes, people who stole that loader movie as well as you content will not be able to run the loader, so the content will not work either. You will then switch the loader movie every Jan 1, but the thieves will not know that.

Technique Number 4: External Security Files
It might be easy to see the name of the .dcr in the OBJECT/EMBED tag, but not so easy to see the names of other files that your Shockwave movie might be calling. You can use getNetText, postNetText, external cast members, or even external cast libraries. Any of these can contain information or scripts that can be used to foil thieves.
For instance, you can use a simple getNetText call to look for a companion text file on the server located at a relative path. If this text file is not found, then the .dcr stops. If The text file is found, then it can contain information, like a code, that must be correct for the .dcr to continue.
A thief might notice that the content they have stolen is trying to access a file on their server and not finding it. They can then return to your site and try to grab that file. A cast library comes in handy because it has its own path, as does an external media member, like a bitmap. So you can check that path, after it has been loaded, to make sure it is on your server. The thief can't change your .dcr to access the cast member or cast on your server, because the Lingo code in the .dcr is looking at a local relative path.

Technique Number 5: The Secret Number
Here is a very advanced technique that requires some server-side programming. It works very well if you are using a serving technology like ASP, JSP or PHP.
You only serve up an OBJECT/EMBED tag in a dynamically created by whatever technology you use, say PHP. This dynamically-created page includes a special number as a tag in the OBJECT/EMBED tag, like "sw1" or such. If the number is not included, then the content stops. If the number is there, then the content uses getNetText with an absolute path to call another script on your server. This script will return the same special number. If the getNetText number matches the "sw1" number, then the movie continues.
So far, this doesn't stop a thief at all. They copy the OBJECT/EMBED tag, with the special number and the movie confirms that number with your server. The content runs fine. But then you change that number. Now, the thief is running with an OBJECT/EMBED tag using the old number and your server returns a different number to the getNetText call. So all you have to do is change the number every once in a while and you have a very effective antitheft system. You can even program your server to change the number daily or at random times if you know how.

Security Measure Actions
The five different security measures outlined above work great. And there are even more that I'm sure other people use. What I left out of most of the above information is how a clever thief can get around each one. I don't want to write a how-to article for thieves here, so I won't mention the workarounds.
So now that one of your security measures detects something amiss, what should it do?
The main thing is to execute a halt command. This will stop a movie in its tracks. But before a halt command, you can do some other things to make it even more troublesome for thieves.
You can use a gotoNetPage to take the Web user to your site. This will put the surfer where they wanted to go in the first place -- to your game. It can also relay to you information about where the stolen game was located if you know how to capture server referer (sic) variables. Or, you can simply take the user to a page that informs them that the game was stolen and asks them to report the site to you. You can then use this information to check to see if more of your content was stolen -- or perhaps the content of your friendly competitors.
If you don't want to use the gotoNetPage trick, you can always throw up an alert box stating that the game was stolen. But this can also be a tool for thieves. They can use the alert to quickly determine if their workarounds worked and tweak them as necessary.
A better way might be to simply issue a halt command. This doesn't let the thief know that they triggered your security code. Instead, they might think that they simply broke the game or got a corrupt version of it. It gives them no clues.

Further Protections
Stealing a .dcr file for use on a Web site is not the only thing to be afraid of. Someone with a copy of Director, most likely a pirated copy, could take your .dcr and build a projector with it. Then they could distribute your content as a downloadable.
Preventing this is easy. Just check the Lingo property the runMode and make sure it is not "projector". Of course, if you are checking the moviePath, then you will also get good information that will lead you to identify projector playback.
It is always a good idea to implement as many of these security measures as makes sense. Remember that it is not possible to make content 100% secure, but you can make it so hard to steal that no thief will find it worth the trouble.
Gary Rosenzweig is the Chief Engineer, founder, and owner of CleverMedia, a game and multimedia development company in Denver, Colorado. He is the author of ten books on Macromedia Director and Flash, including his latest, Special Edition Using Director MX.

Copyright 1997-2017, Director Online. Article content copyright by respective authors.