When the rain falls silver » ソフトウェア

三菱東京UFJ銀行のUIが悪化していた

silver — Tue, 15 May 2012 12:45:27 +0000

以前から銀行の入出管理はJunsoft Moneyに入れるために、Microsoft Money形式でダウンロードして利用していた。日付を指定せずに前回エクスポートの続きからできるので便利。みずほだと一部要素をテキストエディタで置き換えてあげないとうまくいかなかったが、MUFGはそのまま使えたので、重宝していた…の、だが。

何故かMoney形式でのエクスポートが廃止されていたらしい。代わりにCSVになっていたのだが、Moneyと相性が悪く色々と悪化してしまった。

まず、エクスポートの日付が前回からとできなくなったので、前回の取り込み日を調べて直接指定するしかなくなった。そして致命的なことに金額が3ケタ狂う。どうやらMoneyで区切りの,を.に誤認識(そういう国もあるから仕方ない)するので、正しい金額が入らない。仕方がないので手動で置き換え。CSVだとどの項目が何かわからないので、全部インポートの度に手動で設定する必要がある。

不便になったなあ。これは何か別の方策を考えないと続かないか…。

AndroidのPermission状況

silver — Sun, 13 May 2012 14:04:27 +0000

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種類の脅威レベルに分けられる。

Normal Permission: 壁紙の変更など、APIへのアクセスを制限するもの。
Dangerous Permission: SMS送信など、API呼び出しにより潜在的に危険をもたらすもの。
Signature/System Permission: 署名されたアプリケーションでだけ使えるもの。バックアップやアプリケーションのインストールなど、特に危険なもの。
(他、各アプリケーションが独自に定める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の分析結果が続きますが、省略。)

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

魔術師オーフェンのWikiが凄い

silver — Wed, 02 May 2012 02:31:10 +0000

Orphenpediaというのを発見したが、情報量が凄い。どうやら、私が読んだのは背約者のあたりまでなので、その後倍くらい続いているようだ。何で止めたかというと…出版間隔か、展開に飽いたのかどっちだっけ。

システムはWikipediaと同じMediawikiベース。2008年9月開始でおよそ3年半近く運営。項目数が1200強ページある割に、「議論」(ノート)の活用があまり無いことから、少人数で各個に編集していると推察される。凄いなあ。

と、思いつつ夏用にログホラのデータを収集する昨今であった。

そういえば、今でこそWikipediaのおかげでWikiとの略称があったが、当初は”Wiki-Wiki”から取ったオリジナルにそって、一部ではWikiWikiWebとよんでいた気がする。現在はOEDにも”Wiki”の名前で登録されたようだし、すっかりオリジナルからも離れたし、Wikiで良いのだろう。

非常用のボイスレコーダを探す

silver — Thu, 26 Apr 2012 01:50:45 +0000

iPhone/iPad用で小会議のレコーダを探しているのだけれど、どれが適当なのかがよくわからない。

本当はマイクつけてやるものだろうし、非常用は携帯電話にしてしまったほうが幸せなのかな。

FreeBSD 8.3-RELEASE

silver — Tue, 24 Apr 2012 14:36:47 +0000

早速手元のシステムをバージョンアップ。

# freebsd-update upgrade -r 8.3-RELEASE
# freebsd-update install
# shutdown -r now
# freebsd-update install
# freebsd-update install
# shutdown -r now

# mergemaster

jail側もいつものように対応。

# ezjail-admin update -b
# ezjail-admin restart
# ezjail-admin update -P
# PORTSDIR=/jail/basejail/usr/ports/ portsdb -u

各jailの中も適当に、チェックして、アップデートして、後始末。これが面倒だけれども、仕方がない…とやっている間に時間がなくなりそうなので、ここは後日に後まわし。

# portmaster -L
# portmaster --no-confirm -ady -x xz
# find /var/ports -type d -name work -depth 3 -exec rm -r '{}' ';'

アレがいいんです

silver — Mon, 23 Apr 2012 14:06:21 +0000

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

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

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

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

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

オブジェクト指向でイベント駆動型のソース追いは面倒だ

silver — Fri, 20 Apr 2012 10:15:48 +0000

ソースコードを読むのはそんなに苦にしていないのだけれど、最近のウェブ系はイベントで発火してオブジェクトにより多態化した処理というのが多く、動作から追うことはできても、このメソッドどこからの経路で使われているの? というのが非常に追いにくい。

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

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

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

MagicPlanが面白い

silver — Tue, 17 Apr 2012 14:58:53 +0000

何をするのかは、MagicPlanのサイトの動画を見てもらえば一目瞭然。

部屋の中央からiPad(or iPhone)をかざして、ジャイロでARしつつ、カメラに写る部屋の特徴点を指定。そうすると寸法の入った見取り図ができあがる仕組み。

試してみたが、物が多い部屋でも推測で試せば大体なんとかなる。家具を探しているときとか、引越し先を探す時の内見によさそうだ。

	MagicPlan (Version 2.0)
	カテゴリ:	ユーティリティ
	価格:	無料
	デベロッパ名:	Sensopia
	リリース日:	2011/04/09
	対応デバイス:	iPhone 4 / iPad 2 Wi-Fi+3G / iPad 2 Wi-Fi / iPod touch (4th Gen)

Androidは面倒だ

silver — Thu, 12 Apr 2012 15:13:48 +0000

最近、興味が出てAndroidのpermissionまわりに手を出しているのだけれど、どの関数がどの権限を要求しているのかがさっぱりわからない。

公式サイトからは辿れなかったのだけれども、どこかにまとまった表は無いものだろうか。

情報のクリッピングを整頓してみる

silver — Wed, 04 Apr 2012 15:07:22 +0000

Readabilityは確かに良いのだけれど、何故か会社の環境だとChromeのプラグインで2ステップになってしまって、非常に使い勝手が悪い。ifttt.comを経由してのDeliciousへの登録も、一々Favoriteをつけないと取り込んでくれない。

しかし、Reederとの連携が良いのでInstapaperには戻りたくない。

そこで、Instapaperで記録→DeliciousとReadabilityに反映、と流れを整理した。

Instapaper→Deliciousはタイトルをとりこぼすことが多いのが難点だが、まあReadability連携のほうで普段すればなんとかなる。

なお、事ここに至り、タグは完全に捨ててます。