プログラミング

Android APIを追い掛けていて困るのは、どのAPIでどのPermissionが必要かわかりにくいことだ。マニュアルに明記してあることもあるが、大体は「エラーが出たらManifestに」といった場当たり的な対処が推奨されてしまっている。

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には未収録)。 [↩]

Eclipse.appに日本語(pleiades)を導入しようとしたが、何かうまくいかない。原因は一部ファイルを、plugins/pluginsという中に展開してしまっていたことだったので、ファイルを移動して無事起動。eclipse.iniがパッケージの中にあるので、地味にやりなおすのが面倒だった。

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

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

アレといっても代名詞ではなく、ARE (Virtual Machine for Android Reverse Engineering) というきちんとしたツール名。

有名所のツールが色々と詰め合わせになっていて、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*などが飛び出して実装を意識しすぎたり。とにかく目的を飛ばして手順だけ書く感じ。「何故その処理なのか」が無い。

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

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

プログラム言語RubyのJIS規格（JIS X 3017）制定について

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

EmacsWiki: Zen Codingから、Carbon EmacsにZenCodingを導入してみる。

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

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

オープンソースカンファレンスのHadoop講演資料を紹介します (Yahoo! JAPAN Tech Blog)

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

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

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

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

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

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

Macで５分でARアプリを作る方法(AR without programming in 5min)を見ていたら面白そうだったので、いじって遊んでみる。

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

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

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

調子が悪かったので、宴会に行かずさっさと帰宅。

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

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

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

アイドレスの大元はプリミティブな仕様の裏で物凄く面倒なことをしているようだ。MVCのうち、Mだけが突出している正直表がRoRである必要性を感じないが(1セッションのコストを考えると特に)バックエンドや管理画面等で便利なことも多いのだろう。

とにかく、この過去との互換性を背負った複雑な書式にあいまいな記載のデータをつっこんで、きちんとした結果を出す、そのプロセスの複雑さは想像することすらできない。パーザの仕様を見てみたい。

Continue reading

GDC2010 報告会の資料 「Killzone 2」「The Sims 3」のAIから辿って、デジタルコンテンツ制作の 先端技術応用に関する調査研究報告書 2008年度をざっと読んでみる。

画像に音楽AIに職業状況等多彩な情報が盛り込まれたいたが、一番の興味を引いたところは矢張りAI。近年のAIは知覚系-体-思考を完全に分離した上で、対応する状況の粒度を変えた階層構造を持ち、メタAIやメタメタAIが連携してタスクをこなす構造がスタンダードらしい。

それで思い出したのがGPMや絢爛舞踏祭なのだが、言及が無かったのは資料の開示があるかどうかが大きいのかな。絢爛は一応攻略本にAIの概説程度は書いてあったけれども、確か欲求ベースのモデルで、The Simsで示された例に近い構造を持っていたはず。あれは観察していてなかなか愉快なAIっぷりだった。

今回のプログラム縛りについてのMeCab作者の意見を読んだ。

きまぐれ日記: MeCabがiPhone,OSXに載っていると言うのは止めようと思う

違和感が何か見えてきた気がする。iPhoneは家電であって家電でないということかな。これがプログラムの外挿自体が特別な機器であるテレビや冷蔵庫やビデオレコーダ等…例えばApple TV上のガジェットならそう言われなかったのだろう。

携帯電話だとしても言語縛りは別に今まで問題とはなってこなかった。BREWでしか作れないと言われてもそんなものか、ですんでしまう。いわゆる従来からのスマートフォンの系譜にあるバイナリさえあれば言語は何でもいいというのと、今まで解放していたのが制限された、というのが反発しやすい条件になっているのだろう。自由の制限、というのはわかりやすいし。

私自身としては、libc相当から自前で書きおこしているdjb ware的なものを皆が使うと何か不安だよね、という程度の違和感なので、ミドルウェアは何だっていいじゃない、とは思う。一方で、市場が縮小する判断をしてまで安定性を重視したアップルの姿勢もわからなくはない。多分短期的には悪い方向に行くんだろうなあと思いつつ様子見といったところ。

通勤中にヒレガス本を読んで、帰ってから課題の一つである文字列の入力とその文字数を数えるメッセージを出すというのをやってみた。場所でいうと「5.6 チャレンジ」(日本語版の場合p96、英語はp90)。

まずは素直に IBOutlet/IBAction を使うバージョン。NSTextField の outlet を二つ用意して、ボタンの押下を IBAction のメソッドで受ける。ついでに awakeFromNIB メソッドを定義してラベルの初期値を設定してみた。これは課題のページのすぐ前あたりでやっていることなので簡単。

さらに作りなおしてみる。Key-Value コーディングが面白そうだったので、がらっと違う方法で挑戦。

NSString を二つ(テキスト入力用、テキスト出力用)用意して、@property と @synthesize で setter/getter を自動定義。文字列の入力即文字数カウントとしたかったので、IBで入力テキストフィールドのContinuesを有効にして、setter だけ自前で書く。このへんでどハマり。

まず、NSString の更新ってどうなるんだっけ、と延々マニュアルをあさってみたりする。結局 textField = t; と単純なポインタ代入でよかったようだ。本当はその前にt を retainしたりtextField を release したり必要なはずだが、しばらくはメモリ管理は忘れたままでおきたいので、ガーベージコレクションをビルドオプションでつけて逃げる。

そして、あんのじょう値を直接更新したのに更新通知を飛ばしてしまい、willChangeValueKey と didChangeValueKeyに辿りつくまで長々と悩んでしまう。出力側のテキストの更新も少々悩んだが、こちらは self 経由で [self setLengthMessage:msg]; と @synthesize がつくってくれた setter を指定することで逃げた。

なんだかんだで2,3時間かけて課題完了。少しは勘所がわかってきた気がする。

NIBがないとわからないが、一応二番目の課題でつくったクラス AppController.h。

#import 

@interface AppController : NSObject {
	NSString *textField;
	NSString *lengthMessage;
}
- (id)setTextField:(NSString *)t;
- (int)countLength:(NSString *)t;
@property (readwrite, copy) NSString *lengthMessage;
@property (readonly) NSString *textField;
@end

ついでに AppController.m。

#import "AppController.h"

@implementation AppController
- (id)setTextField:(NSString *)t
{
	// set new textField
	[self willChangeValueForKey:@"textField"];
	textField = t;
	[self didChangeValueForKey:@"textField"];

	NSLog(@"%@ -> %@", textField, t);

	// update length message
	[self countLength: t];

	return self;
}

- (int)countLength:(NSString *)t
{
	NSString *msg;
	int length;

	// make message from textfield's length
	length = textField.length;
	msg = [[NSString alloc] initWithFormat:@"'%@' has %d characters.",
		   textField,
		   length];

	// set value using self-setter(automated)
	[self setLengthMessage:msg];
	NSLog(@"%@", msg);

	return length;
}

@synthesize textField;
@synthesize lengthMessage;
@end

ちょうどヒレガス本の日本語版が発売されていたようなので、何件かまわって購入してみた。原書で持っているだけに日本語で読めるというだけではちょっと買いにくいが、XCode 3.2/Snow Leopard 対応がされているというので「これはヒレガス本++とでも言うべき内容だ」と自分を納得させて購入。ああ、矢張り日本語で読むと楽だねえ(←そこが主眼だっだのか)

• [BOOK]Mac OS X Cocoa プログラミング 第3版(アーロン・ヒレガス)
• [COMIC]もやしもん―TALES OF AGRICULTURE (4) (石川雅之)