ウイルス対策会社、モバイルアプリストア、およびセキュリティ研究者は、動的なコード分析技術を使用して、モバイルの悪意のあるアプリケーションを検出および分析します。 この記事では、悪意のあるアプリケーションがエミュレートされたAndroidプラットフォーム環境で動的分析をバイパスするために使用できる、さまざまな分析対策手法を紹介します。
この記事で紹介する検出ヒューリスティックは、（i）静的プロパティ、（ii）センサーからの動的情報、および（iii）仮想マシン上のAndroidエミュレーターの複雑さに基づく3つの異なるカテゴリーをカバーしています。 提示された方法の有効性を評価するために、それらは実際の悪意のあるアプリケーションのサンプルに含まれ、公開されている動的分析システムに送信され、その後、驚くべき結果が得られました。 すべてのツールとサービスは、ほとんどの分析回避手法に対して脆弱であることがわかりました。 IMEI値のチェックなどの簡単な手法でさえ、既存の動的分析環境をバイパスするには十分です。 分析を回避する試みに対する現在の動的分析ツールの安定性を改善するために、可能な対策も提案されています。
1.はじめに
Android OSの人気は、このプラットフォームのオープン性と相まって、攻撃者にとって魅力的な標的となっています[13]。 ウイルス対策メーカーと研究者は、悪意のあるアプリケーションを分析するためのサービスとツールを介して、この増大するセキュリティの懸念に対応しています。 Googleは、悪意のあるアプリケーションを自動的にスキャンおよびスキャンするためのサービスであるBouncer [1]も作成しました。 潜在的に隠された悪意のあるアクションを検出するためのアプリケーションのスキャンは、静的分析[22、25]および動的分析[14、17、19、28]に基づくことができます。 残念ながら、静的アプローチと動的アプローチの両方を回避できます。 静的解析に関して、研究者は現在利用可能な静的解析ツールを回避できる一連の技術を実証しました[30]。 このペーパーで示すように、エミュレーションを使用して悪意のあるAndroidアプリケーションを調査する動的分析も理想的ではありません。 悪意のあるプログラムは、エミュレートされた環境で実行されているかどうかを推測し、その結果、すべての悪意のあるアクションを一時停止することで検出を回避する場合があります。
この記事では、AndroidアプリケーションがエミュレートされたARMプロセッサまたは実際のデバイスで実行されていると結論付ける方法について詳しく説明します。 まず、ヒューリスティックセットを使用してランタイム環境の特性を決定するために、可能なパスの体系が作成されます。 この記事で紹介するヒューリスティックは、広範囲の複雑さをカバーしています。 それらのほとんどは単純であり、デバイスシリアル番号（IMEI）などの静的プロパティの現実的な値など、不正なヒューリスティックのエミュレートされた環境での簡単な変更によって防止できます。 エミュレートされた環境は、加速度計などのモバイルセンサーからの現実的なデータを提供する必要があるため、他のものはより信頼性が高くなります。 最後に、エミュレートされた環境の設計で多くの重要な変更が必要であることに対処するために、一連のヒューリスティックがここに提示されます。
この記事で行われた結論の重要性を評価するために、悪意のあるアプリケーションの関連画像のセットが再パッケージ化されました。 開発されたヒューリスティックがこれらの画像に追加され、オンライン分析ツールに送信されました。 奇妙なことに、テスト済みの分析ツールはすべて、提示されたヒューリスティックを使用して回避できます。 テストされたすべてのヒューリスティックに対処できるマルウェア分析サービスは見つかりませんでした。 さらに、テストした12個の分析ツールのうち少なくとも5個は、IMEI値のチェックなどの単純なヒューリスティックを使用して回避できます。 仮想マシンの複雑さに基づくより複雑なヒューリスティックは、4を除くすべてのテスト済みサービスを回避できました。これら4つのサービスは、マシンコードの実行をサポートしていないため、Androidアプリケーションのサブセットを実行するために使用できません。 最後に、テストされたすべてのサービスは、センサー（センサー）からの情報に基づくヒューリスティックに対して脆弱です。
悪意のあるアプリケーションを分析するための既存の方法は、現在の悪意のあるアプリケーションが公的に利用可能なマルウェア分析サービスから悪意のある機能を隠すことができるという事実を示すことで簡単に回避できることに注意する価値があります。 エミュレートされた環境でのAndroidアプリケーションの分析を、それを迂回する試みに対してより耐性を持たせるために、一連の対策が提案されています。
2.分析に対抗する手法
Androidアプリケーションで検出をバイパスするために使用できる分析防止技術は、次の3つのカテゴリに分類できます。（a）エミュレート環境で常に固定値に初期化される静的情報に基づく静的ヒューリスティック、（b）さまざまなセンサーの非現実的な動作の観察、および（c）実際の機器の不完全なエミュレーションに基づくハイパーバイザーのヒューリスティック。 表1に、すべてのカテゴリの簡単な説明といくつかの典型的な例を示します。
表1.モバイル悪意のあるアプリケーションが使用できる仮想マシンのヒューリスティック検出の主な種類の簡単な説明と典型的な例
2.1。 静的ヒューリスティック
静的セットには、存在確認またはシリアル番号（デバイスID）、アセンブリの現在のバージョン、ルーティングテーブルの値などのデバイスの一意の識別子に含まれる値を使用してエミュレートされた環境を検出するために使用できるヒューリスティックが含まれます。
デバイスのシリアル番号（デバイスID）。 各スマートフォンには、IMEI（International Mobile Station Equipment Identifier）が含まれています。これは、GSMネットワークでそれを識別する一意の番号です。 IMEIは、エミュレーターで実行されているマルウェア検出ツールを使用した分析を妨害するために、悪意のあるアプリケーションによって既に使用されています[2]。 別のモバイル識別子はIMSI（International Mobile Subscriber Identity）であり、これは電話で見つかったSIMカードに関連付けられています。 単純な回避ヒューリスティックは、たとえば、IMEI値がnullの場合、これらの識別子をチェックすることに基づいています。これは、デフォルトのAndroidエミュレーター構成に当てはまります。 略語idHは、このタイプのヒューリスティックを参照するために使用されます。
ビルド番号 エミュレートされた環境を識別する別の方法は、システムプロパティから抽出された現在のアセンブリに関連付けられた情報を確認することです。 たとえば、Android SDKは、アプリケーションがエミュレーターで実行されていることを検出するために表示できるPRODUCT、MODEL、HARDWAREなどのフィールドに関する情報を提供するパブリックビルドクラスを提供します。 たとえば、エミュレーターの標準Androidイメージには、PRODUCTおよびMODELフィールドがgoogle_sdkに設定され、HARDWAREフィールドがgoldfishに設定されています。 同様のチェックに基づくいくつかのヒューリスティックが特定されました。これについては、後でbuildHという略語を使用して参照します。
ルーティングテーブル。 デフォルトでは、エミュレートされたAndroidデバイスは、ターゲットマシンのネットワークから分離された10.0.0.2/24のアドレススペースを持つ仮想ルーターの背後で実行されます。 エミュレートされたネットワークインターフェイスは、10.0.2.15のIPアドレスで構成されます。 デフォルトゲートウェイとDNSサーバーの構成には、固定値も含まれています。 このホワイトペーパーでは、ネットワークパラメータを検出ヒューリスティックの別の方法として使用します。 特に、ヒューリスティックは、ソケットのリッスンと接続の確立（/ proc / net / tcp経由）をチェックし、エミュレートされた環境の指標として、アドレス10.0.2.15および0.0.0.0に関連付けられたポート番号を見つけようとします。 略語netHは 、このヒューリスティックを指すために使用されます。
2.2。 動的ヒューリスティック
携帯電話には、加速度計、ジャイロスコープ、GPS、重力センサーなどのさまざまなセンサーが搭載されています。 実際、これらのセンサーの出力値は環境から収集された情報に基づいているため、現実的なエミュレーションは複雑なタスクです。 センサーの存在は、スマートフォンと従来のコンピューティングシステムの主な違いです。 スマートフォンのセンサー数の増加により、実際のモバイルデバイスを識別するための新しい機会が提供されるため、差異の確立とエミュレーターの検出が可能になります。 たとえば、センサーの欠陥と欠陥に基づくスマートフォンの特徴に焦点を当てた研究があります[3、20]。 特徴的な機能に基づくこれらのアプローチは、エミュレートされた環境を検出するために使用できます。
デフォルトでは、Androidエミュレーターは空間内のデバイス行のエミュレーションをサポートしていません。 これは、追加のセンサーシミュレーターを使用して実現できます[4]。 Androidエミュレータの現在のビルドでは、他の種類のセンサーのシミュレーションも部分的にのみサポートされているか、まったくサポートされていません。 使用可能なシミュレートされたセンサーをテストすると、エミュレータは0.8秒の等しい平均間隔でわずかな標準偏差（0.003043秒）で同じ値を生成することがわかりました。 2分間のAndroidエミュレーターの動作中に観測された、加速度計のイベント間の時間間隔の分布関数を図1に示します。この関数は、他のセンサーの同じスキームに準拠していることがわかりました。 センサーベースのヒューリスティックは、Android APIのSensorManagerクラス[5]を使用して実装されました。 次のアプローチを使用して、センサーリスナーを登録してその出力値を追跡しようとするAndroidアクティビティ（アプリケーション画面）が開発されました。
まず、センサーリスナーが登録されます。 登録が失敗した場合、エミュレートされた環境で実行される可能性が高くなります（実際のデバイスが特定のセンサーをサポートしていない場合を除く）。 それ以外の場合、センサーの登録が成功すると、onSensorChangedコールバックメソッドの値がチェックされます。これは、センサー値が変更されたときに呼び出されます。 センサーの値または観測された時間間隔がこのメソッドの連続呼び出し中に変化しない場合、アプリケーションはエミュレートされた環境で実行されていると見なされ、センサーリスナーの登録はキャンセルされます。 加速度計（ accelH ）、磁場（ magnFH ）、回転（ rotVecH ）、近接（ proximH ）、ジャイロスコープ（ gyrosH ）のセンサーに基づくヒューリスティックが実装されました 。
図1.実行中のAndroidエミュレーターで数分間観察された加速度計イベント間の間隔のHFD
2.3。 ハイパーバイザーヒューリスティック
スイッチングコンテキストQEMUの定義。 このヒューリスティックは、QEMU [26]のコンテキストスイッチングメカニズムと、QEMUがパフォーマンス上の理由により各命令の実行中に仮想コマンドカウンター（仮想PC）の値を更新しないという事実に関連しています。 翻訳された命令はターゲットマシンで実行されるため、 仮想命令カウンターを増やすには追加の命令が必要です。したがって、ジャンプ命令などの線形実行に違反する命令が実行される場合にのみ、仮想命令カウンターを更新するだけで十分かつ高速です。 つまり、ベースユニットの実行中にコンテキストの切り替えが発生した場合、仮想コマンドカウンターの値を計算することはできません。 このため、QEMU環境でのコンテキストスイッチングは、ベースユニットが実行された後にのみ発生し、実行中には発生しません。
この概念の証明として、ストリームのアドレス計画のヒストグラムに基づいて、 QEMU BT検出技術が既に開発されています[26]。 エミュレートされていない環境では、コンテキストの切り替えがいつでも発生するため、コンテキストの切り替えが発生すると、広範囲の時間間隔を観察できますが、エミュレートされた環境では、コンテキストの切り替えは常にベースユニットの開始時に特定の時間に発生します。完全な基本ユニットが完成しました。 この手法は、 BTdetectHという略語で別のヒューリスティックとして実験で実装および使用されました。 図 図2は、Androidエミュレーターと実際のデバイスでこのヒューリスティックを実行する場合のコンテキスト切り替え時間の違いを示しています。
図2.最適化のために、QEMUは各命令の実行後に仮想コマンドカウンターの値を更新しないため、発生した可能性のあるコンテキスト切り替えイベントの多くはエミュレートされた環境では観測されません
自己修正コードを実行してQEMUを定義します。 2番目のヒューリスティックとして、QEMUがコードページの変更を追跡しないという事実に基づいて、新しいQEMU検出手法（ xFlowHと呼ばれる）が実装されました。 この手法は、エミュレーターと実際のデバイスでの自己修正コードの実行に起因する実行スレッドの違いに基づいています。
ARMプロセッサには、2つの異なるキャッシュがあります。1つは命令にアクセスするため（I-Cache）、もう1つはデータにアクセスするため（D-cache）です。 ハーバードアーキテクチャ（ARMなど）は、データキャッシュと命令キャッシュの一貫性を提供しません。 したがって、プロセッサは、新しいコードがすでにメインメモリに書き込まれた後、古いコード（無効なコード）を実行できます。 この状況は、2つの操作間の一貫性を維持することで解決できます。これは、2つの操作を使用して実現できます。1）データキャッシュにある新しいコードがメインメモリに混入するようにメインメモリをクリーニングする2）命令キャッシュを無効にして、メインメモリからの新しいデータで満たされるようになりました。 Androidネイティブコードでは、これはcacheflush関数を呼び出すことで実行できます。この関数は、システムコールを介して上記の操作を実行します。
実行および書き込みの権限を持つメモリセグメントを使用する自己変更（マシン）コードの例を実装しました。これは、2つの異なる関数f1およびf2の内容によってサイクル内でそれぞれ何度か書き換えられます。 コードが変更されるたびに、このセグメントのコードが起動され、 f1またはf2が起動されます。 これらは2つの単純な関数であり、どちらもグローバル文字列変数の末尾に名前を追加するため、関数呼び出しのシーケンスについて結論付けることができます。 交互の呼び出しシーケンスを実現するには、 前述のように、キャッシュをcacheflush呼び出しと同期する必要があります。
このコードは、各変更後の同期のための追加の呼び出しとともに、同じ結果でモバイルデバイスとエミュレーターで起動されました。各起動は、サイクルで定義されているように、関数の順次起動を行いました。 次に、同じ実験が実行されましたが、今回はcacheflash呼び出しが除外されました 。 予想どおり、各起動後にモバイルデバイスでランダムな一連の呼び出しが観察されました。 キャッシュは各呼び出しの前に同期されないため、命令キャッシュは明らかに無効化されていない（無効である）ため、古い命令が含まれている可能性があります。 興味深いことに、この動作はエミュレーターでは観察されないことがわかりました。 その代わり、呼び出しのシーケンスは、各関数呼び出しの前にキャッシュが一貫していた最初のケースとまったく同じでした。 QEMUはコードの以前のバージョンの翻訳されたベースユニットを破棄し、コードページの変更を追跡し、生成されたコードがメモリ内のターゲット命令と常に一致することを保証するため、この動作が期待されます[16]。
3.実装
セクション2で説明したAndroid SDKを使用したヒューリスティックが実装されました。 BTDetecHおよびxFlowHでは、Javaネイティブインターフェイス（JNI）を使用して、各ヒューリスティックの機能を実装するマシンコードを実行しました。 バックグラウンドで提案されたヒューリスティックを実行し、それぞれの有効性に関する情報を収集する単純なAndroidアプリケーション（テストアプリケーション）が開発されました。 収集された情報は、ローカルデータベースに保存するためにHTTPサーバーに送信されます。 さらに、開発されたヒューリスティックは、有名な悪意のあるAndroidアプリケーションのセットに含まれていました。 このために、Smali / Backsmali [7]とAptktool [8]を使用しました。これらは、分解および再組み立て（アプリケーションの再パッケージ化）に使用しました。 マルウェアにヒューリスティックを含めるには、開発済みのテストアプリケーションから以前に抽出された各ヒューリスティックの逆アセンブラーを使用して生成されたSmali Dalvikバイトコードを挿入しました。 表2に示すように、各悪意のあるアプリケーションは、実装されたヒューリスティックのいずれかを含むように変更されています。
最初に、各元のサンプルはエミュレーターと実際のデバイスで実行され、その動作はメインのアクティビティ（アプリケーション画面）とサービスを開始するときにlogcatコマンド（Androidロギングシステム）を使用して観察されました。 その後、アプリケーションのこれらのコンポーネントは、開発されたヒューリスティックのいずれかによって変更され、ヒューリスティックの結果に応じて、コンポーネントの実行を停止するかどうかを決定しました。
表2.調査で使用された悪意のあるアプリケーションのサンプル
再パッケージ化されたアプリケーションは、シミュレーターと実際のデバイスでテストされ、悪意のある動作が実際のデバイスでのみ発生することを確認しました。 悪意のあるアプリケーションの受信コードの上記の変更に加えて、以下の場合を除き、APKファイルの他の部分に他の追加の変更は必要ありません。 ヒューリスティックidHには、Androidマニフェストファイルで明示的に宣言されたREAD_PHONE_STATE権限が必要で、電話の状態を読み取ることができます。 ヒューリスティックBTDetectHおよびxFlowHの場合、共有ライブラリの形式で必要なマシンコードを含むアプリケーションのルートディレクトリにlibディレクトリを作成する必要があります。
4.実験評価
このセクションでは、セクション2で説明したヒューリスティックの有効性の評価結果を示します。各ヒューリスティックを実際の悪意のあるアプリケーションに追加し、さまざまなサービスと動的分析ツールを使用して分析しました。 各ケースについて、どのヒューリストがエミュレータを見つけたのか、見つけなかったのかについての情報が記録されました。 最初に、作業で使用されるマルウェアと動的分析サービスのセットの説明を行い、次に方法論の簡単な概要を説明し、最後に調査結果を提示して説明します。
4.1。 データとツール
悪意のあるアプリケーションのサンプル。 セクション3で説明したプロセスを使用して、いくつかの有名な悪意のあるAndroidアプリケーションに検出技術者コードが追加されました。 特権エスカレーションのエクスプロイト、機密情報の漏洩、SMSトロイの木馬など、さまざまな機能を持つ悪意のあるアプリケーションのさまざまなファミリから10個のサンプルが使用されました。 すべてのテスト済みサンプルは公開されており、Contagio Minidumpの一部です[9]。 表2に、使用される悪意のあるアプリケーションのサンプルと、各ケースで使用されるヒューリスティックをまとめます。
動的分析サービス。 評価に使用したサービスと動的分析ツールを表3に示します。ダウンロードおよびローカルで使用できるスタンドアロンの分析ツールと、送信されたサンプルをオンラインで分析するオンラインサービスの両方を使用しました。
Androidアプリケーションの分析には、DroidBox [10]、DroidScope [35]、TaintDroid [21]の3つの一般的なツールが使用されました。 3つのツールはすべて、仮想環境でAndroidアプリケーションを実行し、分析レポートを作成します。 DroidBoxは、着信/発信トラフィック、読み取り/書き込み操作、サービスと呼ばれる情報、アプリケーションのアクセス許可のバイパス、SMSの送信、電話の発信などに関する情報を提供します。 DroidScopeは、OSおよびAPI呼び出しのレベルでAndroidアプリケーションのプロファイルを作成し、情報漏洩のアイデアを提供します。 TaintDroidは、機密データの複数のソースからのデータフローのシステム全体の追跡を効率的に実行できます。
表3.評価で使用したAndroidマルウェア分析ツールとサービス
スタンドアロンツールに加えて、以下で簡単に説明するAndroidアプリケーションの動的分析を実行できる公的に利用可能なオンラインサービスも使用されています。 Andrudis [14]は、不要なAndroidアプリケーションの静的分析と動的分析の両方を実行します。 SandDroidは、アプリケーションの権限/コンポーネントの分析、および悪意のあるアクションの検出/分類を実行します。 ApkScanは、ファイルアクセス、ネットワーク接続、通話、送信されたSMS、情報漏洩、暗号化アクティビティへのアクセスを含む情報を提供します。 VisualThreatは、ネットワークアクティビティやデータ漏洩から、API呼び出しの相関関係を持つ悪意のあるアプリケーションファミリの検出まで、幅広いアクティビティをカバーする情報を提供します。 TraceDroidは、ユーザーの対話、着信呼び出し、悪意のある意図を検出できるSMSメッセージなど、アプリケーションを分析するときにいくつかのアクションをエミュレートします。 CopperDroid [31]はQEMUに基づいて構築されており、「そのまま」Androidアプリケーションの動的分析を実行できます（OSレベルとAPIレベルの両方で）。 APK Analyzer、ForeSafe、およびMobile Sandbox [33]も、上記のツールで説明したアプローチに従ってモバイルマルウェアアプリケーションを調べる動的分析サービスです。
4.2。 方法論
提示されたヒューリスティックの有効性を評価するために、2つの異なるアプローチが使用されました。 最初のアプローチでは、セクション3で説明したすべてのヒューリスティックを含むアプリケーションのインスタンスが、セットの各オンラインサービスに送信されました。 分析中に、アプリケーションはヒューリスティックの有効性を確認し、それらを順次適用して、エミュレートされた環境で実行されるかどうかを判断します。 チェックされたヒューリスティックごとに、アプリケーションは結果をHTTPサーバーに送信します。 その後、どのヒューリスティックが仮想化された環境を識別するのに効果的で、どれが効果的でないかを判断できます。
より現実的な分析を実行し、そのようなヒューリスティックがさまざまな動的分析ツールの作業を複雑にし、間違った結論を導き出さないようにするために、別のアプローチを検討してください。 これを行うには、既存の悪意のあるアプリケーションが、セクション3で説明されている1つのヒューリスティックを含むように変更され、元のサンプルと各サービスに再パッケージ化されたものの両方が送信されます。 次に、生成されたレポートを収集して比較し、観察された動作の違いを見つけます。
表4.仮想マシンを回避する手法に対する動的分析ツールの安定性。 「✓」はそれらに対する脆弱性を意味し、「them」はそれらに対する脆弱性を意味し、「JNI NS」はJNI（Javaアプリケーションからマシン関数を呼び出す）のサポートの欠如を意味します
4.3。 回避結果
有効性評価の結果を表4に示します。最初の3行はスタンドアロン分析ツールに関連し、残りはオンライン分析サービスに関連しています。 以下は、収集された結果に基づく重要な調査結果です。
結論1. 調査したすべてのツールと動的分析サービスは、5つ以上のヒューリスティックに対して脆弱です。 表4に見られるように、テストされたすべてのツールは、提案されたヒューリスティックの1つだけを使用して簡単に回避できます。 特に、12個のツールのうち6個だけが、デバイスのIMEI値をチェックするidH単純な静的ヒューリスティックに耐性があります。 提示されたすべての静的ヒューリスティックに耐性があることがわかった分析サービスは、Apk Analyzerのみでした。 さらに、すべてのサービスは、デバイスセンサーの使用に基づく動的なヒューリスティックや、QEMUコード生成アルゴリズムの複雑さに関する知識を活用するハイパーバイザーヒューリスティックに対して脆弱です。 4つのツール（DroidBox、TaintDroid、ApkScan、Apk Analyzer）はマシンコードの実行をまったくサポートしていないことに注意してください。つまり、ハイパーバイザーヒューリスティックの有効性をテストすることはできません。 この結論は、テストアプリケーションがJNIを介してマシンコードをロードしようとしたときに例外メッセージを受信した後に行われました。 これらのメッセージはすべて、結果を含むhttp要求に含まれていました。
結論2. すべての分析ツールは、悪意のあるアプリケーションの再パッケージ化されたサンプルの悪意のある動作に関する正しい結論を引き出すことができませんでした。 分析ツール（スタンドアロンとオンラインの両方）を調査して手動で作成したすべてのレポートを比較し、評価の2番目のアプローチを順守し、観察された結果は最初の方法論に関連するものと一致しています。つまり、特定のヒューリスティックを含む再パッケージ化されたサンプルは、悪意のある動作を正常に隠すことができ、以前は同じヒューリスティックに対して脆弱であることが判明したツールから気付かれることはありません。これは、観測されたインシデントとアクティビティの数の減少、および観測されたネットワークトラフィックの減少により検証されました。
結論3. 調査したすべてのオンライン分析サービスは、ランタイムに関する情報に基づいて特徴付けることができます。分析中、最初のアプローチを使用したオンライン分析サービス（CopperDroid、Visual Threat、APK Analyzer）からの結果を含む単一のリクエストは受信されませんでした。明らかに、これらのツールは、ネットワーク接続が切断された環境でアプリケーションを分析します。それでも、分析中のアプリケーションがファイルを書き込もうとすると、その名前がこれらすべてのツールの結果ページに表示されることがわかりました。したがって、このトリックを使用して、特定のヒューリスティックが成功したかどうかを示す特別な名前を持つファイルを作成することにより、提示されたヒューリスティックの有効性をテストしました。したがって、このアプローチを使用して、分析サービスの特性評価に使用できるアセンブリ情報などの環境情報について結論付けることができます。
4. .各分析ツールで生成されたレポートを分析することにより、Apk Analyzerのみが送信されたサンプルの分析バイパスを検出し、受信したレポートで適切な警告を生成できることがわかりました（たとえば、「分析を防ぐために仮想マシンを検出しようとした可能性があります」というメッセージ"）。さらに、クロールに一致する動作を見つけるために使用されるパスを報告します。たとえば、idHおよびbuildHヒューリスティックを含む再パッケージ化されたインスタンスの場合、彼はサンプルの実行中にメモリ内で見つかった文字列に関連する仮想マシンアーティファクトについて言及しています。さらに、Androidエミュレーターで使用されるデフォルトのネットワークインターフェイスのIPアドレスが値10.0.2で変更されたため、netHヒューリスティックもこのサービスでは無効でした。15から192.168.0.24の値。それでも、私たちが開発したnetHヒューリスティックは、それが変更され、任意のIPアドレスと0.0.0.0を検索する場合、ADBポートが/ proc / net / tcpインターフェイスで関連付けられている場合、改善できます。
Apk Analyzerは提示された静的ヒューリスティックに耐性があることが判明しましたが、これは動的ヒューリスティックには適用されません。実際、Apk Analyzerからその動作を隠すには、パックされたサンプルで1つのヒューリスティック、たとえばaccelHを使用するだけで十分であることがわかりました。さらに、動的ヒューリスティックを含む再パッケージされたすべてのサンプルについて、Apk Analyzerは仮想マシンの検出の試行に関連するアラートを生成しないことがわかりました。
5.対策
仮想マシン検出機能を備えたモバイルの悪意のあるアプリケーションは、検出を回避し、エミュレーターに基づいて動作する動的分析ツールの動作を無効にする能力があるため、深刻な脅威をもたらす可能性があります。さらに、Google Playで公開できる悪意のあるアプリケーションを検出するために使用される公式ツールであるGoogle Bouncerは、QEMUに基づく標準のエミュレートされたAndroid環境で実行される動的分析に基づいています。 Google Bouncerは、環境検出技術に対しても脆弱です[11]。このセクションでは、より現実的にするために、現在のエミュレートされたAndroid環境に適用できる一連の保護を提供します。
エミュレータの変更。提示された静的ヒューリスティックに耐性を持たせるために、Androidエミュレーターを簡単に変更できます。 idHヒューリスティックで使用されるIMEIやIMSIなどのモバイルデバイス識別子は、Androidエミュレーターで構成できます。 AndroidエミュレーターでTelephony Managerサービスのソースコードを表示および分析することで、QEMUの一部として実装されているモデムデバイスがエミュレートされる場所を見つけることができます[12]。このようにして、エミュレータが実際のデバイスに似るように、IMEIとIMSIを簡単に変更できます。現在のビルドに関する情報を使用するbuildHヒューリスティックは、Androidエミュレーターにロードされたビルドプロパティを変更することで簡単にだまされる可能性があります。これらのプロパティは、Androidエミュレーターのソースコードのbuild.propファイルで定義されています。ついにAndroidエミュレーターのデフォルトのネットワーク設定は、Apk Analyzerと同様に、netHヒューリスティックから保護するために変更できます。
.ヒューリスティックの2番目のセットである動的ヒューリスティックは、モバイルデバイスでサポートされるさまざまなセンサーに基づいています。すでに述べたように、Androidエミュレーターは、センサーイベントの正確な時間間隔と取得された値が連続するイベント間で変化しない状態で、簡単に検出可能なセンサーのシミュレーションをサポートします。すべての動的ヒューリスティック（accelH、magnFH、rotVacH、proximH、およびgyroH）は、この動作に基づいています。すべての動的ヒューリスティックを非効率的にするには、センサーのより良いシミュレーションが必要です。ただし、このようなハードウェアコンポーネントの現実的なシミュレーションは複雑なタスクであり、デバイスで生成できる値の範囲とユーザーインタラクションの現実的なモデルの両方についての深い知識が必要です。この文脈では、外部シミュレーションプログラム[4]または記録および再生ソリューション[23]を使用して、Androidエミュレータの追加コンポーネントとしてセンサーデータをリアルタイムでシミュレートできます。
.BTdetectHヒューリスティックのベースとなっているQEMUで使用されるバイナリバイナリ変換は、Androidエミュレーターでの重要な操作であり、その間に各ARM命令が同等のx86命令に変換され、x86ベースのターゲットマシンでの実行が可能になります。セクション2で前述したBTdetectHヒューリスティックは、変更するのが非常に難しいAndroidエミュレーターの基本的な動作に基づいています。この問題を解決する1つの方法は、デバイスのプロセッサで使用される実際の実行に対してQEMUバイナリ変換プロセスをより正確にすることです。つまり、仮想命令カウンタは、命令がプロセッサで実行されるときに発生するように、常に命令の後に更新される必要があります。したがって、これには、QEMUの現在のバイナリ変換操作のレビューと拡張が必要です。一方、このアプローチでは、実行負荷が高くなり、QEMU、つまりAndroidエミュレーターが容易に検出可能になります（たとえば、エミュレーターと実際のデバイスで観察される特定の操作の異なるランタイムを比較することにより）。
ハードウェア仮想化をサポートします。この問題に対処する別の方法は、ハードウェア仮想化サポートを使用することです。これは、仮想マシンモニターの作成を支援し、ゲストオペレーティングシステムを相互に分離して実行できるアーキテクチャサポートに基づいています。たとえば、ハードウェア仮想化ARM [15]をサポートする開発技術を使用して、バイナリ変換のプロセスとそれに関連する問題を回避できます。エミュレーション命令（QEMU）をこのようなテクノロジーに置き換えると、仮想マシンの複雑さに基づくBTdetecHおよびxFlowHのヒューリスティックは非効率になります。
混合アプリケーションの実行。さらに、ハイパーバイザーヒューリスティックの別のソリューションは、実際のモバイルデバイスを使用してネイティブコードアプリケーションを実行することです。両方のヒューリスティック（BTdetecHおよびxFlowH）が機能するには、マシンコードが必要です。混合アプリケーションの実行は、動的分析ツールが提案されているすべてのヒューリスティックを回避するための最も安全で最も効果的な方法です。つまり、アプリケーションのバイトコードは、上記のすべてのセキュリティ対策で保護されたAndroidエミュレーターの修正バージョンで実行できます。アプリケーションがマシンコードをダウンロードまたは実行しようとすると、マシンコードの実行がリダイレクトされ、実際のデバイスで実行されます。
6.関連作品
Rastogiとその他[30]は、Androidデバイスで利用可能なさまざまな難読化方法に対して、最高の市販のウイルス対策製品を評価しました。結果に基づいて、テストしたすべての製品は、一般的な難読化方法に対して脆弱でした。彼らの研究は静的解析ツールに基づいていました。対照的に、Android向けの動的分析ツールを評価するために、本書では同様のアプローチが使用されました。 Savarら[32]は、タグ付きデータを動的に追跡することは、悪意のあるAndroidアプリケーションの機密データの漏洩を検出するのに効果的ではないと主張し、悪意のあるアプリケーションがデータの追跡を回避するために使用できるTaintDroidに対する複雑な攻撃も実装しましたこの研究では、TaintDroidを使用して、提示されたヒューリスティックの有効性を評価しました。
従来のシステムで仮想マシンを回避することを目的とした多くの研究があります。 Raffetzedder et al。[29]は、システムエミュレータを検出するためのいくつかの方法を提示しました。それらの方法は、特定のプロセッサエラー、MSRレジスタ、命令長の制限、相対的なパフォーマンスの測定など、さまざまな機能を使用します。ウィリアムズなど[34]は、実際のマシンとエミュレーターで暗黙的に異なる動作を行うコードシーケンスを導出することから成る異なるアプローチを提示しました。これらの手法は、特定の操作の副作用とエミュレーションプロセスの不完全性に基づいており（たとえば、自己修正コードをサポートするアーキテクチャでエミュレートされている場合、アプリケーションは異なる制御フローパスをたどることができます）、xFlowHヒューリスティックで使用されるアプローチに非常に近いです。
Paleariとその他[27]は、エミュレートされたプロセッサで実行されるか、物理プロセッサで実行されるかを検出できるコードの断片である「赤い丸薬」を自動生成する方法を提示しました。彼らのアプローチは、QEMUとBOCHSの2つのプロセッサエミュレータ用に、数百の異なる命令コードを含む新しい「赤い丸薬」を開くために使用されるプロトタイプとして実装されました。 Lindorfer et al。[24]は、ランタイムに敏感なマルウェア検出システムであるDISARMを導入しました。サンプルのマルウェアアプリケーションをさまざまな分析サンドボックスで実行し、分析回避技術を使用して悪意のあるアプリケーションを検出するために、さまざまな分析サンドボックスで観察された動作を比較しました。これらの研究はすべてテクニックを提供し、悪意のあるアプリケーションが仮想化されたx86環境を検出するために使用できます。この記事で紹介する調査では、モバイルの悪意のあるアプリケーション、特に悪意のあるAndroidアプリケーション（主にARMアーキテクチャに関連する）で使用できる同様の方法を提供しています。
7.
この記事では、Androidプラットフォームを標的とした悪意のあるアプリケーションを使用して動的分析を回避する方法を検討しました。エミュレートされた環境で分析されたときに存在を隠そうとする実際の悪意のあるアプリケーションのサンプルにそれらを含めることにより、複雑さが増すヒューリスティックが実装およびテストされました。スタンドアロンの分析ツールおよび一般に利用可能なスキャンサービスで悪意のあるアプリケーションの再パッケージ化されたすべてのサンプルがテストされ、その動作が調査されました。提示されたヒューリスティックの少なくともいくつかによって無視できない単一のサービスまたはツールは見つかりませんでした。この作業により、悪意のあるAndroidアプリケーションに対する既存の分析システムの有効性に関する重要な疑問が生じます。このため、仮想マシンの検出に対するAndroidアプリケーションの動的マルウェア分析ツールの安定性を高めるために、いくつかの可能な対策が提案されています。
参照リスト
[1] googlemobile.blogspot.com/2012/02
android-and-security.html。
[2] vrt-blog.snort.org/2013/04/changingimei-provider-model-and-phone.html。
[3] blog.sfgate.com/techchron/2013/10/10
stanford-researchers-discover-alarmingmethod-for-phone-tracking-fingerprintingthrough-sensor-flaws /。
[4] code.google.com/p/openintents/wiki
SensorSimulator。
[5] developer.android.com/reference
android / hardware / SensorManager.html。
[6] bluebox.com/corporate-blog/androidemulator-detection。
[7] code.google.com/p/smali。
[8] code.google.com/p/android-apktool。
[9] contagiominidump.blogspot.com。
[10] code.google.com/p/droidbox。
[11] www.duosecurity.com/blog/dissectingandroids-bouncer。
[12] codepainters.wordpress.com/2009/12/11
android-imei-number-and-the-emulator /。
[13]すべてのモバイル脅威の99％がAndroidデバイスを標的としています。WWW。
kaspersky.com/about/news/virus/2013/99_of_all_
mobile_threats_target_Android_devices。
[14] Anubis / Andrubis：不明なバイナリの分析。 http：//
anubis.iseclab.org/。
[15] Arm：仮想化拡張。www.arm.com
製品/プロセッサー/テクノロジー/
virtualization-extensions.php。
[16] QEMU内部。ellcc.org/ellcc/share/doc
qemu / qemu-tech.html。
[17] T.ブレージング、A.-D。 Schmidt、L。Batyuk、SA Camtepe、および
S. Albayrak。不審な
ソフトウェアの検出のためのAndroidアプリケーションサンドボックスシステム。 MALWARE、2010年。
[18] Bramley Jacob。キャッシュと自己修正コード。 http：//
community.arm.com/groups/processors/blog/2010/
02/17 / caches-and-self-modifying-code。
[19] J.カルベット、JMフェルナンデス、J.-Y。マリオン。 Aligot：
難読化されたバイナリプログラムでの暗号化関数の識別。 CCSでは、2012
[20] S.デイ、N.ロイ、W.徐、及びS. Nelakuditi。 Acm hotmobile 2013
ポスター：
スマートフォンの指紋をとるためのセンサーの欠陥の活用。 SIGMOBILE Mob。計算。コミュニケーション。 Rev.、17（3）、
11月 2013年。
[21] W.エンク、P。ギルバート、B.-G。 Chun、LP Cox、
J。Jung、P。McDaniel 、およびAN Sheth。 Taintdroid：
スマートフォンでのリアルタイムのプライバシー監視のための情報フロー追跡システム。 OSDIにおいて、2010
[22] W. Enck、D. Octeau、P.マクダニエル、およびS. Chaudhuriの。
Androidアプリケーションのセキュリティの研究。 USENIX Security、2011。
[23] L.ゴメス、I。ネアムティウ、T。アジム、およびT.ミルスタイン。 Reran：Androidのタイミングとタッチセンシティブな記録と再生。 ICSEにおいて、2013
[24] M. Lindorfer、C. Kolbitsch、及び P. MilaniのComparetti。
環境に敏感なマルウェアの検出。 RAID、2011年。
[25] L. Lu、Z。Li、Z。Wu、W。Lee、およびG. Jiang。 CHEX：
コンポーネントハイジャックの脆弱性に対する静的なAndroidアプリの検証。 CCS、
2012年。
[26] F.マテナールとP.シュルツ。 Androidサンドボックスの検出。 http：//
www.dexlabs.org/blog/btdetect。
[27] R. Paleari、L。Martignoni、GF Roglia、およびD. Bruschi。一握りの
赤丸：CPU
エミュレーターを検出する手順を自動生成する方法。 WOOT、2009年。
[28] THプロジェクト。 Androidリバースエンジニアリング（ARE）仮想
マシン。www.honeynet.org/node/783。
[29] T. Raffetseder、C。Kruegel、およびE. Kirda。システム
エミュレーターの検出。 ISC、2007年。
[30] V.ラストーギ、Y。チェン、およびX.ジャン。 Droidchameleon：
変換攻撃に対するAndroidマルウェア対策の評価。 ASIA CCSでは、
2013年。
[31] A. Reina、A。Fattori、およびL. Cavallaro。
アンドロイド
マルウェアの動作を自動的に再構築するシステムコール中心の分析および刺激技術。 EUROSEC、2013。
[32] G.サーワー、O。メハニ、R。ボレリ、D。カーファー。Androidベースのデバイス
での個人情報
漏洩から保護するための動的汚染分析の有効性について。 SECRYPTにおいて、2013
[33] M. Spreitzenbarth、F. Freiling、Echtler F.、T.シュレック、及び
J.ホフマン。モバイルサンドボックス：Android
アプリケーションの詳細を調べます。 SACは、2013年
[34] C.ウィレムス、R.フント、Fobian A.、D. Felsch、ホルツT.、および
A. Vasudevan。ベアメタルまで：
バイナリ解析にプロセッサ機能を使用します。 ACSAC '12、2012年。
[35] LKヤンとH.イン。DroidScope：
動的なAndroidマルウェア
分析のために、OSおよびDalvikセマンティックビューをシームレスに再構築します。USENIXセキュリティ、2012年