仙石浩明の日記

最初の Android 4.0 端末である Galaxy Nexus は、 今までの Android 端末と異なり USB Storage として使うことができない。 PC とデータをやりとりしたいときは MTP (Media Transfer Protocol) を使えということらしい。 従来の Android 端末は、 PC と USB ケーブルで接続することによって、 Android 端末のストレージ (microSD カードなど) を USB Storage として PC からアクセスすることができた。

ただし、 PC と Android 双方から同じストレージを同時に読み書きすると破綻するので、 PC からアクセスするときは、 Android 端末からそのストレージを一時的に切り離す (umount する) 実装になっている。 このため、 ストレージに Android が必要とするデータがあると、 切り離したときに問題が起きる。 例えば着信音 (着メロ) を microSD カード上に置いていると、 切り離しているときに電話がかかってきても、 その着信音を鳴せない (Nexus S などだと、 設定した着信音がアクセスできない場合は、 デフォルトの着信音に切り替わる)。

MTP はブロックデバイス単位でなくファイル単位でストレージを管理する。 したがって PC との接続時でも Android 端末からストレージ全体がアクセスできなくなるという問題がない。 しかも MTP は Windows Vista 以降なら標準でサポートしている。 と、 このように (Samsung と Google は) 考えて、 Galaxy Nexus では USB Storage の代わりに MTP を使うようにしたのだろう (Samsung の一つ前の世代の Android 端末である Galaxy S でも MTP が使える)。 なお、 今後登場する Android 4.0 (Ice Cream Sandwich, ICS) 端末で USB Storage 機能が廃止されるかどうかは不明。 少なくとも Nexus S を ICS にシステムアップデートしても、 従来通り USB Storage を使うことができた。

一見妥当のように見える MTP の採用だが、 実際に使ってみると問題が多い。 ストレートに言えば 「全く使い物にならない」。 Windows XP だと Windows Media Player 10 以降のバージョンをインストールしないと MTP が使えないし、 Windows 以外だと、 標準で MTP をサポートしている OS はほとんどない。 しかも Windows でも、 MTP うんぬん以前に Samsung 端末用の USB ドライバを入手するのが大変。 以前は SAMSUNG_USB_Driver_for_Mobile_Phones.exe が単体で配布されていたようだが、 今は Kies をインストールしないと入手できない (-_-ﾒ)。

さんざん苦労して MTP が使えるようにしても、 データ転送速度が極めて遅い (まだ実装がこなれてないため?)。 さらに、 普通のブロックデバイス (あるいはファイルシステム) として OS から見えないため、 MTP 対応を謳っていない限り、 普通のバックアップアップツールでは扱えないことが多い。 数MB 程度のファイルを一つ二つコピーする程度であればさほど問題無いが、 バックアップなど大量のデータを転送したい場合は不向き。

私の場合、 Galaxy Nexus のストレージ (/mnt/sdcard パーティション, 実際には /data/media を FUSE で /mnt/sdcard に mount している) を毎日 PC (Linux マシン) へバックアップしたい。 全部で数GB の大きさがあるので、 全データを毎回コピーするのは非現実的。 そこで rsync backup for Android アプリを使ってみた。 このアプリは、 内部に rsync と ssh コマンドを持っていて、 rsync を以下のような形で実行している:

/data/data/eu.kowalczuk.rsync4android/files/rsync -vHrltD \
    --chmod=Du+rwx,go-rwx,Fu+rw,go-rw --no-perms --delete-after \
    -e '/data/data/eu.kowalczuk.rsync4android/files/ssh -y -p 22 \
            -i /data/data/eu.kowalczuk.rsync4android/files/dss_key' \
    /mnt/sdcard/ sengoku@senri.gcd.org:~/android/sdcard/

Galaxy Nexus には有線LAN が無いので WiFi 経由で通信することになるが、 PC 同士で rsync する場合と全く同じで、とても簡単。 Android も Linux なのだから、 MTP みたいな得体の知れないものを無理に使うより、 使い慣れた rsync の方が断然 (・∀・)ｲｲ!!

とはいえ、 使ってると WiFi の通信の遅さが気になってきた。 「USBテザリング」 を使えば USB ケーブル経由で TCP/IP 通信を行なうこともできるが、 rsync でデータ転送を行なうためだけにテザリングするのは牛刀な感じが否めない。 また、 テザリングの場合 Android の default route が 3G 回線へ向いてしまうので、 特定のアドレス (プライベート IP アドレス) を USB へ向ける route 設定が必要。

そもそも Android 端末と PC とは adb (Android Debug Bridge) でデータをやりとりしているのだから、 rsync も adb 上で行ないたいと思うのが人情というもの。

前フリが長くなったが、ここからが本題。

