Part I: “Applying ROT128 Encryption On ByteArray”
Part II: “Applying ROT128 Encryption On Embedded/Module SWFs”

In “Saving XML As Binary”, we looked at how text XML can be stored in a ByteArray object so that it can be compressed and made non-human-readable. In this post, we look at how you can integrate ROT128 into the XML-to-ByteArray-to-XML routines. Binary XML is used only as an example; you can definitely apply the same concept to other binary data.

XML-to-ByteArray:
ROT128 is applied after the XML is stored and compressed as ByteArray.

var data:ByteArray = new ByteArray();
data.writeUTFBytes(xmlData); // xmlData is original XML string
data.compress();
// BEGIN ROT128
var j:int = data.length;
while (j--)
{
	data[j] += 128;
}
// END ROT128
new FileReference().save(data, "bindata.xml"); // default name "bindata.xml"

ByteArray-to-XML:
With ROT128 applied, the saved binary file is no longer a valid compressed ByteArray – it cannot be uncompressed and converted back to XML without first reversing the encryption on the raw data.

// event handler for Event.COMPLETE of URLLoader loading external XML
function on_XML(evt:Event):void
{
	var data:* = URLLoader(evt.target).data;
	if (data is ByteArray)
	{
		try
		{
			// BEGIN ROT128
			var j:int = data.length;
			while (j--)
			{
				data[j] += 128;
			}
			// END ROT128
			data.uncompress();
		}
		catch(e:Error)
		{
		}
	}
	data = XML(data);
	// handle data as XML
}

Partial Encryption
In order to make the process of reversing ROT128 encryption less predictable, you could vary the conditions under which the encryption is to be applied.

Here is an example (alternate bytes):

// BEGIN ROT128
var j:int = data.length;
while (j--)
{
	data[j] += 128;
	j--; // skip next byte
}
// END ROT128

Another example (first 1024 bytes):

// BEGIN ROT128
var j:int = (data.length < 1024) ? data.length : 1024;
while (j--)
{
	data[j] += 128;
}
// END ROT128

Correspondingly, your applications would reverse the encryption under the same conditions. Effectively, these conditions determine the complexity of your cipher and become the “secret key” necessary to decrypt the data.

Conclusion
ROT128 is a weak encryption technique that you should not use to protect sensitive data. However, the light-weight algorithm can be used to make binary blobs inaccessible to unauthorized parties while allowing your applications to easily restore the data when needed.

This method of encryption may seem amateurish, but it does what it is supposed to do well enough while remaining light-weight and flexible.

It worked well enough for Julius Caesar, after all.

Some time back, we posted a simple technique for hiding assets and AS3 code from prying eyes by embedding one SWF within another SWF. In this post, we revisit that topic and look at how ROT128 can be used to provide an additional layer of protection.

Step I: Apply ROT128 To Actual SWF
Using the following code, we will apply ROT128 to the SWF that is going to be embedded:

// assuming the raw data of the SWF has been stored in a variable swfBytes
var j:int = swfBytes.length;
while (j--)
{
	swfBytes[j] += 128;
}

The following shows a simple tool you can create to load a SWF file, apply ROT128 to it, and save the encrypted file.

• Flash Player 10 is required.
• Click the Browse button to bring up a native file dialog.
• Select a Flash Movie (.swf) file.
• Click the Save button that will be shown after loading the SWF file.

(80×80 SWF, 2KB)

You can verify that encryption has been done by running the saved SWF file “ActualSWF.swf” – it should show a blank screen.

Remember, applying ROT128 twice restores the file, so the tool can also be used to restore a previously ROT128-encrypted file if the algorithm used was the same (same n increment, same conditional loop).

The ROT128SWF class:
(please feel free to customize to fit your own requirements)

