STOWAWAYには、Android 2.2のPermissoon Mapがある^[1]。これは、どのAPIを呼び出せばどのパーミッションが必要かわかるマップだが、いかんせん情報量が多くてわかりにくい。また、基本は同じとはいえAPI levelにより多少変化もしている。

そこで、整理のために論文”Android Permissions Demystified”(PDF)を元にして、おおまかな区別を抜き出してメモとする。

まず最初に触れておきたいのは、結局統一したPermissionのポリシーなど無い、ということだ。以下に説明するようにあちこちで権限が持ちだされ、チェックされ、あるいは無視されている。中には無駄にチェックするAPIもあるらしい。よって、現状のAPI Levelでは食い違っている箇所がでることを前提とする。

最初に、Permissionは3種類の脅威レベルに分けられる。

1. Normal Permission: 壁紙の変更など、APIへのアクセスを制限するもの。
2. Dangerous Permission: SMS送信など、API呼び出しにより潜在的に危険をもたらすもの。
3. Signature/System Permission: 署名されたアプリケーションでだけ使えるもの。バックアップやアプリケーションのインストールなど、特に危険なもの。
4. (他、各アプリケーションが独自に定めるPermission)

Android API frameworkの構造は「APIライブラリ」「システムプロセス中のAPI実装」の二つのパートに分割できる。「APIライブラリ」は各アプリケーションの仮想マシンで動作するもの。当然、アプリケーションと同様の制限を受ける。それに対し「システムプロセス中のAPI実装」に制限はない。ライブラリが構文糖としてユーザからのリクエストを代理で受け、裏でシステム側で実行する、といった感じになる。

APIの呼び出しは三ステップで行われる。まず、アプリケーションはライブラリのAPIをinvokeする。次に、ライブラリはライブラリ中のprivate interfaceをinvokeする。このprivate interfaceはRPC stubになっていて、最後にRPCリクエストがシステムプロセスとして、システムサービスに誰が処理してくれるか尋ねる。この仕組みはJavaのreflectionが使われている。

例えば、ClipboardManager.getText()は、IClipboard$Stub$Proxyに引き渡され、システムのClipboardServiceが呼ばれる。

さて、肝心のPermissionのチェックだが、統一ポリシーなどは存在せず、実に色々な箇所で行われる。システムプロセス中のAPI実装でチェックするものもあれば、ライブラリ中で随時チェックするものもある。極一部の権限(INTERNET, WRITE_EXTERNAL_STORAGE, BLUETOOTHなど)は、Unix groupで制御されている。この場合、API側は何もチェックせず、ただinvokeするだけである。

Android NDKで開発できるNative Codeでは、直接にはシステムのPermissionを制御できない。、ソケットやファイルにアクセスする場合、Java wrapperを用意して行うことになる。

Content Providerは、単独のアプリケーションとしてインストールされて他のシステムプロセスやAPIライブラリからは切り離され、抱える情報の保護のために静的/動的なPermissionチェックを行う。アクセス先は、read/writeといった定義と、”content://a/b”のようなpathにより指定される^[2]。

Intentは、全てシステムサービスのActibityManagerServiceを通じて送信される。二つのテクニックによりIntentの送信は制限されている。一つは、Permissionを持っているアプリケーションにだけ送信する仕組みである。もう一つは、システムのIntentはUIDがマッチするプロセスにしか送信しない仕組みである。受信の場合もだいたいはPermissionが必要であり、OSが送信するIntentの受取先を制限している。

(論文では、この後もテストコードを暮ろうとしたらAndroid側が色々アレで大変でしたという話や、APIの分析結果が続きますが、省略。)

1. 一応、本命はapkをアップロードして余分な権限を宣言していないか解析を行えるStowawayの方、のはず。
2. 余談だが、BlackHatなどで発表されたMercuryという「うっかりContent ProviderやServiceに権限をつけ忘れて、publicになっていないか」というチェックを行うためのツールが存在し、最新のAndroguardと組み合わせて使うこともできるらしい(AREには未収録)。

軽く動作をなぞって、大体どのディレクトリに何が入っているのか、勘所をつかんでおく。

Manifest.xmlにPermissionだけで4種類ほどあるのだが、User以外の3つはどう違うのだろう。どこかに書いてあるのだろうが、調べるのが大変そうだ。