Android 上のアプリの多くは 「共有」 機能を用いて他のアプリへデータを送ることができる。 例えば画像ビューアだと、 「メニュー」 から 「共有」 を選び、 「Picasa」 を選ぶことで Android 標準の com.google.android.apps.uploader (マイアップロード) アプリを使って、 Picasa ウェブアルバムへ画像をアップロードできる (← 左図)。

ところが、 この Picasa には Google アカウントとの連係に問題があって、 Android 端末の状態によっては Picasa へのアップロードができなくなってしまう。 つまり、 「Picasa」 を選んだときに、 「Googleアカウントを追加」 する画面に遷移してしまい先に進めない (↓ 下図)。

既にこの携帯に登録済の Googleアカウントで、 画像をアップロードしたいのに、 「マイアップロード」 が現在の登録済アカウントを認識できず、 アカウントの追加を求めてくる。

[戻る] ボタンを押すと 「マイアップロード」 が終了してしまうので、 仕方なく [次へ] をタップして Googleアカウントを追加しようとすると、 「アカウントが既に存在します」 と言われてしまう (↓ 下図)。

「アカウントが存在する」 のが分かってるなら、 そのアカウントで画像をアップロードしろよ！ と言いたくなるが、 画面には [戻る] しかないのでどうにもならない。

Google ヘルプを見ると、 http://picasaweb.google.com に一度もアクセスしない状態でアップロードを試みると、 このような二進も三進も行かない状態に陥る、 ということらしい。 そこまで分かってるなら対策しろよ、 と言いたくなる。 まあ、 Google 的には、 Picasa へ直接アップロードするのではなく、 Google+ 経由で使って欲しいということなのかもしれないが。

もちろん、 現在の Googleアカウントをいったん削除すれば、 アカウントを追加することは可能になる (はず)。 しかし、 アカウントを削除しようとすると、 「携帯のメール、連絡先などのすべてのデータも削除されます」 などと脅される (右図 →)。

アカウントを削除しても、 再度アカウントを追加すれば、 削除されたメールや連絡先も再同期されるのだとは思うが、 「１つ目のアカウントを絶対削除したらだめ」 という先達の意見をスルーするのも気が引ける。

また、 知らぬ間にPicasaとの同期が始まるケースもあるらしいが、 ただ待ってるというのも能がないし、 待っていれば必ず始まるというものでもないだろう。

そこで、 アカウントを削除すること無く、 他への影響を最小限に抑えつつ、 Picasa Web Albums を同期させる方法を考えてみた。

Galaxy S を Kies 経由 (SAMSUNG 公式の方法) で 2.2.1 (ビルド番号 FROYO.ZSJPK) へアップデートしたら、 ほとんど全てのアプリが起動直後に異常終了するという事態に陥ってしまった。

← のような 「Sorry!」 ダイアログが、 ブート中に次々と表示される。 これは jp.softbank.mb.mail つまり SoftBankメールが異常終了したことを知らせるダイアログだが、 これ以外にも Battery Graph, K-9 Mail, Dropbox, Calendar Pad, ROM Manager などなど、 ブート時に自動起動されるウィジェットやサービスなどが、 次々と異常終了して同様の 「Sorry!」 ダイアログで画面が埋め尽された。 「Force close」 ボタンを押してダイアログを閉じても、 後から後からダイアログが繰り返し現れる深刻な事態。

一体何が起ったのかと呆然としながら 「Force close」 を押し続けていると、 言語 (英語/中国語) を選択する画面が表示された。 これはセットアップウィザード (PhoneSetupWizard.apk) で、 普通は初回のみ起動されるアプリ。

なぜホーム画面が表示されないのかと思いつつ、 ウィザードにしたがって時刻などを設定していくと、 異常終了してウィザードが再起動してしまった。 つまり言語設定からやり直し。 これが繰り返される無限ループに陥り、 ホーム画面に移行できなくなってしまった。

いったい何が起ったのか?

検索したら Kies を使って 2.2.1 BOJS5 へアップデートしたら PhoneSetupWizard.apk の無限ループに陥った、 という同様の症例が見つかったが、 もし SAMSUNG 公式の方法で 2.2.1 へアップデートしたとき、 常にこのような問題が起きるのだとしたら、 もっと大騒ぎになるはず。 だから、 単にアップデートしただけで発症するのではなく、 なにか別に発症の条件があるのではないか?

RyanZA's OCLF 2.0 を使っていて、 きちんと OCLF (One Click Lag Fix) を無効化してから 2.2.1 へアップデートしたのに、 アプリが動かなくなったという症例も見つかった。 Galaxy S はアプリのデータ用のフラッシュメモリ (/data ディレクトリ) の書込み速度が遅く、 しばしばフリーズする (いわゆる 「プチフリ」) 問題があり、 多くの人が OCLF 等のツール (ext2 なイメージファイルを /data パーティションに作って loop device 経由で /data にマウントしてくれるツール。 ファイルシステムが rfs から ext2 になることによりプチフリが軽減される) を使っていると思われるし、 もちろん私も使っている。

