3. 解析ツール　MobSFの使い方

本稿では、解析ツールである、MobSFの使い方を紹介します。

MobSFへ不正アプリをアップロード

まず、MobSFにログインすると、以下の画面になるので、中央の「Upload＆Analyze」をクリックの上で解析対象である不正アプリのAPKファイルを選択します。

そうすると数十秒で解析が終わり、以下のような見やすいダッシュボードに解析結果が表示されます。

項目が充実しすぎてて、私自身フル活用できていないのですが、本ブログでは右下の”DECOMPILED CODE欄”を使います。

Manifest（宣言）ファイル

Android用のアプリを構成するAPKファイルは、大きく分けて①Manifest、②ソースコード、③リソースから構成されます。
このうちManifestはマニフェスト（宣言）という名称からも分かるとおり、アプリの重要な設定情報が記載されます。
MobSFの「View Android Manifest.xml」欄は、APKファイルに含まれるManifest.xmlファイルの中身を確認することができます。

Manifestファイルにおいて、最も重要なチェック事項は「Permission」（許可）欄です。
スマホアプリでは、セキュリティ機能の中核として、アプリがユーザーのプライバシーにかかわる機能やデータ（位置情報データ、カメラ機能、SMS機能など）にアクセスするには、ユーザーの許可を必要とします。
これをPermission（許可）といいます。身近な例で言えば、LINEアプリでカメラ機能や写真一覧に利用しようとすると「以下の機能へのアクセスをLINEに許可してください」というポップアップが表示されて「許可」or「キャンセル」と選択させます。

アプリが勝手にカメラ機能や写真一覧にアクセスできるとすると、不正アプリが密かに盗撮したり写真を盗んでしまうことが可能となるので、許可画面を表示させてユーザーに注意喚起をするとともにユーザーの許可がない限りアプリに自由に活動させないようにしています。
このPermissionはスマホのセキュリティ機能の中核です。

アプリ側の仕様としては、ユーザーのプライバシーに関わる機能やデータにアクセスするには、その旨をManifest.xmlファイルにおいてマニフェスト（宣言）してPermissionを求める必要があります。なので、Manifest.xmlという名称のファイルです。

例えば、以下は通常のアプリのManifest.xmlファイルの中身ですが、"uses-permission"の箇所に注目です。ここにアクセスしたい機能やデータが宣言されています。

静的解析の観点からは、このManifest.xmlの"uses-permisson"欄を見れば、不正アプリがどの機能やデータを悪用しているかの見込みがつきます。
例えば、上記のスクショでいえば、"ACCESS_FINE_LOCATION"が一番下に記載されています。これは、不正アプリが、「FINE_LOCATION(正確な位置情報)」を盗ろうとしているという予測がつきます。以降の記事では、解析の最初に必ずこのManifestファイルを確認します。

View Source

もう一つ使うのは、”View Source”です。これはアプリを解析して、ソースコードの詳細を表示します。
アプリは、Manifestファイルに機能を宣言しただけで、その機能を実装できるわけではありません。宣言した上で、その機能を具体的にソースコードに記載する必要があります。
そして完成すると、ソースコード一式（とManifestファイル）をコンパイルしてAPKファイルに仕上げます。コンパイルとは、簡単に言えば機械が処理できる形に変換する作業です。
このコンパイル（変換）されたAPKファイルをリバースエンジニアリングして再び人間が読み書きできる形式のソースコードに戻したものが、この”View Source”欄に表示されます。

具体的には、Mob SFがAPKファイル内部にあるコンパイル（変換）後のDEX（Dalvik Executable）ファイルを読み取り、人間が読み書きしやすい「Java風」のソースコードに戻した結果が表示されます。
これにより、不正アプリ内のクラス構造やメソッド、呼び出し関係、文字列定数やリソース参照などを確認でき、開発者が実装した具体的な機能を把握・分析できるようになります。

リバースエンジニアリングの留意点

ただし重要な留意点として、リバースエンジニアリングされたソースコードは 元のソースコードを完全に再現するものではない点を押さえておく必要があります。
人間が読み書きするソースコードの中には機械が処理する上では不要な情報がたくさんあるため、コンパイル時に不要な情報がごっそり削られます。貴重な情報で言えば、変数名や関数名が削られたりします。
例えば、「8-3-3. スマホ用ランサムウェア(filelocker)」では、暗号化するための関数について、本来”encrption”的な関数名がついていたはずなのに、"b"に置き換わっています。関数名を読むことでその関数の機能を推測できるのに、"b"だと何のこっちゃでして、予測がつかないままで詳細にソースコードを見ていくしかなくなります。

また、開発者が自分のソースコードを見られたくない場合、意図的に難読化（obfuscation）処理をすることがあります。難読化されると、リバースエンジニアリングをしても、元の識別子や意図した構造は失われることがあります。

そのため、比較的解読しやすいAPKファイルであったとしても、リバースエンジニアリングの結果として出力されるのは、元のソースコードではなく、「元のソースコードを何とか人間が読み取れる形に変換したもの（＝Java風）」にとどまります。