package 
{
	import flash.display.Sprite;
	import flash.display.Stage;
	import flash.display.StageAlign;
	import flash.display.StageScaleMode;
	import flash.events.Event;
	import flash.events.MouseEvent;
	import flash.events.IOErrorEvent;
	import flash.net.FileFilter;
	import flash.net.FileReference;
	import flash.text.TextField;
	import flash.text.TextFieldAutoSize;
	import flash.text.TextFieldType;
	import flash.text.TextFormat;
 
	public class ROT128SWF extends Sprite 
	{
 
		// ** minimalist text button **
		private var opButton:TextField;
 
		// ** browse/load/save **
		private var swfFile:FileReference;
 
		public function ROT128SWF():void 
		{
			if (stage) init();
			else addEventListener(Event.ADDED_TO_STAGE, init);
		}
 
		private function init(e:Event = null):void 
		{
			removeEventListener(Event.ADDED_TO_STAGE, init);
 
			// entry point
			stage.align			= StageAlign.LEFT;
			stage.scaleMode			= StageScaleMode.NO_SCALE;
			stage.showDefaultContextMenu	= false;
 
			// ** draw minimalist text button **
			opButton			= new TextField();
			opButton.autoSize		= TextFieldAutoSize.LEFT;
			opButton.background		= true;
			opButton.backgroundColor	= 0x000000;
			opButton.defaultTextFormat	= new TextFormat("Tahoma", 14, 0xFFFFFF, true, null, null, null, null, null, 4, 4);
			opButton.selectable		= false;
			opButton.text		= "BROWSE";
			opButton.x			= (stage.stageWidth - opButton.width) * 0.5;
			opButton.y			= (stage.stageHeight - opButton.height) * 0.5;
			addChild(opButton);
 
			// ** button click listener **
			opButton.addEventListener(MouseEvent.CLICK, on_buttonClick, false, 0, true);
		}
 
		/**
		* handle browse or save
		*/
		private function on_buttonClick(evt:MouseEvent):void
		{
			var btn:TextField = evt.target as TextField;
			if (btn)
			{
				if (btn.text == "BROWSE")
				{
					swfFile = new FileReference();
					swfFile.addEventListener(Event.SELECT, on_swfSelect, false, 0, true);
					swfFile.browse([new FileFilter("Flash Movie","*.swf")]);
				}
				else if (btn.text == "SAVE")
				{
					if (swfFile)
					{
						// ** BEGIN ROT128 **
						var j:int = swfFile.data.length;
						while (j--)
						{
							swfFile.data[j] += 128;
						}
						// ** END ROT128 **
						new FileReference().save(swfFile.data, "ActualSWF.swf");
					}
				}
			}
 
		}
 
		/**
		* handle browse, load swf file
		*/
		private function on_swfSelect(evt:Event):void
		{
			swfFile.removeEventListener(Event.SELECT, on_swfSelect);
			swfFile.addEventListener(Event.COMPLETE, on_swfComplete, false, 0, true);
			swfFile.load();
		}
 
		/**
		* handle load, change browse button to save button
		*/
		private function on_swfComplete(evt:Event):void
		{
			swfFile.removeEventListener(Event.COMPLETE, on_swfComplete);
			opButton.text		= "SAVE";
			opButton.x			= (stage.stageWidth - opButton.width) * 0.5;
		}
	}	
}

Step II: Embed Actual SWF In Shell SWF
If you have not done so already, please see “Hiding Assets And Code By Embedding SWF Within Another SWF” for the original discussion on how the technique works.

The following is a MainShell class you can use to embed the ROT128-encrypted SWF:

package
{
	import flash.display.Loader;
	import flash.display.Sprite;
	import flash.utils.ByteArray;
 
	public class MainShell extends Sprite 
	{		
		[Embed(source="ActualSWF.swf", mimeType="application/octet-stream")]
		private static const bytes:Class;
 
		/**
		* REMINDER
		* 
		* MAKE SURE THAT THIS SHELL SWF IS PUBLISHED USING THE
		* ORIGINAL WIDTH/HEIGHT DIMENSIONS OF THE EMBEDDED SWF
		*/
 
		public function MainShell()
		{
			var swf:ByteArray = new bytes() as ByteArray;
			if (swf)
			{
				// ** BEGIN ROT128 **
				var j:int = swf.length;
				while (j--)
				{
					swf[j] += 128;
				}
				// ** END ROT128 **
				Loader(addChild(new Loader())).loadBytes(swf);
			}
		}
	}
}

With the above code, the “ActualSWF.swf” file is embedded into the shell SWF. It is then instantiated as a ByteArray during run-time. ROT128 is then applied to the ByteArray before it is loaded into a Loader object.

Why Do This At All?
Hiding assets and code by embedding one SWF within another SWF is simple to implement and so far, there has not been any report on any decompiler overcoming the protection.

In the original post on the technique, I suggested that you could, if you wish, add another layer of protection by encrypting the embedded SWF just in case a decompiler may in future automatically identify a binary blob and “guess” that it is an embedded SWF (and decompile it separately).

I feel that ROT128 is light-weight and simple enough that can achieve that objective. Remember that the objective here is not to overcome meticulous hacking, but merely to thwart possible attempts to implement automatic extraction and identification of embedded binary blobs as separate SWFs.