私の場合、 まず OCLF を無効化 (ext2 上のデータを /data 以下へ書き戻して loop device をアンマウント) し、 Kies を使って 2.2.1 へアップデートを行なった。 次に OCLF を有効化し、 しばらくフツーに Galaxy S を使ってみて問題無いことを確認した後、 バックアップを取っておこうと ClockworkMod recovery へ再起動してバックアップを行なった (うっかり OCLF を有効化したままバックアップしてしまったので、 data.img が 1.6GB になってしまった ^^;)。

ここまでは全く正常。

フツーの Android だと recovery mode では (通常起動時とは別の) recovery mode 専用のブートイメージ (recovery image) が使用されるので、 この recovery image を書き換えてバックアップ機能を持たせたり、 カスタムROM を書込む機能を持たせたりできる。 ClockworkMod recovery や Amon RA recovery が有名。
ところが Galaxy S の場合は、 recovery mode でも通常起動と同じブートイメージが使用され、 /system/bin/recovery が実行される。 しかもこの recovery が、 バージョン <3e> 以降から (正規の) 署名付 update.zip でないと書込めず (つまりカスタムROM 等を書込めない) しかも書込んだときは強制的に初期化するようになった。
そこで 改変版 3e Recovery が作られた。 この改変版で /system/bin/recovery を置き換えると、 初期化せずに任意の update.zip を読み込むことができて、 かつ ROM Manager に含まれる recovery-update.zip を読み込むと、 Galaxy S でも ClockworkMod recovery が利用できる。

で、 バックアップが正常に終了したあと起動したら前述したような異常事態に陥った、 という顛末。
同様の異常事態に陥ったかたは、 何をしたらそうなったか教えて頂けると幸い。

この手のトラブルが起きたとき、 Web 上でよく見かける対処方法といえば 「初期化」 (wipe data / factory reset)。 そりゃ初期化すれば直ることが多い (より事態が悪化して再起不能になるケースも無いわけではないので、 手放しで推奨するわけにはいかない) が、 トラブルの原因が闇に葬られるので、 私としてはきちんと原因究明した上で (可能なら設定等も温存したまま) 直したい。

遅ればせながら Nexus S を入手した。

もちろん、 真っ先に行なったのは root 権限の取得。 「正規に」 root 権限を取得できるのが、 Nexus S の唯一(?)の存在理由なのだから、 root を取らずにいじるというのは邪道だろう。 root を取らないのであれば Galaxy S などで充分。

Android 端末の root 権限を取得するには大別して次の二つの方法がある:

1. ブートローダをアンロックしてリカバリを書換 (fastboot oem unlock)
2. セキュリティホールを利用して root 権限を奪取 (RageAgainstTheCage)

1. の方法は Google 正規の方法。 開発目的で Android 端末をいじるときは root 権限を取得したほうが何かと便利なので、 Nexus One や Nexus S など開発者用の Android 端末は、 「仕様」 として root 権限を取得できるようになっている。

開発用でない端末の root を取れてしまうとセキュリティ上の脅威となる (他人の端末で勝手に root を取ってプライベートデータを盗み読むなど) ので、 端末上の全データを消去した上でないとアンロックできない。 なので、 root を取る前にアプリをインストールしたり、 設定を変更したりすると、 アンロックしたとき全て消えてしまって二度手間になる。 だから Nexus S を入手したら、 何よりも真っ先にアンロックすべき (← くどい)。

2. の方法は、 (root 権限で起動される) adbd が、 setuid(2) を使って root 権限を手放す (adbd は shell ユーザ権限で動く) ときに、 エラー (setuid の返値) チェックを行なっていない、 というバグ (セキュリティホール) を利用する。 具体的には RageAgainstTheCage exploit を利用して (再起動した) adbd が setuid を呼び出すときにリソース不足 (errno = EAGAIN) で失敗させ、 adbd が root 権限を手放さずにそのまま走るようにすることにより、 root 権限が利用できるようになる。

一般の (開発者用でない) 端末をいじり倒したい場合には便利な方法だが、 当然ながら悪用もできるわけで、 ユーザが意図しないところでアプリが勝手に root 権限を奪取してしまうと、 極めてやっかいなことになる。 実際そういうマルウェアも出回っているらしい。

Android Gingerbread 2.3.3 以降でこのバグが修正され、 RageAgainstTheCage では root 権限を奪取できないようになったのは当然と言える。 むしろ遅きに失したくらい。 これだけ有名かつ重大なセキュリティホールを今まで放置した Google は万死に値する。

