(57)【要約】      （修正有）【課題】所望のライブラリの組み合わせで動作しない可能性のある構成であっても、実行時に必ず意図した依存関係を保証できるようにする。【解決手段】所定の中間言語をマイクロプロセッサが解釈可能な命令に変換する機能２０１を搭載する情報処理装置において、同一ＡＰＩで異なるバージョンのモジュールを提供する場合に、異なる難読化乱数シードを用いて難読化済モジュールを生成するが難読化処理と、特定の難読化済モジュールを使用するように設定されたアプリケーションプログラムまたは親モジュールと、アプリケーションプログラムまたは親モジュールを実行可能な状態にするモジュール読込処理部２０２と、を有する。【選択図】図２
2019020933.tif 000002
【特許請求の範囲】
【請求項１】
所定の中間言語をマイクロプロセッサが解釈可能な命令に変換する機能（２０１）を搭載する情報処理装置（１００）において、
同一ＡＰＩで異なるバージョンのモジュールを提供する場合に、異なる難読化乱数シードを用いて難読化済モジュールを生成するが難読化処理（３０２）と、
特定の前記難読化済モジュールを使用するように設定されたアプリケーションプログラムまたは親モジュールと、
前記アプリケーションプログラムまたは前記親モジュールを実行可能な状態にするモジュール読込処理部（２０２）と、
を有することを特徴とする情報処理装置および制御方法。
【請求項２】
難読化処理時に結び付けられた前期難読化済モジュールが見つからない場合に、同一ＡＰＩの異なるバージョンの難読化済モジュールを探索するモジュール読込処理部（２０２）と、難読化処理時に結び付けられた前期難読化モジュールとは異なる難読化済モジュールを使用する際にユーザに通知を表示する通知処理と、を有することを特徴とする請求項１の情報処理装置および制御方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プログラム及び制御方法、特に所定の中間言語をマイクロプロセッサの固有命令に変換する機能を搭載する情報処理装置に関する。
【背景技術】
【０００２】
近年、特定のハードウェア及びＯＳといったプロットフォームに依存しないＪａｖａ（登録商標）を用いた開発が広く普及してきている。
【０００３】
Ｊａｖａは、コンパイラがソースコードからプラットフォームに依存しないバイトコードと呼ばれる中間言語に翻訳する。バイトコードは、Ｊａｖａ仮想マシン（Ｊａｖａ  Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ：ＪａｖａＶＭ）と呼ばれるソフトウェアを用いてマイクロプロセッサ固有のネイティブコードに解釈され実行される。プラットフォームに対応するＪａｖａ仮想マシンを用意することで、プラットフォームの差異はＪａｖａ仮想マシンが吸収する。
【０００４】
また、Ｊａｖａはクラスローダと呼ばれる機能を持っている。クラスローダとは、Ｊａｖａ仮想マシンの一部で、ＪａｖａクラスをＪａｖａ仮想マシンに動的にロードする役割を持つ。Ｊａｖａでは、ライブラリをＪａｒファイルと呼ばれるファイルに格納する。クラスローダはこのＪａｒファイルから、必要なタイミングでＪａｖａ仮想マシンにプログラムを実行できるように自動的にクラスを読み込む。
【０００５】
特許文献１は、要求毎に対応するクラスローダを使用してクラスファイルのロードを行うことで、サーブレットエンジンの再起動無しにＪａｖａ仮想マシンの更新を可能とする技術を開示している。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００３−２０８３１２公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
クラスローダがＪａｒファイルをロードする際に、所望のライブラリの組み合わせで動作しない状況のことを指して、Ｊａｒ地獄（Ｊａｒ  Ｈｅｌｌ）と呼ぶことがある。これにはいくつかの原因がある。
【０００８】
１つ目は、たまたま同じライブラリの２つバージョンが利用可能になってしまったことによる。Ｊａｖａ仮想マシンは、この場合エラーを発生させず、単純にどちらか一方のライブラリからのみロードすることによる。
【０００９】
２つ目は、ある２つのライブラリＡとＢが、別のライブラリＣの異なるバージョンを、それぞれ要求している場合である。
【００１０】
これらの結果として、各ライブラリのバージョンの組み合わせが保証できず、予測困難なエラーやバグに直面するという課題があった。
【課題を解決するための手段】
【００１１】
上記の課題を解決するために、本発明に係る情報処理装置および制御方法は、
所定の中間言語をマイクロプロセッサが解釈可能な命令に変換する機能（２０１）を搭載する情報処理装置（１００）において、
同一ＡＰＩで異なるバージョンのモジュールを提供する場合に、異なる難読化乱数シードを用いて難読化済モジュールを生成するが難読化処理（３０２）と、
特定の前記難読化済モジュールを使用するように設定されたアプリケーションプログラムまたは親モジュールと、
前記アプリケーションプログラムまたは前記親モジュールを実行可能な状態にするモジュール読込処理部（２０２）と、
を有することを特徴とする。
【発明の効果】
【００１２】
本発明に係る情報処理装置および制御方法によれば、環境やクラスローダの種類によらず実行時に各ライブラリのバージョンの組み合わせが保証出来るようになる。その結果、予測困難なエラーやバグを減らすことが出来る。
【図面の簡単な説明】
【００１３】
【図１】本発明の一実施形態としての情報処理装置のハードウェア構成図
【図２】本発明の一実施形態としてのバイトコード実行端末のソフトウェアブロック図
【図３】本発明の一実施形態としてのバイトコード生成端末のソフトウェアブロック図
【図４】Ｊａｖａソースコードからバイトコードの生成処理を行うフロー
【図５】バイトコードを仮想マシン上に読み込むクラスローダ処理のフロー
【発明を実施するための形態】
【００１４】
以下、本発明を実施するための形態について図面などを参照して説明する。なお、実施形態は、本発明を限定するものではなく、また、実施形態で説明されている全ての構成が本発明の課題を解決するための手段に必須であるとは限らない。
【００１５】
［実施例１］
本実施形態に係る情報処理装置の一例として、以下では情報処理装置１００を例に説明する。
【００１６】
図１は、情報処理装置１００のハードウェア構成図である。
【００１７】
情報処理装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１０１、ＲＡＭ１０２、通信部１０３、外部入力部１０４、記憶部１０５から構成されている。
【００１８】
情報処理装置１００は、例えばＰＣ及びスマートフォン等の、ユーザからのＪａｖａプログラムの実行を要求する入力に応じて、Ｊａｖａプログラムを実行する情報処理装置であってもよい。また、情報処理装置１００は、クライアントからのＪａｖａ実行を要求する情報のネットワークを介した受信に応じて、Ｊａｖａプログラムを実行するアプリケーションサーバであっても良い。
【００１９】
ＣＰＵ１０１は、記憶部１０５に格納されたプログラムを実行することによって、情報処理装置１００としての処理を実行する。すなわち、記憶部３に格納されたプログラムは、本実施の形態に係る情報処理装置１００における処理を、ＣＰＵ１０１に実行させるためのコードを含む。このコードにはＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）のプログラム、アプリケーションＪａｒファイル１０６、ライブラリＪａｒファイル群１０７、標準ライブラリＪａｒファイル群１０８、Ｊａｖａ管理プログラム１０９が格納されている。記憶部１０５は、上記のファイルおよびプログラム等を格納可能なメモリ及びハードディスク等の記憶装置の少なくとも１つ以上を含み、構成されている。
【００２０】
ＲＡＭ１０２は、各種の情報を記憶する読み書き可能なメモリである。また、ＲＡＭ１０２は、ＣＰＵ１０１のワークエリアとしても利用される。例えば、ＣＰＵ２０１は記憶部１０５に記憶されているプログラムをＲＡＭ１０２にロードしてプログラムを実行する。なお、情報処理装置１００の機能及び後述するシーケンスに係る処理の全部又は一部については専用のハードウェアを用いて実現してもよい。
【００２１】
通信部１０３は、情報処理装置１００と他の情報処理端末との間でネットワークを介して任意の情報を送受信する。通信部１０３は、例えばネットワークアダプタ等の通信装置を含み構成されている。通信部１０３は、ＣＰＵ１０１から他の情報処理端末に送信するために出力された情報を、ネットワークを介して他の情報処理端末に送信する。また、通信部１０３は、他の情報処理端末からネットワークを介して送信された情報を受信し、ＣＰＵ１０１に出力する。
【００２２】
例えば、情報処理装置１００がクライアントからの実行要求に応じてＪａｖａアプリケーションを実行するアプリケーションサーバであってもよい。その場合、通信部１０３は他の情報処理端末からのＪａｖａアプリケーションの実行を要求する情報を受信した時にその情報をＣＰＵ１０１に出力する。そして、ＣＰＵ１０１は、通信部１０３からのＪａｖａアプリケーションの実行を要求する情報の出力に応じて、Ｊａｖａアプリケーションを起動する。
【００２３】
外部入力部１０４は、ユーザからの各種入力を受け付ける。外部入力部１０４は、例えばマウス、キーボード及びタッチパネル等の入力装置の少なくとも１つ以上を含んで構成されている。外部入力部１０４は、ユーザからの入力に応じて、その入力内容を通知する通知情報をＣＰＵ１０１に出力する。
【００２４】
続いて、Ｊａｖａプログラム用のバイトコードを実行するバイトコード実行端末２００のソフトウェア構成図について、図２を用いて説明する。
【００２５】
Ｊａｖａ仮想マシン２０１は、バイトコードと呼ばれる中間コードをＣＰＵ１０１が認識できるネイティブコードに変換する。さらに、Ｊａｖａ仮想マシン２０１は変換済みのネイティブコードをＣＰＵ１０１で実行する。Ｊａｖａ仮想マシン２０１はＪａｖａ管理プログラム１０９に含まれる。
【００２６】
クラスローダ２０２は、標準ライブラリＪａｒファイル群１０８をＪａｖａ仮想マシン２０１で使用可能な状態にするために読み込む。また、クラスローダ２０２は必要に応じてライブラリＪａｒファイル群１０７に含まれるＪａｒファイルを自動的に読み込む。クラスローダ２０２はＪａｖａ管理プログラム１０９に含まれる。
【００２７】
アプリケーション２０３は、バイトコード実行端末２００で所望の機能を達成するためのプログラムである。本実施例では、アプリケーション２０３が、標準ライブラリＪａｒファイル群１０８以外に、ライブラリＡ２０４とライブラリＢ２０５に依存しているものとする。
【００２８】
ライブラリＡ２０４は、アプリケーション２０３の機能実現に必要なプログラムを含む。また、本実施例ではライブラリＡ２０４がさらにライブラリＣ２０６に依存するものとする。
【００２９】
ライブラリＢ２０５は、アプリケーション２０３の機能実現に必要なプログラムを含む。また、本実施例ではライブラリＢ２０５がさらにライブラリＣ’２０７に依存するものとする。
【００３０】
ライブラリＣ２０６とライブラリＣ’２０７は、互いに同じ機能を提供することを目的としたライブラリである。すなわち、ライブラリＣ２０６とライブラリＣ’２０７は同じパッケージ名、クラス名、メソッド名で構成されている。ライブラリＣ２０６とライブラリＣ’２０７の違いは、バージョンの違いを意味している。つまり、ライブラリＣ２０６とライブラリＣ’２０７は内部の細かな挙動が異なり、ライブラリＡ２０４はライブラリＣ２０６との組み合わせのみ十分に考慮され、ライブラリＢ２０５はライブラリＣ’２０７との組み合わせのみ十分に考慮されているものとする。もし、異なる組み合わせ、例えばライブラリＡ２０４とライブラリＣ’２０７、の場合、同じパッケージ名、クラス名、メソッド名のため動作はする。しかし、その動作はほとんど考慮されておらず、不安定な状態に陥ったり、予測困難なバグの基となる可能性がある。
【００３１】
次に、Ｊａｖａプログラム用のバイトコードを生成する端末のソフトウェア構成図について、図３を用いて説明する。なお、バイトコードを生成する端末とバイトコードを実行する端末は同じであってもよい。
【００３２】
バイトコード生成端末３００はＪａｖａコンパイラ３０１と難読化部３０２を含む。
【００３３】
Ｊａｖａコンパイラ３０１はＪａｖａソースコードをＪａｖａ仮想マシン２０１が実行可能なバイトコードに変換する。
【００３４】
難読化部３０２はＪａｖａソースコードを、リバースエンジニアリングを防ぐためにパッケージ名、クラス名、メソッド名、変数名などを難読化する。例えば、ＰａｃｋａｇｅＡ．ＣｌａｓｓＢ．ＭｅｔｈｏｄＣというメソッドがあった場合、難読化の結果は、ＫＺＹｐｈ．ＯＦＶＱＪ．ｙＹｇＫｎといった解読困難な文字列となる。この結果、リバースエンジニアリングを試みる者が、一見何をするメソッドか分からないため、リバースエンジニアリングに対する耐性が向上する。
【００３５】
このバイトコード生成端末３００にて実行されるバイトコード生成処理について図４を用いて説明する。図４のバイトコード生成フローはＪａｖａソースコードからバイトコードを生成する際の処理フローである。
【００３６】
図４を説明するために、バイトコード生成端末３００が変換元のＪａｖａソースコードとしてライブラリＡ２０４とライブラリＢ２０５をバイトコードに変換することを考える。
【００３７】
Ｓ４０１において、バイトコード生成端末３００は対象がアプリケーション全体かそうでないかをチェックする。もし対象がアプリケーション全体であればＳ４０３に遷移し、アプリケーション全体で無ければＳ４０２に遷移する。
【００３８】
Ｓ４０２において、バイトコード生成端末３００はライブラリＡ２０４およびライブラリＢ２０５がさらに別のライブラリに依存しているかをチェックする。ここで、もし、依存するライブラリが無ければＳ４０６に遷移する。一方で、もし依存するライブラリがあればＳ４０３に遷移する。本実施例ではライブラリＡ２０４がライブラリＣ２０６に、ライブラリＢ２０５がライブラリＣ’２０７に依存しているため、Ｓ４０３に遷移する。
【００３９】
Ｓ４０３において、バイトコード生成端末３００は難読化用の乱数シードを生成する。ここで、難読化用の乱数シードとは、難読化処理において、難読化処理の結果が常に異なる結果となるよう難読化部３０２に与える乱数の基となる値である。一般に乱数シードは現在時刻や、情報処理端末の起動からのＣＰＵやタイマーのクロック数、または回路内の熱雑音値から生成される。しかし、乱数シードが安易に重複するようなことが無ければ、他の方法で生成しても良い。
【００４０】
Ｓ４０４において、バイトコード生成端末３００は非難読化設定ファイルを読み込む。非難読化設定ファイルは記憶部１０５に格納されているものとする。非難読化設定ファイルとは、対象ソースコードを難読化する時に、難読化から除外するパッケージ名、クラス名、メソッド名などが記載されたファイルである。非難読化設定ファイルは、外部に公開すべきＡＰＩを指定することで、公開ＡＰＩの難読化を行わず非公開ＡＰＩのみ難読化をするといった用途のために使用される。
【００４１】
Ｓ４０５において、バイトコード生成端末３００は対象アプリケーションまたは対象ライブラリとＳ４０３で生成した難読化乱数シードとＳ４０４で読込んだ非難読化設定ファイルを難読化部３０２に渡し難読化を依頼する。なお、この際に難読化部３０２に対して、変換辞書を渡しても良い。変換辞書とは難読化後の文字列のリストである。変換辞書を渡すことで難読化部３０２は難読化乱数シードを用いて生成した乱数から変換辞書に記載されたうちの一つの難読化文字列を決定する。もし、変換辞書が渡されなければ、難読化部３０２は難読化乱数シードを用いて生成した乱数から、重複しないように難読化後文字列を生成する。また、難読化部３０２に渡す難読化乱数シードは対象ライブラリのバージョンに合わせて決定しても良い。その結果、異なるバージョンのライブラリを１つのクラスローダの中で共存させることが出来る。さらに、難読化部３０２は難読化前と難読化後のシンボルが一体一に対応した難読化マップファイルを生成しても良い。難読化部３０２は、対象ソースコードに含まれる難読化前シンボルを難読化後シンボルに変換し、難読化済ソースコードを出力する。
【００４２】
Ｓ４０６において、バイトコード生成端末３００はＳ４０５にて出力された難読化済ソースコードをバイトコードに変換するよう、Ｊａｖａコンパイラ３０１に依頼する。Ｊａｖａコンパイラ３０１は入力である難読化済ソースコードをＪａｖａ仮想マシン２０１が解釈可能なバイトコードに変換する。
【００４３】
本実施例では、バイトコード生成端末３００が変換元のＪａｖａソースコードとしてライブラリＡ２０４とライブラリＢ２０５をバイトコードに変換することを考えた。他のライブラリＣ２０６、およびライブラリＣ’２０７はＳ４０２にて依存を持たないと判定されるため、難読化を行わない。一方でアプリケーション２０３が対象の場合、Ｓ４０１でＹｅｓとなるため難読化が行われる。一般的にはアプリケーション全体の難読化を１回だけ行うが、本実施例の場合、難読化が２重に行われることになる。
【００４４】
また、バイトコードに変換されたライブラリＡ２０４とライブラリＢ２０５はそれぞれライブラリ情報を含んだＪａｒファイルにパッケージ化されバイトコード実行端末２００のライブラリＪａｒファイル群１０７に格納されるものとする。同様にバイトコードに変換されたアプリケーション２０３はアプリケーションＪａｒファイル１０６に格納されるものとする。
【００４５】
次に、Ｊａｖａコンパイラ３０１が生成したバイトコードを読み込み、Ｊａｖａ仮想マシン２０１が実行可能な状態にするクラスローダ処理を、図５を用いて説明する。
【００４６】
バイトコード実行端末２００上でアプリケーションＪａｒファイル１０６に含まれるアプリケーションを実行したいとする。
【００４７】
図５のクラスローダ処理は、Ｊａｖａ管理プログラム１０９に含まれるクラスローダ２０２がアプリケーションＪａｒファイル１０６に含まれるクラス群を、Ｊａｖａ仮想マシン２０１に読み込み、実行可能な状態にする処理である。
【００４８】
Ｓ５０１において、クラスローダ２０２が対象とするＪａｒファイルから対象クラスをＪａｖａ仮想マシン２０１に読み込む。
【００４９】
Ｓ５０２において、クラスローダ２０２はＳ５０１で読み込んだ対象クラスが難読化されたバイトコードを含む難読化クラスに依存しているかを判定する。もし難読化クラスに依存している場合Ｓ５０３に遷移する。一方で対象クラスが難読化クラスに依存していない場合、Ｓ５０５に遷移する。
【００５０】
Ｓ５０３において、クラスローダ２０２は対象クラスが依存している難読化済クラスをライブラリＪａｒファイル群１０７から探索する。
【００５１】
ここで、クラスローダ２０２は対象クラスが依存している難読化済クラスをライブラリＪａｒファイル群１０７から発見できなかった場合、単にエラーとして続行不可能な状態にしても良い。また、単にエラーとするだけでなく、クラスローダ２０２が難読化済クラスを見つけられなかった場合、旧バージョンの難読化済クラスを探索しても良い。バイトコード実行端末２００に含まれるライブラリの依存関係を基に具体的に例を挙げる。クラスローダ２０２がライブラリＢ２０５をＪａｖａ仮想マシン２０１に読み込もうとした時、非依存ライブラリであるライブラリＣ’２０７を探索することとなる。ここで、仮にライブラリＣ’２０７がライブラリＪａｒファイル群１０７に含まれていなかったとする。その時、クラスローダ２０２は同ライブラリの別バージョンであるライブラリＣ２０６を探索対象としてフォールバック処理をしても良い。さらに、クラスローダ２０２がライブラリＣ’２０７の別バージョンライブラリＣ２０６を発見した時、情報処理装置１００を使用するユーザに対して、意図したバージョンとは異なる組み合わせである旨を通知しても良い。その結果、意図した組み合わせがライブラリＪａｒファイル群１０７に含まれていない時に単に動作しない代わりに、ユーザから承諾を得た上で、異なるライブラリの組み合わせでアプリケーション２０３の動作を試みることが出来る。
【００５２】
Ｓ５０４において、クラスローダ２０２はＳ５０３で探索の結果発見した難読化済クラスをＪａｖａ仮想マシン２０１に読み込む。
【００５３】
Ｓ５０５において、クラスローダ２０２はアプリケーションＪａｒファイル１０６に必要な未だＪａｖａ仮想マシン２０１に読み込まれていない未解決クラスがあるかをチェックする。もし未解決クラスがあった場合、Ｓ５０１に遷移する。一方で、もし未解決クラスがなく、アプリケーションＪａｒファイル１０６が実行可能な状態であると判定した場合、本処理を抜ける。
【００５４】
図５で説明したクラスローダ処理を行うと、Ｊａｖａ仮想マシン２０１による実行時に、各ライブラリとバイトコード生成時の依存するライブラリのバージョンの組み合わせの通りに実行することが出来る。具体的にはライブラリＡ２０４はライブラリＣ２０６を使用することが保証できる。同様にライブラリＢ２０５はライブラリＣ’２０７を使用することを保証できる。さらに依存するライブラリのバージョンに合わせて難読化乱数シードを固定することで、複数の依存するライブラリを１つのＪａｖａ仮想マシン２０１内に共存させることができる。また、既存の依存関係を保障する必要のないライブラリに関しては、クラスローダ２０２がＳ５０１で対象ライブラリのクラスをＪａｖａ仮想マシン２０１に読み込む。
【００５５】
以上にように、本実施形態によれば、通常ならば所望のライブラリの組み合わせで動作しない可能性のある構成であっても、実行時に必ず意図した依存関係を保証できるようになる。その結果、難読化という工程に予測困難なエラーやバグを減らすことが出来る付加価値を付与できるようになる。
【００５６】
［その他の実施例］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５７】
１００  情報処理装置、１０１  ＣＰＵ、１０２  ＲＡＭ、１０３  通信部、
１０４  外部入力部、１０５  記憶部
【図１】
2019020933.tif 000003
【図２】
2019020933.tif 000004
【図３】
2019020933.tif 000005
【図４】
2019020933.tif 000006
【図５】
2019020933.tif 000007