Pull to refresh

Как защититься от SWF-декомпиляторов

Reading time3 min
Views16K
У меня в последнее время с завидной частотой спрашивают: «Как защитить данные, летающие между Flash Player и сервером?». Вместо ответа я предлагал прочитать любые книжки по криптографии, а от сильно наглых отбивался следующим кодом.

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); //Метод, посылающий шифрованные данные на сервер


И от меня отвязывались, копипастя код. И всё у меня было хорошо, до тех пор, пока один из любопытных не спросил: «А как же защитить ключ? Ведь любую флешку можно утащить с сайта и декомпилировать!»

Способ, как оказалось, очень прост и не требует наличия никаких обфускаторов. Речь пойдёт о стендалон-флешках, скомпилированных одним файлом.

Немного теории

Любой декомпилятор анализирует ваш swf-файл и разбирает его на классы. Он способен прочитать даже имена свойств и методов класса, но лишь тех, которые доступны извне этого класса: то есть статические, public, inherited и protected. Переменные, защищённые модификатором доступа private, либо переменные определённые только в области видимости методов, декомпиляторы прочитать так же способны, но их имена заменяют например на _loc_1. Это лишь потому, что большинство компиляторов (это относится не только к flash) занимаются оптимизацией, выкидывая человеко-ориентированный легко читаемый код перед превращением в байт-код. Кто-то называет это мета-информацией, но для среды исполнения это всего лишь мусор, не несущий никакой смысловой нагрузки.

Особенности flash-технологии

Любой action-script проект можно скомпилировать как swc-файл: файл библиотеки. SWC является по сути архивом, содержащим swf-файл и xml-метафайл. В XML хранятся ссылки-указатели на классы, которые можно использовать при подключении этой библиотеки. На самом деле обходиться можно и без них, читая swf «вживую». Делается это при помощи параметров мета-тега Embed. Например, так:

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

Дальше использовать этот класс можно как обычно — через вызов конструктора у SomeClassFromSomeSWF. Тип экземпляра этого класса будет точно таким же, как у класса SomeClass в some.swf. Однако, при помощи тега Embed можно внедрять не только определённые классы, но и всю SWF целиком (на самом деле внедрять можно что угодно, но сейчас речь не об этом). Какой же тип будет у экземпляра класса внедрённой SWF?

Внедрённая SWF

Для внедрённых файлов с mimeType равным application/x-shockwave-flash (то есть, например, swf-файлов) у Adobe есть специальный тип: MovieClipLoaderAsset, находящийся в пакете mx.core. Сам swf-файл при внедрении ложится в его свойство movieClipData как массив байт, исключая весь человекоориентированный «мусор» — то есть только то, что нужно flashplayer'у. Но и это ещё не всё. MovieClipLoaderAsset является наследником MovieClip, а значит может быть с чистой совестью добавлен в список отображения.

Зная всё это, решить исходную задачу «защиты от декомпиляторов» — дело трёх минут:

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";
}
}
}


Да. Ничто не помешает декомпилятору прочитать исходный код результата компиляции вышеприведённого. Но защищаемая swf уже не будет ему доступна. И ему останется лишь читать специально предназначенное для него сообщение и плакать.

UPD: Анализатор байткода AS3 proxy, основанный на оптимизаторе apparat взломал данную защиту без особых проблем.

UPD 2: Данный метод не претендует на звание «абсолютная защита». Взломать можно всё, что существует. Этот метод всего лишь увеличивает временные и интеллектуальные затраты на получение ресурсов, зашитых в SWF: арт/музыку/расчётную логику. К тому же, в комментариях обнаружился декомпилятор, действующий по принципу «нажми-одну-кнопку», вскрывающий подобную защиту без проблем. Подводя итоги: не стоит использовать данный метод, как единственное защитное препятствие к взлому флешки. Однако будучи применён комплексно, при своей простоте и легковесности, он способен значительно помочь оградить ресурсы от вскрытия.
Tags:
Hubs:
+13
Comments78

Articles