{
A friend of mine was working on a CD he wanted to make, with a bunch of different swf presentations. He wanted to know if its possible to make the various swfs only load up through a single .exe file, and to prevent people from opening up those swfs outside of his main presentation.
This seemed like a very interesting challenge, and I had thought that the only way to do this was to make some c++ program that would encrypt the files and also load them in, save them out as swfs, then somehow send them to the main .exe as swfs, and then delete them when done. However, it turns out there is another way of doing it. This other way that I discovered uses only ActionScript, and now thanks to AIR I was able to make a small app to streamline the process a bit.
The method is best described by the person who (I think) came up with it. You can read about his method here.
I've decided to put the .air file up on my server to share it with others, if they find some need for it.
There are other such apps out there, and likely they work better. However, the project my friend was doing was dealing with over 100 external swfs, and I wanted to be able to do it in a large batch.
The way the program works, is this: You select an input directory, then you select an export directory. The program then searches for all swfs in your import directory that don't have the name "enc" in it. It then turns all these swfs into XML files with the name (yourSwf)_enc.xml and places those files in the output directory. Interestingly these XML files are twice the size of the SWF files. Another time, I'm going to look into making these smaller, or perhaps figureing a better method all together. In the meantime though, for just a few hours of work, this was way fun, and I thought I would share.
}
Interesting. It doubles the size since you are converting the file from binary to hex. Each byte of the original file is represented by two hex digits which each take a byte(assuming your xml file is UTF-8).
ReplyDeleteIt isn't encryption, just simple obfuscation. Most programmers could write a short program to read the xml file and reproduce the original file. There are likely even websites that will convert between hex and binary. But it should stop your typical layman user from getting at the files.
I assume you could write a simple flash encryption pretty easily. Define a contant byte array with some arbitrary value--this is your key. Load the file to a byte array, as you already do. Write a loop to XOR the key with the entire byte-array. Then write the byte-array to a file--this is your encrypted version.
To decrypt--just do the reverse: load the encrypted file, XOR with the key...
That is what I did in my first attempt. Now, perhaps I am just doing it wrong, but when I attempted to load my encrypted swf I got an error saying "Unknown type"
ReplyDeleteIt seems as though I need to encrypt most of the swf but leave the headers that identify the file as a swf type for the flash security settings. But I need to look up this issue more indepth to find out. I saw a few blog posts where people claimed to get it working, but I found two common problems.
1. It was the old flash player with less security restrictions.
2. It was a stream loaded in through AMF, and not directly from the hardrive.
But I agree, that this is simple obfuscation as it stands. And it shouldn't be too hard to actually encrypt the bytes that get written to the XML and then decrypt them when they are read in again. However, if I'm not mistaken, you don't want to publicize that process, and I think you really want to a use a passkey system for that. I might try including that in the future. Though I'd much prefer to find a method that works without increasing the file size. Even better, would be if I could figure out a method of compression at the same time.