というわけで、 Nexus S の箱を開封して真っ先にアンロックしようと FASTBOOT MODE にした (音量大ボタンを押しながら電源を入れる) のだが、 アンロックコマンド (fastboot oem unlock) が使えるなら、 もしかすると、 その他の fastboot コマンドも使えるのではないか? という思いがよぎり...

senri:~ $ fastboot boot recovery-clockwork-3.0.0.5-crespo.img
downloading 'boot.img'... OKAY
booting... OKAY

ありゃ (^^;)、 clockwork リカバリで起動してしまった。 リカバリイメージをフラッシュしていない点に注目。 フツーは、 アンロックした上でリカバリイメージを書込み、 リカバリモードで起動して root 化するのだが、 そうした手順をすっ飛ばして起動できてしまった。

ちなみに、 リカバリイメージを書込むにはアンロックが必要であるようだ:

senri:~ $ fastboot flash recovery recovery-clockwork-3.0.0.5-crespo.img 
sending 'recovery' (3980 KB)... OKAY
writing 'recovery'... FAILED (remote: Bootloader Locked - Use "fastboot oem unlock" to Unlock)
senri:~ $ 

フラッシュに書込みできなくても、 任意のカーネルを起動できたら何でもできるわけで、 ロックする意味がなくなってしまう。 実際、 root 権限があれば flash_image コマンドでリカバリイメージを書き込むことができた。 アンロック不要で 「fastboot boot」 コマンドが実行できてしまうのは、 バグなのではないか?

バグか仕様かはサテオキ、 現状の Nexus S は、 アンロックせず、 フラッシュへの書込みもせずに clockwork リカバリが起動できたので、 初期状態のフルバックアップが可能。 しかも、 clockwork リカバリは、 adbd が root 権限で動いている (これはバグではなく仕様) ので、 adb でアクセスすれば root になれる。

senri:~ $ adb shell
~ # 

う〜ん、簡単すぎ。 こんなことでいいのだろうかと思いつつ、 アンロックする手間が省けたので、 clockwork リカバリのメニューから 「mount /system」 を実行し、 su コマンドをインストール:

senri:~ $ adb push su-2.3.6.1-ef/system/bin/su /system/bin/
596 KB/s (26264 bytes in 0.042s)
senri:~ $ adb install su-2.3.6.1-ef/system/app/Superuser.apk
1825 KB/s (196521 bytes in 0.105s)
	pkg: /data/local/tmp/Superuser.apk
Success
senri:~ $ adb shell
~ # chmod 4711 /system/bin/su
~ # 

というわけで、 Nexus S を素のまま root 化できてしまった。 ブートイメージやリカバリイメージを変更する必要がないので、 文鎮化リスクが全く無い安全な root 化方法と言えるが、 逆に言うと端末に痕跡を全く残さずに root 権限を奪取できてしまうわけで、 いいんだか悪いんだか...

華為 (华为, Huawei) の IDEOS U8150 は、 各国キャリア向けのファームウェアが公開されている。 華為終端 (华为终端, Huawei Device) の中文 (中国語) ページで 「U8150」 を検索すると、 香港數碼通 (数码通, SmarTone Vodafone) 向けファームウェアが、 Worldwide ページで 「U8150」 を検索すると、 Italy Vodafone 向けファームウェアが、 それぞれダウンロードできる。 また、 華為終端サイトの検索では見つけられなかったが、 米国 T-Mobile (Postpay) 向け (T-Mobile Comet) も華為終端サイトからダウンロードできる。 その他、 台湾などアジア各国向けやオーストラリア向けもダウンロードできるようだ。

IDEOS U8150 の既知のファームウェアについてまとめてみる:

ビルド番号は、 どのファームウェアも 「U8150V100R001」 で始まっているので、 その後に続く 「C〜B〜SP〜」 の数値のみ記した。 「USA T-Mobile」 は、 ファームウェアのファイル名では C85 なのだが、 実際に使ってみると U8150V100R001C126B823SP01 と表示されるので、 C126 と記した。 日本通信が販売している IDEOS も C126 だが、 T-Mobile Comet と何らかの共通点があるのだろうか?

「B〜」 の数値を昇順に並べてみると、 ファームウェアをビルドした日時 (ro.build.date) も昇順に並ぶことが分かる。 このことから、 「B〜」 はビルドした順に付けた番号と推測される。

「AMSS」 のバージョンは、 「*#*#2846579#*#*」 をダイヤルすると表示される 「テスト中」 メニューの 「ProjectMenu」 を選び、 その中の 「4.Veneer information query」 を選び、 その中の 「1.S/H version query」 を選ぶと表示される。 「テスト中」 とか 「Veneer」 (化粧張り) とか、 メニューの項目名がいかにもアレだが、 こうした詳細情報を表示する機能をつぶさずに出荷している点は好感が持てる。 日本のメーカとかだと、 こういう機能は全力でつぶしてくる。 力をかける場所を間違ってるんじゃ? と思いたくなるくらい。 わたし的には、 「*#*#4636#*#*」 や 「*#*#8255#*#*」 などの機能をつぶしている Android 端末は 「買ってはいけない」。

