以下、図面と共に本発明に係る難読化判定装置の実施形態について詳細に説明する。なお、図面の説明においては同一要素には同一符号を付し、重複する説明を省略する。
図1に本実施形態に係る難読化判定装置10を示す。難読化判定装置10は、アプリが難読化されたものか否かに係る判定を行う装置である。難読化判定装置10は、アプリの実行コード、即ち、ソースコードがコンパイルされたデータ(バイナリデータ)が、難読化されて生成されたものであるか否かに係る判定を行う。難読化は、例えば、ソースコードがコンパイルされる際にコンパイルとあわせて行われる。難読化は、従来の難読化を行うソフトウェア(例えば、DashO又はEnsureIT)によって行われる。難読化を行うソフトウェアは、具体的には、例えば、名前の変更、文字列の暗号化、制御フローの難読化、特定の関数呼び出しの隠匿、リソースの難読化、リソースの検証、アンチデバッグ及び改ざん検出等の機能を有している。
難読化判定装置10は、例えば、第三者であるアプリベンダからアプリの実行コードを受け取ってユーザに公開する、アプリのプラットフォームの管理者によって用いられる。アプリのプラットフォームの管理者は、難読化判定装置10による判定でアプリが難読化されたものであると確認できたアプリを公開することができる。なお、難読化判定装置10は、アプリのプラットフォームの管理者以外によって用いられてもよい。
引き続いて、本実施形態に係る難読化判定装置10の機能を説明する。図1に示すように難読化判定装置10は、プログラムコード取得部11と、出現頻度情報取得部12と、判定部13と、出力部14とを備えて構成される。
プログラムコード取得部11は、判定対象のアプリの実行コードを入力して、入力した実行コードに対して逆コンパイルを行ってプログラムコードを取得する機能部である。例えば、プログラムコード取得部11は、難読化判定装置10のユーザによる難読化判定装置10に対する操作によって判定対象のアプリの実行コードを入力する。プログラムコード取得部11は、入力した実行コードに対して逆コンパイルを行ってプログラムコードを取得する。逆コンパイルは、従来の逆コンパイルを行うソフトウェア等によって行うことができる。プログラムコード取得部11は、取得したプログラムコードを出現頻度情報取得部12に出力する。
出現頻度情報取得部12は、判定対象のアプリの実行コードの逆コンパイルによって得られるプログラムコードにおけるキャラクタの出現頻度を示す出現頻度情報を取得する機能部である。出現頻度情報取得部12は、プログラムコード取得部11によって取得されたプログラムコードから出現頻度情報を取得する。
出現頻度情報取得部12は、プログラムコード取得部11からプログラムコードを入力する。出現頻度情報取得部12は、プログラムコードに出現するキャラクタの数をキャラクタ毎にカウントして、プログラムコードを構成する全キャラクタ数(キャラクタの延べ数)で割ることでキャラクタ毎の出現頻度(ここでは、出現率)を算出する。算出した出現頻度を示す情報が出現頻度情報であり、出現頻度情報取得部12は、このように出現頻度情報を取得する。出現頻度算出の対象となるキャラクタは、通常の文字(図形文字)に加えて、制御文字(例えば、削除文字の“DEL”)を含んでいてもよい。また、出現頻度算出の対象となるキャラクタは、難読化の判定に用いられる、予め設定された特定のキャラクタのみであってもよい。出現頻度情報取得部12は、取得した出現頻度情報を判定部13に出力する。
プログラムコードにおけるキャラクタの出現頻度の例を図2に示す。図2において、上の行は、難読化(DashO)が行われたアプリのプログラムコードにおけるキャラクタの出現頻度である。下の行は難読化が行われていないアプリのプログラムコード(ソースコード)におけるキャラクタの出現頻度である。図2におけるchar()の括弧中の数値は、キャラクタの識別番号(ASCII十進表現)である。図2に示す出現頻度は、複数のアプリから得られた出現頻度である。
また、図3にプログラムコードにおけるキャラクタの出現度数の例のヒストグラムを示す。図3における横軸は、キャラクタの識別番号(ASCII十進表現)であり、縦軸は、当該識別番号に対応するキャラクタのプログラムコードにおける出現度数である。難読化が行われたアプリに係るグラフ(dasho)及び難読化が行われていないアプリに係るグラフ(non-dasho)の両方を示す。
図2及び図3に示すようにプログラムコードにおけるキャラクタの出現頻度は、難読化が行われているか否かによって異なる傾向を有している。例えば、図2に示されるように、char(127)の出現頻度は、難読化が行われたアプリでは0.250%になっているのに対して、難読化が行われていないアプリでは0.000%になっている。このように難読化が行われたアプリにしか出現しないキャラクタが存在している。また、難読化が行われていないアプリの方が、キャラクタの種類が多い。これは、難読化の際に特別なキャラクタが自動で追加されることによる。本発明者は、難読化の有無に応じたキャラクタの出現頻度の相違を発見し、これを利用することで発明を行った。
判定部13は、出現頻度情報取得部12によって取得された出現頻度情報に基づいて判定を行う機能部である。判定部13は、出現頻度情報取得部12から出現頻度情報を入力する。判定部13は、例えば、予め記憶した決定木(決定木のよる分類モデル)によってアプリが難読化されたものか否かの判定を行う。判定部13は、出現頻度情報によって示されるキャラクタの出現頻度と予め設定された閾値とを比較して決定木における分岐を判断する。
決定木の例を図4に示す。判定部13は、最初にchar(127)=“DEL”の出現頻度が0.002以下であるか否かを判断する。char(127)=“DEL”の出現頻度が0.002以下ではないと判断した場合、判定部13は、アプリが難読化されたもの(D)と判定する。char(127)=“DEL”の出現頻度が0.002以下であると判断した場合、判定部13は、続いて、char(59)=“;”の出現頻度が0.138以下であるか否かを判断する。
char(59)=“;”の出現頻度が0.138以下ではないと判断した場合、判定部13は、続いて、char(62)=“>”の出現頻度が0.011以下であるか否かを判断する。char(62)=“>”の出現頻度が0.011以下ではないと判断した場合、判定部13は、アプリが難読化されたものではない(ND)と判定する。char(62)=“>”の出現頻度が0.011以下であると判断した場合、判定部13は、アプリが難読化されたもの(D)と判定する。
char(59)=“;”の出現頻度が0.138以下であると判断した場合、判定部13は、続いて、char(46)=“.”の出現頻度が0.008以下であるか否かを判断する。char(46)=“.”の出現頻度が0.008以下ではないと判断した場合、判定部13は、アプリが難読化されたものではない(ND)と判定する。char(46)=“.”の出現頻度が0.008以下であると判断した場合、判定部13は、アプリが難読化されたもの(D)と判定する。
図4には、DashOによって難読化された200のアプリ、難読化されていない200のアプリの合計400のアプリに対する上記の判定の結果もあわせて示す。図4におけるNumberの値が、決定木における各節点におけるアプリの数を示す。[D,ND]の値は、それぞれ決定木における各節点における、難読化されたアプリの数及び難読化されていないアプリの数を示す。
図4に示すように難読化された200のアプリのうち、194のアプリが難読化されたものと判定され、6のアプリが難読化されたものではないと判定されている。また、難読化されていない200のアプリのうち、1のアプリが難読化されたものと判定され、199のアプリが難読化されたものではないと判定されている。
決定木、具体的には、判断に用いられるキャラクタの種類及び閾値は、例えば、図2及び図3に示すような、サンプル(学習用のデータ)のアプリにおける難読化が行われている場合及びいない場合のプログラムコードにおけるキャラクタの出現頻度に応じて設定される。例えば、難読化が行われている場合といない場合とで、出現頻度が大きく異なるキャラクタ(相違を認識しやすいキャラクタ)程、決定木における上位の節点における判断に用いられる。また、判断に用いられるキャラクタの種類及び閾値は、難読化を行う方法、例えば、難読化を行うソフトウェアに応じて設定されてもよい。また、決定木は、図2及び図3に示すようなサンプルに基づいて従来の決定木学習アルゴリズムによって生成されてもよい。
一般に木の深さが深くなればなるほど、サンプルによく適合したモデルが生成される。木の深さが浅いと、各種計算を行う際の説明変数に対する学習係数に対するバイアスが大きくなり、汎化能力の不足の要因となる。図4に示す決定木については、発明者による検証では4層がベストであることが確認された。
判定部13は、決定木以外の方法で判定を行うこととしてもよい。例えば、判定部13は、機械学習によって得られたニューラルネットワークを含む学習済みモデルを用いて判定を行うこととしてもよい。例えば、学習済みモデルは、出現頻度情報によって示されるキャラクタの出現頻度を入力して、アプリが難読化されたものか否かを示す情報を出力する。
また、上記の例では、判定部13は、アプリが難読化されたものか否かの判定を行う(0か1かの判定)こととしたが、それ以外の判定、例えば、アプリが難読化されたものである可能性を判定することとしてもよい。例えば、判定部13は、当該可能性を示す数値を算出することとしてもよい。判定部13は、判定結果を出力部14に出力する。
出力部14は、判定部13による判定の結果を示す情報を出力する機能部である。出力部14は、判定部13から判定結果を示す情報を入力する。出力部14は、例えば、難読化判定装置10が備える表示装置に判定結果を表示する。出力部14による出力は、難読化判定装置10のユーザ(例えば、アプリのプラットフォームの管理者)によって参照される。また、出力部14による出力は、難読化判定装置10以外の装置に対して行われてもよい。また、出力部14による出力は、上記以外の形態(例えば、送信)で行われてもよい。以上が、本実施形態に係る難読化判定装置10の機能である。
引き続いて、図5のフローチャートを用いて、本実施形態に係る難読化判定装置10で実行される処理(難読化判定装置10が行う動作方法)を説明する。本処理では、まず、プログラムコード取得部11によって、判定対象のアプリの実行コードが入力される(S01)。続いて、プログラムコード取得部11によって、入力された実行コードに対して逆コンパイルが行われてプログラムコードが取得される(S02)。続いて、出現頻度情報取得部12によって、プログラムコードにおけるキャラクタの出現頻度が算出される(S03)。続いて、判定部13によって、出現頻度に基づいて難読化の判定が行われる(S04)。続いて、出力部14によって、判定結果を示す情報が出力される(S05)。以上が、本実施形態に係る難読化判定装置10で実行される処理である。
上述した実施形態では、出現頻度情報に基づいてアプリの難読化に係る判定が行われる。難読化されたアプリから得られるプログラムコードにおけるキャラクタの出現頻度と、難読化されていないアプリのプログラムコードにおけるキャラクタの出現頻度とは、判定ができる程度に異なっているとの本発明者によって見出された上述した知見により、本実施形態によれば、アプリが難読化されたものか否かを判別することができる。
また、本実施形態のようにアプリの実行コードを入力し、実行コードからプログラムコードを取得し、プログラムコードから出現頻度情報を取得する構成としてもよい。この構成によれば、アプリの実行コードから難読化に係る判定を行うことができる。但し、出現頻度情報があれば、難読化に係る判定を行うことができるので、必ずしもアプリの実行コードを入力する必要はなく、出現頻度情報を何らかの方法で取得できる構成となっていればよい。
上述した実施形態では、判定に用いる出現頻度は、キャラクタ毎(キャラクタ単位)であることとしていた。しかしながら、出現頻度は、キャラクタ毎ではなく、複数のキャラクタからなるキャラクタ列(文字列)に係るものを用いてもよい。即ち、出現頻度情報取得部12は、プログラムコードにおける、複数のキャラクタからなるキャラクタ列の出現頻度を示す出現頻度情報を取得し、判定部13は、当該出現頻度情報に基づいて判定を行うこととしてもよい。出現頻度に係るキャラクタ列は予め設定される。例えば、難読化されている場合とされていない場合とで出現頻度が大きく異なるキャラクタ列を用いる。この構成によれば、精度の高い難読化に係る判定を行うことができる。
なお、上記実施形態の説明に用いたブロック図は、機能単位のブロックを示している。これらの機能ブロック(構成部)は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的又は論理的に結合した1つの装置を用いて実現されてもよいし、物理的又は論理的に分離した2つ以上の装置を直接的又は間接的に(例えば、有線、無線などを用いて)接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記1つの装置又は上記複数の装置にソフトウェアを組み合わせて実現されてもよい。
例えば、本開示の一実施の形態における難読化判定装置10は、本開示の方法の処理を行うコンピュータとして機能してもよい。図6は、本開示の一実施の形態に係る難読化判定装置10のハードウェア構成の一例を示す図である。上述の難読化判定装置10は、物理的には、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006、バス1007などを含むコンピュータ装置として構成されてもよい。
なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。難読化判定装置10のハードウェア構成は、図に示した各装置を1つ又は複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。
難読化判定装置10における各機能は、プロセッサ1001、メモリ1002などのハードウェア上に所定のソフトウェア(プログラム)を読み込ませることによって、プロセッサ1001が演算を行い、通信装置1004による通信を制御したり、メモリ1002及びストレージ1003におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。
プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインターフェース、制御装置、演算装置、レジスタなどを含む中央処理装置(CPU:Central Processing Unit)によって構成されてもよい。例えば、上述の難読化判定装置10の各機能部は、プロセッサ1001によって実現されてもよい。
また、プロセッサ1001は、プログラム(プログラムコード)、ソフトウェアモジュール、データなどを、ストレージ1003及び通信装置1004の少なくとも一方からメモリ1002に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。例えば、難読化判定装置10の各機能部は、メモリ1002に格納され、プロセッサ1001において動作する制御プログラムによって実現されてもよい。上述の各種処理は、1つのプロセッサ1001によって実行される旨を説明してきたが、2以上のプロセッサ1001により同時又は逐次に実行されてもよい。プロセッサ1001は、1以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されても良い。
メモリ1002は、コンピュータ読み取り可能な記録媒体であり、例えば、ROM(Read Only Memory)、EPROM(Erasable Programmable ROM)、EEPROM(Electrically Erasable Programmable ROM)、RAM(Random Access Memory)などの少なくとも1つによって構成されてもよい。メモリ1002は、レジスタ、キャッシュ、メインメモリ(主記憶装置)などと呼ばれてもよい。メモリ1002は、本開示の一実施の形態に係る方法を実施するために実行可能なプログラム(プログラムコード)、ソフトウェアモジュールなどを保存することができる。
ストレージ1003は、コンピュータ読み取り可能な記録媒体であり、例えば、CD-ROM(Compact Disc ROM)などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク(例えば、コンパクトディスク、デジタル多用途ディスク、Blu-ray(登録商標)ディスク)、スマートカード、フラッシュメモリ(例えば、カード、スティック、キードライブ)、フロッピー(登録商標)ディスク、磁気ストリップなどの少なくとも1つによって構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。上述の記憶媒体は、例えば、メモリ1002及びストレージ1003の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。
通信装置1004は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア(送受信デバイス)であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。通信装置1004は、例えば周波数分割複信(FDD:Frequency Division Duplex)及び時分割複信(TDD:Time Division Duplex)の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。例えば、上述の難読化判定装置10の各機能部は、通信装置1004によって実現されてもよい。
入力装置1005は、外部からの入力を受け付ける入力デバイス(例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど)である。出力装置1006は、外部への出力を実施する出力デバイス(例えば、ディスプレイ、スピーカー、LEDランプなど)である。なお、入力装置1005及び出力装置1006は、一体となった構成(例えば、タッチパネル)であってもよい。
また、プロセッサ1001、メモリ1002などの各装置は、情報を通信するためのバス1007によって接続される。バス1007は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。
また、難読化判定装置10は、マイクロプロセッサ、デジタル信号プロセッサ(DSP:Digital Signal Processor)、ASIC(Application Specific Integrated Circuit)、PLD(Programmable Logic Device)、FPGA(Field Programmable Gate Array)などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部又は全てが実現されてもよい。例えば、プロセッサ1001は、これらのハードウェアの少なくとも1つを用いて実装されてもよい。
本開示において説明した各態様/実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。
入出力された情報等は特定の場所(例えば、メモリ)に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報等は、上書き、更新、又は追記され得る。出力された情報等は削除されてもよい。入力された情報等は他の装置へ送信されてもよい。
判定は、1ビットで表される値(0か1か)によって行われてもよいし、真偽値(Boolean:true又はfalse)によって行われてもよいし、数値の比較(例えば、所定の値との比較)によって行われてもよい。
本開示において説明した各態様/実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知(例えば、「Xであること」の通知)は、明示的に行うものに限られず、暗黙的(例えば、当該所定の情報の通知を行わない)ことによって行われてもよい。
以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。
ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。
本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)(例えば、テーブル、データベース又は別のデータ構造での探索)、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)(例えば、情報を受信すること)、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)(例えば、メモリ中のデータにアクセスすること)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断(決定)」は、「想定する(assuming)」、「期待する(expecting)」、「みなす(considering)」などで読み替えられてもよい。
本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。