有名所のツールが色々と詰め合わせになっていて、Android のapkファイルの基本的な解析がだいたいできるようになっている。Qtライブラリを利用して色々と環境を作るのが面倒な APKInspector まで入っているのは嬉しい。

というか、APKInspectorを使おうとVMをいじっていた最中に見つけたのでちょっとだけ涙目。まあ、そういうものですよね。

詰め合わせの中身はこんな感じ。

• Androguard
• Android sdk/ndk
• APKInspector
• Apktool
• Axmlprinter
• Ded
• Dex2jar
• DroidBox
• Jad
• Smali/Baksmali

他にも、reverse-androidとか、Mercuryとか、使うと面白そうなものは多いので、まだまだ探しがいがありそうだ。

静的中心に見ている段階なので、実際に動かして動的に解析してやればいいのだろう。言語ごとにcaller/calleeを追うツールが違うので、いまいち使いにくそうなのが懸念点。グラフ書いてソースコードとの対応が取れる程度で良いのだけれど、個人利用の範疇ではあまり無さそう。

まあ、ネタが色々とアレなので通信主体であまり実地に動かしたくないわけで。パーサだけ他のから借りてきて、レイヤつけて自分で解析ツールでもつくるしかないのかねえ…って特殊すぎるしコード量がちょっと多すぎそうだ。

と、そんな趣味(?)に最近手をそめています。

高次設計なのに、やけに具体的に書きすぎてしまったり、酷いといきなりchar*などが飛び出して実装を意識しすぎたり。とにかく目的を飛ばして手順だけ書く感じ。「何故その処理なのか」が無い。

そりゃあ実装寸前まで考えてからやれる規模ですし、私もそうしてますけれども、ソフトウェア工学的にはあくまで高次なわけで…。実装フリーな抽象化した記述というのが、難しい所なのだろう。

自分で手を出せる規模ではないので、レビューに徹するしかないのが良いのか悪いのか。こんな所で趣味や大学での余分な履修が役にたっています。余技程度とはいえ、好みのままにあれやこれやに手を出しておいて本当によかった。

RubySpecとのからみはどうなっているのだろう。

簡単に言えばHTMLをとことん省略記法で書こうというもの。ただし、難点として少なくともEmacs版(非公式)は行単位なので、inlineで書くのには役に立たない。

色々なエディタに組込めるようなので、マークアップ効率化 – zen-codingでコーディングを倍速にあたりを見るとわかりやすいかも。

上司がいじっているのを見て、気になっている技術の一つ。基本的な仕組みはMap/Reduceということで理解はできるのだが、いざ実際に使おうとするとどういうパターンで使えばいいのかわからず、準備するのが面倒そうというのもあって手を出していない。

作っているとSQLならばこんな風^[1]に、Key-Value系ならこんな風^[2]に、というのはある程度見えたので、これも実例を試してみればいいのだろう。今一適当な題材が決まらないのが難点だ。

要するに即時性なし、大規模、分散可能なデータであればいいんだよな。攻撃パケットを適当に投げて、傾向分析でもすればいいのかしらん。…やっぱり使ってみないと勘所がよくわからなさそうだ。バッチで使ってもいいので、適当にブラウザゲームあたりをでっちあげて解析するのもありか。マッチメーカー系とか自分でもしてみたいし。

何にせよ、ある程度処理オーダーの壁を超えられるので、少しでも手を出しておきたい技術ではある。

…とりあえず、どれだけ資源を費せば最低限できそうなのかから調べてみるか。

1. SQLを通じてDB直や、ORマッピングを介したデータ操作。
2. Core DataなどのCocoa風味。あるいは試していないがmemcached系?

簡単に言えばパッチを組みあわせて作るビジュアルプログラミング。

2Dでも3Dでも適当に貼りつけて動かせるし、なかなかに楽しい。並列操作が得意な分、シーケンス操作が難しそうだが、これはマクロでもつくれというものなのだろう。

わけのわからないパッチが山ほどあるので、もうちょっと触ってみるつもり。

Twitterの発言から、Mecabを試してみようとfinkでインストール。

試してみると、見事に文字化け。どうやら、標準だとEUC-JPで全部処理しているらしい。仕方がないので、本体と辞書をUTF8で作りなおしてインストール。すると、今度はrubyバインディングが動かなくなってしまった。どこか妙なライブラリをひろってしまったんだろうか。

面倒そうなので、一端ここまでで中断。なんというか、暑さで気力が続かない。