The above is only an example of how the concept can be applied. As mentioned in the previous post on ROT128, you can also consider applying ROT128 only to part of the file so that the logic for reversing the encryption could be a little less predictable.

Module SWFs
Although the above mentioned only embedded SWFs, you can definitely apply the same concept to module SWFs that will be loaded into your application during run-time. By applying ROT128 to module SWFs, even if they are obtained via unauthorized means such as via the web browser’s cache, they are non-executable (or will just show a blank screen when run) if the ROT128 encryption is not reversed first.

I should also clarify that the term “ROT128″ does not actually exist. The original idea comes from ROT13, a variant of the Caesar Cipher (named after Julius Caesar of ancient Rome who used it to encrypt messages, but it is not clear who first invented or started using the cipher).

ROT13
With ROT13, you obfuscate a piece of text by substituting each character with one that is 13 positions higher up in the English alphabet (A-Z) sequence, with positions wrapping back to the beginning after Z. Therefore, you are rotating the positions (thus the name of the cipher). The choice of 13 positions is used because there are 26 alphabets (positions), which means applying ROT13 twice restores the original text. In other words, the exact same algorithm is used for both encoding and decoding. Effectively, the alphabet A becomes N and vice versa. Likewise, M becomes Z and vice versa, etc.

ROT128
With ROT128, instead of obfuscating text, we will corrupt a ByteArray object by rotating all its byte values by 128 positions each. A byte value has 256 possible positions, and so in the spirit of using the same algorithm for encoding and decoding, we will rotate values by 128 positions. Therefore, 0 becomes 128 and vice versa, 1 becomes 129 and vice versa, 127 becomes 255 and vice versa, etc.

function ROT128(bytes:ByteArray):void
{
	// bytes is ByteArray object to encrypt/decrypt
	// you are modifying the object directly, not a clone
	if (bytes)
	{
		var j:int = bytes.length;
		while (j--)
		{
			bytes[j] += 128;
		}
	}
}

As you can see, the algorithm is very simple. The ROT128 function listed above is intended for reference only. You don’t even really need to create such a function since you can easily sneak the code in-line into the part(s) of your application code where it will actually be used. After all, if your SWF is decompiled, having a function named ROT128() is more likely to alert the hacker to the usage of the cipher.

Partial ROT128
Sometimes, less is more. Instead of applying ROT128 to every byte in the ByteArray object, you may choose to do a variant of that – apply to just the first 50%, last 50%, first and last 1024 bytes, every two bytes, etc. Doing so would make the cipher slightly more complex, and yet requiring only a slight change to the code (the condition of the loop).

ROTn
Instead of rotating by 128 positions, you can choose to rotate by some other number between 1 to 127. Of course, 128 is the only number that will allow you to use the exact same code for encoding and decoding. Using any other number would require opposite operations – if you increment for encoding, then you need to decrement for decoding.

Usage Examples
In the next couple of posts, we will revisit two topics discussed in this blog previously and see how ROT128 can be applied in those scenarios:
(i) Hiding Assets And Code By Embedding SWF Within Another SWF; and
(ii) Saving XML As Binary.

Unfortunately, when targeting Flash Player 9, this clear() method is not available. If you are using a ByteArray object as a data store, keeping a reference to the object and therefore not allowing the object to be garbage collected, do take note that there is no way to clear the contents. This means that the size of ByteArray objects can only be enlarged and never shrunk.

It is important to note that while you can truncate the ByteArray to zero byte by setting its length property to zero, this will not dispose the contents or free up the memory used.

This is actually a rather odd implementation. After you truncate a ByteArray, the bytes stay in memory and is in fact restorable simply by setting the length property back to a non-zero value.

var bytes:ByteArray = new ByteArray();
bytes.writeUTFBytes("ABCDE");
trace(bytes[0]); // 65
trace(bytes[1]); // 66
trace(bytes[2]); // 67
trace(bytes[3]); // 68
trace(bytes[4]); // 69
bytes.length = 0;
trace(bytes[0]); // undefined
trace(bytes[1]); // undefined
trace(bytes[2]); // undefined
trace(bytes[3]); // undefined
trace(bytes[4]); // undefined
bytes.length = 5;
trace(bytes[0]); // 65 ** what the ??? necromancy at work ??? **
trace(bytes[1]); // 66
trace(bytes[2]); // 67
trace(bytes[3]); // 68
trace(bytes[4]); // 69

In my opinion, this implementation is flawed. The Flash Player really should clear the data once the array of bytes is truncated; this should not require a new API method clear() to accomplish. To introduce a new API method that does what setting the length property to zero should have done in the first place really baffles me.

