How to protect against SWF decompilers

Recently I have been asked with an enviable frequency: “How to protect the data flying between Flash Player and the server?”. Instead of answering, I offered to read any books on cryptography, and from the very arrogant fought the following code.

var myAge:Number = 23; //
var someTextToEncode:String = 'Sometext, or xml, or anything else'; //
var arr:Array = new Array();
var l:Number = someTextToEncode.length;
var encodedText:String = '';
for (var i:Number = 0; i< l; i++){
encodedText += String.fromCharCode(someTextToEncode.charCodeAt(i) + myAge); // . . 90% "" .
}
post(encodedText); //,

And they got rid of me, copy-code. And everything was good for me, until one of the curious asked: “But how to protect the key? After all, any flash drive can be dragged from the site and decompiled! "

The method turned out to be very simple and does not require any obfuscators. It will be a question of stand-stalon flash drives compiled with one file.

A bit of theory

Any decompiler analyzes your swf-file and parses it into classes. It is able to read even the names of properties and methods of a class, but only those that are accessible from outside this class: that is, static, public, inherited, and protected. Variables protected by the access modifier private, or variables defined only in the scope of methods, decompilers are also capable of reading, but their names are replaced for example with _loc_1. This is only because most compilers (this applies not only to flash) are engaged in optimization, throwing out human-oriented, easily readable code before turning into byte-code. Someone calls this meta-information, but for the execution environment it is just garbage that does not carry any semantic load.
')

Features of flash technology

Any action-script project can be compiled as a swc file: library file. SWC is essentially an archive containing a swf file and an xml metafile. The XML contains reference references to classes that can be used when connecting this library. In fact, you can do without them, reading the swf "live". This is done using the parameters of the meta tag Embed. For example:

[Embed(source = 'some.swf', symbol = 'SomeClass')] private const SomeClassFromSomeSWF:Class;

You can continue using this class as usual - through a call to the constructor for SomeClassFromSomeSWF . The instance type of this class will be exactly the same as the SomeClass class in some.swf . However, with the help of the Embed tag, you can embed not only certain classes, but the entire SWF as a whole (in fact, you can embed anything, but now it's not about that). What type will the instance of the class implement the SWF?

Embedded swf

For embedded files with mimeType equal to application / x-shockwave-flash (that is, for example, swf-files) Adobe has a special type: MovieClipLoaderAsset , located in the package mx.core . The swf file itself when embedded is placed in its movieClipData property as an array of bytes, excluding all human- oriented “garbage” - that is, only what flashplayer needs. But that's not all. MovieClipLoaderAsset is a successor of MovieClip, which means it can be added to the display list with a clear conscience.

Knowing all this, solving the original problem of “protection against decompilers” is a matter of three minutes:

package {
import flash.display.Sprite;
import mx.core.MovieClipLoaderAsset;
public class Crypto extends Sprite {
[Embed(source = 'unprotected.swf')] public const ToProtect:Class;
public function Crypto():void {
var protectedSwf:MovieClipLoaderAsset=new ToProtect() as MovieClipLoaderAsset;
addChild(protectedSwf);
var messageToDecompiler:String = "Hello fellas. You can do nothing^^ Kekeke";
}
}
}

Yes. Nothing will prevent the decompiler from reading the source code of the compilation result of the above. But the protected swf will not be available to him anymore. And he will only read a message specially designed for him and cry.

UPD: The AS3 proxy bytecode analyzer, based on the apparat optimizer , cracked this protection without any special problems.

UPD 2: This method does not claim to be “absolute protection”. You can hack anything that exists. This method only increases the time and intellectual costs of obtaining resources sewn into the SWF: art / music / calculated logic. In addition, the comments revealed a decompiler acting on the “push-one-button” principle, revealing such protection without problems. Summing up: you should not use this method as the only protective obstacle to cracking a flash drive. However, being applied in a complex, with its simplicity and lightness, it can significantly help protect resources from opening.