AMSS (Advanced Mobile Subscriber Software) というのは、 ベースバンドチップ上で動く基本ソフトウェア。

BREW は, 米QUALCOMM 社が 2001年 1月31日に発表した携帯電話向けダウンローダブルアプリケーションプラットフォームであり, ARM のアーキテクチャに基づいて作られた CPU をコアに持つ, 同社のベースバンドチップ MSM (Mobile Station Modem) シリーズに組み込まれた基本ソフトウェア AMSS (Advanced Mobile Station Software) 上で動作する.

「国内向けCDMA2000 1xEV-DO 方式携帯電話W31T」 から引用

AMSS のバージョンは、 どのファームウェアも 「M7x25V100R001C00」 で始まっているので、 その後に続く 「B〜」 のみ記した。 例えば Italy Vodafone 向けファームウェアの AMSS のバージョンは M7x25V100R001C00B254 なので 「B254」 と記した。

香港で IDEOS U8150-B を購入したら香港數碼通向けファームウェア B818 (上表 B 欄の数値、以下同様) だったが、 このファームウェアだと日本の一部(?)のキャリアの SIM でデータ通信できないという問題がある (音声通話は可能)。 例えば、 ソフトバンクの銀SIM/黒SIM や、 WILLCOM CORE 3G の SIM では接続できなかった。

Italy Vodafone 向けファームウェア B827 を書込むと、 ソフトバンク SIM などでも 3G データ通信できるようになるが、 香港數碼通向け B818 と Italy Vodafone 向け B827 では何が違うのだろうと思ったので、 少し調べてみた。 ちなみに B818 だけでなく B822, B823 にも同様の問題がある。 つまり B823 までと B827 以降では何かが変わったようだ。

先週末 IS01 で root 権限が必要なアプリが使えるようになったばかりなのに、 そのわずか 4日後、 スマートフォン＠2ch掲示板に以下の書き込みがあり、 カーネル空間への侵入口が明らかにされてしまった。 一番乗りを果たした goroh_kun さんに敬意を表しつつも、 IS01 のプロテクトがこの程度だったことが残念でもある。 「root を取られても大丈夫な作りになっている」 と開発者が豪語し、 しかも IS01 の発売から 5ヶ月間も破られなかったのだから、 さぞかし鉄壁の守りなのだろうと思っていたのに、 こんな分かりやすい穴があったとわ... (負け惜しみ ^^;)。

【ROM焼き】au IS01 root2　〜わたくし達も未来へ〜

...

317 ：goroh_kun：2010/12/01(水) 03:14:21 ID:LGLTLBmZ

自動起動仕込むところを大体見つけました。
どなたか協力お願いします。

/data/の直下にlocal.propを置く
ここで、内容をoverrideできます。
サービス起動時のおダイナミックライブラリがある
サービスプログラムを探す。

getpropしてみると、

rild.libpathが/system/lib/libril-qc-1.soといかにも起動時に使っていそう。
rildaemonから使われているプラグインと思われます。

そこで、
local.propの中身を
rild.libpath=/data/lib/libril-wrapper.so
rild.wrapper.cmd=/data/rootkit.boot.sh
rild.libpath2=/system/lib/libril-qc-1.so

で、このプラグインを/data配下から読み出されるようにして、
libril-wrapper.soにて、ダイナミックロード時に
自動実行したいプログラムを指定できるようにします。
で、自動実行したいプログラムをlibril-wrapper.soで実行後
本来のrild用のプラグインをロードして、rildに引き渡すようにします。

これでいけるのではないかと思っているのですが、やるよって方は
いらっしゃいますか？

rild.libpath プロパティは、 RIL (Radio Interface Layer) デーモン rild が参照している。 rild は rild.libpath の値をダイナミックライブラリのパス名として dlopen(3) に渡し、 dlsym(3) でライブラリ内の関数 RIL_Init 呼び出す。 つまり、 rild が起動される前に rild.libpath の値を書き換えておけば、 rild に任意のプログラムを起動時に実行させることが可能になる。

したがって守る側 (つまり開発者の立場) から考えると、 (1) rild.libpath が書き換えられないようにするか (2) 任意のプログラムの実行が脅威にならないよう、 rild 起動前に防御を固めてしまえばよい。

プロパティは、 以下の 4 つのファイルで設定できる。 どれか一つでも改変可能であれば、 (1) の方法は使えない。

• /default.prop
• /system/build.prop
• /system/default.prop
• /data/local.prop