Anyway, rant aside, so that is that – when you truncate a ByteArray, remember that the data is not lost. When targeting Flash Player 10 or AIR 1.5, do remember to call the clear() method instead of attempting to clear the contents by truncating.

Zerofying Bytes
Since the data stays in memory, I reckon it could sometimes be useful to erase the data explicitly, especially if it contains sensitive data:

function zerofy(bytes:ByteArray):void
{
	if (bytes)
	{
		var j:int = bytes.length;
		while (j--)
		{
			bytes[j] = 0;
		}
	}
}

I am not sure if the clear() method in FP10 API does this (or something similar to erase the data in memory) – I sure hope it does.

As indicated in the title of this post, the basic idea here is simply to embed your actual SWF within another “shell” SWF. It is this “shell” SWF that you will then deploy/distribute.

MainShell Class
To embed a SWF within another SWF, you can use a document class like the one below:

package 
{
	import flash.display.Loader;
	import flash.display.Sprite;
 
	public class MainShell extends Sprite 
	{		
		[Embed(source="ActualSWF.swf", mimeType="application/octet-stream")]
		private static const bytes:Class;
 
		public function MainShell()
		{
			Loader(addChild(new Loader())).loadBytes(new bytes());
		}
	}
}

When this “shell” SWF is run, it will
(i) create an instance of flash.display.Loader;
(ii) add that Loader instance to the display list;
(iii) instantiate an instance of the embedded SWF as a ByteArray; and
(iv) load that ByteArray into the Loader instance.

This will work in the same way as loading an external module SWF into a host SWF, but in this case the module SWF is embedded inside the host SWF. This is different from loading external SWFs because any external SWF can still be easily obtained from the browser’s cache and decompiled separately.

This set up will be completely transparent to the end-users – it will look as if the actual SWF has been run.

How This Works Against Decompilers
This protection method assumes that decompilers cannot automatically identify, extract and decompile the embedded binary object as a SWF. Therefore, the assets (classes and symbols) in the “ActualSWF.swf” will no longer be directly accessible by decompilers.

I tried this embedding technique against the trial versions of a couple of decompilers (Sothink and Trillix) and the assets of the embedded SWF (ActionScript classes, artwork, movieclip symbols, etc.) are safely hidden from view.

Since this cost nothing and is so easy to implement, I would suggest you try it out and decide on your own the effectiveness of this. Wrap one of your SWFs in a “shell” SWF as described above, and try to decompile it using one of the decompilers out there. Perhaps the non-trial versions and/or other decompilers I have not tried may be able to defeat this simple layer of protection, but even if they do…

Taking Things Further
While it is possible that makers of decompilers could eventually implement a feature to properly identify, extract and decompile embedded SWFs, you can take things further and make the protection more difficult to overcome.

Instead of embedding the SWF directly, you could run it through some encryption and embed the encrypted SWF – it is mime type “application/octet-stream”, so you can really embed any binary file (even invalid file types). Subsequently, the “shell” SWF will decrypt the ByteArray before feeding it to the loadBytes() method of the Loader instance.

To be very clear though, the intention here is not exactly encryption. The real objective here is to intentionally “corrupt” the embedded SWF, so that even if extracted, decompilers cannot easily identify and run/decompile it as a SWF standalone.

For the purpose of corrupting the SWF, there are countless ways – using simple encryption, bytes transpositions, append/prepend useless bytes, etc. well, you get the idea… basically anything that make the SWF file invalid, no longer executable as a SWF. You can even split the SWF into two or more binary blobs and join them back during run-time.

Since there are so many different possible algorithms to corrupt the SWF, it is then practically impossible for decompilers to automatically identify the way to reconstruct the corrupted embedded SWF.

Disclaimer
Needless to say, if you decide to corrupt/encrypt the SWF, you must be able to reconstruct, in the “shell” SWF, the embedded binary object into a working SWF. As a result, while we may be able to prevent automated decryption (primary objective here), do take note that this provides no protection against determined hacking (decompiling the “shell” SWF, getting the decryption logic, extracting the embedded SWF manually, decrypting it and then running the reconstructed SWF through the decompiler).

FlashDevelop
For users of the FlashDevelop IDE, you are probably aware of its SWF assets browser (unlike decompilers, SWF sniffing is used here ethically, and beautifully, for the purpose of implementing code completion, etc.). If you attempt to browse the “shell” SWF within the FlashDevelop’s Project Manager panel, you will not see the assets (classes and symbols) in the embedded SWF. This can be used as a way to quickly verify if a SWF is protected using the “embedding technique” discussed above.