How to protect yourself from SWF decompilers
Recently I have been asked with enviable frequency: “How to protect data flying between Flash Player and the server?”. Instead of an answer, I suggested reading any books on cryptography, and from the very arrogant I fought off with the following code.
And they untied me, copy-paste code. And everything was fine with 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, as it turned out, is very simple and does not require any obfuscators. It's about standalon flash drives compiled in one file.
Any decompiler parses your swf file and parses it into classes. He is able to read even the names of the properties and methods of the class, but only those that are accessible from outside this class: that is, static, public, inherited and protected. Variables protected by the private access modifier, or variables defined only in the scope of methods, decompilers are also able to read, 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-readable easy-to-read code before turning into byte code. Someone calls this meta-information, but for the runtime, this is just garbage that does not carry any meaning.
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. XML stores reference pointers to classes that you can use when connecting this library. In fact, you can do without them by reading swf “live”. This is done using the parameters of the Embed meta tag. For example, like this: You
can continue to use this class as usual - by calling the constructor of SomeClassFromSomeSWF . The instance type of this class will be exactly the same as the SomeClass class in some.swf. However, using the Embed tag, you can implement not only certain classes, but the entire SWF (in fact, you can implement anything, but now it's not about that). What type will the class instance of the embedded SWF be?
For embedded files with mimeType equal to application / x-shockwave-flash (that is, for example, swf files), Adobe has a special type: MovieClipLoaderAsset , which is in the mx.core package . When embedding, the swf file itself falls into its movieClipData property as an array of bytes, excluding all human- oriented "garbage" - that is, only what flashplayer needs. But that is not all. MovieClipLoaderAsset is the successor to MovieClip, which means it can be added to the display list with a clear conscience.
Knowing all this, solving the initial task of “protection against decompilers” is a matter of three minutes:
Yes. Nothing will prevent the decompiler from reading the source code of the compilation result of the above. But the protected swf will no longer be available to him. And he will only have to read the message specially designed for him and cry.
UPD: AS3 proxy bytecode analyzer based on apparat optimizer broke this protection without any problems.
UPD 2: This method does not claim to be “absolute protection”. You can hack everything that exists. This method only increases the time se and intellectual costs for obtaining resources wired in SWF: art / music / calculation logic. In addition, in the comments there was a decompiler, operating on the principle of "push-one-button", revealing a similar protection without problems. To summarize: you should not use this method as the only protective obstacle to hacking a flash drive. However, being applied comprehensively, with its simplicity and lightness, it can significantly help protect resources from opening.
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); //Метод, посылающий шифрованные данные на серверBit of theory
Any decompiler parses your swf file and parses it into classes. He is able to read even the names of the properties and methods of the class, but only those that are accessible from outside this class: that is, static, public, inherited and protected. Variables protected by the private access modifier, or variables defined only in the scope of methods, decompilers are also able to read, 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-readable easy-to-read code before turning into byte code. Someone calls this meta-information, but for the runtime, this is just garbage that does not carry any meaning.
Features 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. XML stores reference pointers to classes that you can use when connecting this library. In fact, you can do without them by reading swf “live”. This is done using the parameters of the Embed meta tag. For example, like this: You
[Embed(source = 'some.swf', symbol = 'SomeClass')] private const SomeClassFromSomeSWF:Class;can continue to use this class as usual - by calling the constructor of SomeClassFromSomeSWF . The instance type of this class will be exactly the same as the SomeClass class in some.swf. However, using the Embed tag, you can implement not only certain classes, but the entire SWF (in fact, you can implement anything, but now it's not about that). What type will the class instance of the embedded SWF be?
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 , which is in the mx.core package . When embedding, the swf file itself falls into its movieClipData property as an array of bytes, excluding all human- oriented "garbage" - that is, only what flashplayer needs. But that is not all. MovieClipLoaderAsset is the successor to MovieClip, which means it can be added to the display list with a clear conscience.
Knowing all this, solving the initial task 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 no longer be available to him. And he will only have to read the message specially designed for him and cry.
UPD: AS3 proxy bytecode analyzer based on apparat optimizer broke this protection without any problems.
UPD 2: This method does not claim to be “absolute protection”. You can hack everything that exists. This method only increases the time se and intellectual costs for obtaining resources wired in SWF: art / music / calculation logic. In addition, in the comments there was a decompiler, operating on the principle of "push-one-button", revealing a similar protection without problems. To summarize: you should not use this method as the only protective obstacle to hacking a flash drive. However, being applied comprehensively, with its simplicity and lightness, it can significantly help protect resources from opening.