Clever Geek Handbook

SWFデコンパイラから身を守る方法

最近、私はうらやましい頻度で尋ねられました：「Flash Playerとサーバーの間を飛んでいるデータを保護する方法は？」。 答えの代わりに、暗号に関する本を読むことを提案し、非常にant慢だった私は次のコードと戦った。



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); //,







そして、彼らは私を解き、コードをコピー＆ペーストしました。 そして、好奇心of盛な人の一人が次のように尋ねるまで、すべてがうまくいきました。 結局のところ、どのフラッシュドライブでもサイトからドラッグしてデコンパイルすることができます！」



判明したように、この方法は非常に単純であり、難読化ツールを必要としません。 これは、1つのファイルにコンパイルされた標準フラッシュドライブに関するものです。



理論のビット


デコンパイラは、swfファイルを解析し、クラスに解析します。 彼は、クラスのプロパティとメソッドの名前も読み取ることができますが、このクラスの外部からアクセスできるもの、つまり静的、パブリック、継承、および保護されているものだけを読み取ります。 プライベートアクセス修飾子で保護された変数、またはメソッドのスコープでのみ定義された変数、逆コンパイラも読み取ることができますが、それらの名前は、たとえば_loc_1に置き換えられます。 これは、ほとんどのコンパイラ（フラッシュだけでなく）が最適化に従事しており、バイトコードに変換する前に人間が読める読みやすいコードを捨てているためです。 誰かがこのメタ情報を呼び出しますが、ランタイムでは、これは意味を持たない単なるゴミです。



フラッシュ技術を搭載


アクションスクリプトプロジェクトは、swc-file：ライブラリファイルとしてコンパイルできます。 SWCは基本的に、swfファイルとxmlメタファイルを含むアーカイブです。 XMLは、このライブラリを接続するときに使用できるクラスへの参照ポインターを格納します。 実際、swfの「ライブ」を読むことで、それらなしで実行できます。 これは、Embedメタタグのパラメーターを使用して行われます。 たとえば、次のように：



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







SomeClassFromSomeSWFのコンストラクターを呼び出すことにより、通常どおりこのクラスを引き続き使用できます 。 このクラスのインスタンスタイプは、 some.swfの SomeClassクラスとまったく同じです 。 ただし、Embedタグを使用すると、特定のクラスだけでなく、SWF全体を実装できます（実際、何でも実装できますが、今ではそれについてではありません）。 埋め込みSWFのクラスインスタンスはどのタイプになりますか？



埋め込みSWF


application / x-shockwave-flashに等しいmimeTypeを持つ埋め込みファイル（つまり、swfファイルなど）の場合、Adobeには特別なタイプがあります： MovieClipLoaderAsset 、これはmx.coreパッケージにあります。 埋め込みの際、swfファイル自体はバイト配列としてmovieClipDataプロパティに分類され、人間指向の 「ガベージ」をすべて除外します。つまり、flashplayerが必要とするもののみです。 しかし、それだけではありません。 MovieClipLoaderAssetはMovieClipの後継です。つまり、明確な良心をもって表示リストに追加できることを意味します。



これらすべてを知って、「逆コンパイラに対する保護」という最初のタスクを解決するのに3分かかります。



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： apparatオプティマイザーに基づくAS3プロキシバイトコードアナライザーは、この保護を問題なく破りました。



UPD 2：この方法は、「絶対的な保護」とは主張していません。 存在するすべてをハッキングできます。 この方法では、SWFに配線されたリソース（アート/音楽/計算ロジック）を取得するための時間と知的費用が増加するだけです。 さらに、コメントには「プッシュボタン」の原理で動作する逆コンパイラがあり、問題なく同様の保護を明らかにしました。 要約すると、フラッシュドライブをハッキングする唯一の保護障害としてこの方法を使用しないでください。 ただし、そのシンプルさと軽さで包括的に適用されるため、リソースが開かれないように保護するのに非常に役立ちます。


More articles:


All Articles