IS01 の場合、 (たとえ root が奪取されても) /system ディレクトリ下は改変できないようになっている。 また、 /default.prop は initramfs 内のファイルなので、 改変しても再起動すれば揮発してしまう。 だから上記 4ファイルのうち /data/local.prop 以外は改変不可能。

Android では /system ディレクトリ下は read only でも構わないが、 /data ディレクトリ下は Android 動作中に書き換えることが前提となっている。 もちろん /data/local.prop だけは書き換え不可能にするとか、 あるいは再起動時に自動的に /data/local.prop を書き戻す、 という方法も考えられなくもないが、 そもそも論で言えば /data/local.prop は、 システムのプロパティをオーバーライドするための設定ファイルであって、 その本来の趣旨からいえば書き換え不可能にすることは望ましくない。

したがって守るなら (2) の方法が自然。 というか、 /data/local.prop で rild.libpath の値を変更されても、 rild はユーザ空間で動くデーモンなのだから、 本来は 「任意のプログラムの実行」 が可能でも脅威にはならないはず。

ところが IS01 の開発チームは致命的なミスを犯した。

Android 搭載スマートブック IS01 by SHARP (愛称 「メガネケース」) が、 本体価格 0円 + 契約事務手数料 2835円 + 月々 8円 * 2年しばり = 3027円 で入手できるとネット上で話題になっていたので買ってみた。 メジャーアップデート対応なしと公式に宣告されてしまった IS01 ではあるが、 「ワンセグ放送が視聴できて WiFi 通信もできるポメラもどき」 と割りきったとしても激安なので 「ふたつでじゅうぶんですよ」 と言われつつ 3つ入手した。

「グローバル展開もしていないから xda の助けも得られない」 と総統閣下に嘆かれつつも、 RageAgainstTheCage exploit を利用すれば root になることは一応できる (ベースバンドバージョン / ビルド番号 01.00.07 で確認):

senri:/home/sengoku % adb push rageagainstthecage /data/local/tmp/
senri:/home/sengoku % adb shell
$ cd /data/local/tmp
$ chmod 755 rageagainstthecage
$ ./rageagainstthecage
[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C

[*] checking NPROC limit ...
[+] RLIMIT_NPROC={1856, 1856}
[*] Searching for adb ...
[+] Found adb as PID 8223
[*] Spawning children. Dont type anything and wait for reset!
[*]
[*] If you like what we are doing you can send us PayPal money to
[*] 7-4-3-C@web.de so we can compensate time, effort and HW costs.
[*] If you are a company and feel like you profit from our work,
[*] we also accept donations > 1000 USD!
[*]
[*] adb connection will be reset. restart adb server on desktop and re-login.
$ 
senri:/home/sengoku % adb shell
# 

ただし rageagainstthecage はタイミングが良くないと失敗するので、 少なくとも数回は繰り返し実行しないと root が取れない (運が悪いと何度実行しても成功しない上に adb で接続できなくなって再起動する羽目に陥ることも)。 IS01 を再起動するたびに rageagainstthecage を実行して root を取り直すのは著しく手間なので、 root が取れたら su コマンドをインストールしておくべき。

インストール先は、 一般ユーザ (shell 権限) でアクセス可能で、 かつ再起動しても消えない (つまり tmpfs とかでない) ボリュームで、 かつ mount 時に nosuid オプションをつけられていないことが必須条件になるが、 幸い IS01 ではフラッシュメモリ /dev/block/mtdblock7 が /sqlite_journals に nosuid 無しで mount されている:

senri:/home/sengoku % adb shell
$ grep -v '\(tmpfs\|nosuid\)' /proc/mounts
rootfs / rootfs ro 0 0
devpts /dev/pts devpts rw,mode=600 0 0
proc /proc proc rw 0 0
sysfs /sys sysfs rw 0 0
/dev/block/mtdblock7 /sqlite_journals yaffs2 rw 0 0
/dev/block/mtdblock5 /system yaffs2 ro 0 0
$ ls -l /sqlite_journals
drwxrwx--x system   system            1980-01-06 09:00 com.android.providers.settings
drwxrwx--x system   system            1980-01-06 09:00 com.android.providers.settingsex
drw-rw-rw- root     root              2010-11-26 18:51 lost+found

sqlite_journals というディレクトリ名からして SQLite 用のディレクトリと思われるが、 それならなぜ nosuid がつけられていないのだろうか？ ガチガチに防御を固めているはずの IS01 にしては珍しい抜け穴の一つ。

ちなみに上記のように /dev/block/mtdblock5 も /system ディレクトリに nosuid オプション無しでマウントされているが、 こちらはカーネルの MTD ドライバで書き込みが禁止されている (SHARP が公開している IS01 のカーネル kernel/drivers/mtd/devices/msm_nand.c 参照) ので、 簡単には変更できそうにない (少なくとも rw で remount するだけでは書込めない)。

というわけで /sqlite_journals に bin ディレクトリを作って ChainsDD の su コマンド (android_system_extras に含まれる) を置いてみる。

# ls -l /sqlite_journals/bin/su
-rwsr-sr-x    1 root     root         26256 Aug 17 17:27 /sqlite_journals/bin/su

ところが！

iモードメールを Android 端末で送受信するには、 sp モード か iモード.net を利用する。 前者は sp モード専用の APN (Access Point Name) spmode.ne.jp に接続しないと利用できない (つまり無線LAN 経由では使えない) 上に、 ドコモが IMEI (International Mobile Equipment Identity, 端末識別番号) をチェックしていて、 契約端末でないとこの APN に接続できない (らしい)。 なので私は後者を利用している。

iモード.net は、 PC から iモードメールを読み書きできる Webメールサービス (月額210円)。 PC の代りに Android 端末上のアプリ (iMoNi が有名) からアクセスすれば、 Android 端末で iモードメールを読み書きできる。 あるいは iモード.net からメールを読み取って別のメールアドレス (例えば Gmail) へ転送するプログラムを (どこかのサーバで) 動かしておけば、 iモードメールを Android 端末で普通のメールとして受信できる。

前者の方法は、 メールの新着をどうやって知るか、 という問題がある。 Android 端末上のアプリが定期的に iモード.net にアクセスして新着をチェックすることになるが、 電池の消耗を考えればせいぜい 15分に一度チェックするのが限界で、 それ以上の頻度でチェックするのは現実的ではない。 つまり最大 15分間は新着を知るのが遅れる。 iMoNi にはドコモから送られてくる WAP PUSH を検知してメールをチェックしにいく機能もあるが、 3G 接続中は (なぜか) WAP PUSH を受け取れないらしい。

それに対し後者の方法は、 転送プログラムは Android 端末上で動くわけではないので、 電池のことを心配せずに iモード.net を頻繁にチェックできる。 iモード.net で取得したメールを Gmail へ転送するようにすれば、 Android 端末は Gmail の着信をリアルタイムで知ることができる。

前者の方法は Android 端末だけで iモードメールを読み書きできるのに対し、 後者の方法は転送プログラムを動かすサーバ (24時間稼働が望ましい) が必要になるので万人向けではないが、 そういったサーバを確保できるのなら、 iモードメールを普通のメールと同様に扱える後者の方法が圧倒的に便利。

というわけで、 私は imoten (imode.netのメールをSMTPで転送するプログラム) を使っている (まだ使い始めて 2日だが)。 1分も遅れずに Android 端末で着信を知ることができるので、 とても便利。

imoten には iモードメールを送信する機能もある。 すなわち imoten が SMTP サーバとして振る舞い、 受け取ったメールを iモード.net へ転送する。

ということはつまり Android 端末から iモードメールを送ることができるのはもちろん、 PC 上のメーラや任意のメール配信プログラムから iモードメールが送ることが可能。 試しにテストプログラムを書いてみた:

#!/usr/bin/perl
use strict;
use warnings;
use Net::SMTP;

my $smtp = Net::SMTP->new('senri.gcd.org', Port => 42525, Debug => 1);
$smtp->auth('imoten', 'xxxxxxxx');
$smtp->mail('sengoku');
$smtp->to('sengoku@gcd.org');
$smtp->data();
$smtp->datasend("To: sengoku\@gcd.org\n");
$smtp->datasend("\n");
$smtp->datasend("A test message\n");
$smtp->dataend();

imoten を動かしているサーバ senri.gcd.org の 42525 番ポートに SMTP 接続してメールを送信するプログラム。 imoten は SMTP PLAIN 認証をサポートしているので、
「$smtp->auth('imoten', 'xxxxxxxx');」 で、
ユーザ 「imoten」、 パスワード 「xxxxxxxx」 (伏字) を指定している。

ところが！

新しい Android 端末が次から次へと発表される今日このごろ、 1月6日に発表された Nexus One は (まだ一年たっていないのに) 旧型機といった感じになりつつある。 特に端末内部メモリ容量が 200MB しかないのは致命的。 正確に言えば内蔵フラッシュメモリは 512MB だが、 システム側で 300MB ほど使うので、 ユーザが自由に使えるのは残り 200MB 程度となる (もちろんそれとは別に SD カードが使える)。

いまどき 200MB というのはいかにも少ない。 例えば私が Nexus One で使ってるアプリのうち、 サイズの大きいものを一部ピックアップしてみると、

わずか 8個のアプリだけで 100MB 近く使っている。 200MB に収めようと思えば、 インストールするアプリを相当厳選する必要がある (100個程度で限界)。

さすがにこれでは使い物にならないということで、 アプリを SDカード上にインストールできるようにする仕掛け Apps 2 SD (A2SD) が提案されてきた。 A2SD には App2sd など、 いろんな実装があるが、 基本的には SDカードに ext3 (あるいは ext4) パーティションを切り、 /system/ext あたりにマウントして (実はこれが難しい, 後述)、 /data/app などからシンボリックリンクを張る。

つまり、こんな感じ:

# cat /proc/mounts
	...
/dev/block/mtdblock3 /system yaffs2 ro,relatime 0 0
/dev/block/mtdblock5 /data yaffs2 rw,nosuid,nodev,relatime 0 0
	...
/dev/block/mmcblk0p2 /system/ext ext3 rw,nosuid,nodev,relatime,errors=continue,data=writeback 0 0
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:1 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
	...
# cd /data
# ls -l
drwxrwxr-x    1 system   system        2048 Oct 23 19:33 anr
lrwxrwxrwx    1 root     root            15 Oct 23 20:45 app -> /system/ext/app
lrwxrwxrwx    1 root     root            23 Oct 23 20:46 app-private -> /system/ext/app-private
lrwxrwxrwx    1 root     root            18 Oct 23 20:47 backup -> /system/ext/backup
lrwxrwxrwx    1 root     root            24 Oct 24 11:23 dalvik-cache -> /system/ext/dalvik-cache
drwxrwx--x    1 system   system        2048 Oct 24 11:59 data
drwxr-x---    1 root     log           2048 May 13 08:47 dontpanic
lrwxrwxrwx    1 root     root            17 Oct 23 20:02 local -> /system/ext/local
drwxrwx---    1 root     root          2048 May 13 08:47 lost+found
drwxrwx--t    1 system   misc          2048 Oct 24 14:02 misc
drwx------    1 root     root          2048 Oct 23 19:33 property
drwxrwxr-x    1 system   system        2048 Oct 24 14:20 system
lrwxrwxrwx    1 root     root            22 Oct 23 21:11 tombstones -> /system/ext/tombstones

アプリを Android 端末にインストールすると、 パッケージファイル (*.apk) が /data/app ディレクトリに格納 (「コピー防止」 アプリは /data/app-private ディレクトリに格納) され、 クラスファイル (classes.dex) が /data/dalvik-cache ディレクトリに格納される。 上記のように /data/app および /data/dalvik-cache はそれぞれ /system/ext/app および /system/ext/dalvik-cache へのシンボリックリンクにしてあるので、 内蔵フラッシュメモリ (/data パーティション) の代わりに SDカード (/system/ext パーティション) へ格納される、という仕掛け。

/data/data ディレクトリにはアプリが使用するデータが格納される。 /data/app および /data/dalvik-cache が、 アプリのインストール/アンインストール時のみ書き込みが行なわれるのに対し、 /data/data はアプリ動作中も読み書きが行なわれるわけで、 /data/data を SDカードへ移すとアプリの実行速度が低下したり、 あるいは頻繁な書込みによって SDカードの寿命が短くなったりする恐れがある。 もし /data/data も SD カード上に置こうとするなら、 使っている SDカードが充分高速 (Class6 以上?) で、 かつウェアレベリング (wear leveling) をサポートしているか確認したほうが無難。

私は /data/data は /system/ext へのシンボリックリンクを張らずに /data パーティションをそのまま使用している。 現時点での各パーティションの空き容量は次のような感じ:

# df
/dev:               197552K total,       0K used,  197552K available (block size 4096)
/mnt/asec:          197552K total,       0K used,  197552K available (block size 4096)
/system:            148480K total,  127580K used,   20900K available (block size 4096)
/data:              200960K total,  102148K used,   98812K available (block size 4096)
/cache:              97280K total,    9128K used,   88152K available (block size 4096)
/system/ext:       3690832K total,  269908K used, 3420924K available (block size 4096)
/mnt/sdcard:      11547432K total, 6808720K used, 4738712K available (block size 8192)
/mnt/secure/asec: 11547432K total, 6808720K used, 4738712K available (block size 8192)

私が使ってる SD カードは 16GB Class6 だが、 /data パーティションはまだ 99MB の空きがあるので /data/data を無理に /system/ext へ移動させることもないと判断した次第。

なお、Android 2.2 froyo から OS 標準で、 アプリを SD カードへ移動できるようになった。 しかし対応アプリでないと移動できないし、 現時点では多くのアプリが対応していない。 さらに 「USBストレージをON にする」 と SD カードへ移動したアプリは USB ストレージが ON の間は使えなくなるので注意が必要。

というわけで、 アプリを SDカード上にインストールできるようにするのは、 シンボリックリンクを /data から /system/ext へ張るだけのことなので全く難しくない。 しかしながら、 どうやって SDカード上の ext3 パーティションをマウントするか、 という問題がまだ残っている。