仙石浩明の日記

Android

2013年12月13日

nexus5 の充電をワイヤレス (Qi 給電) にしたので、バックアップもワイヤレスにしてみた 〜 ssh サーバを nexus5 上で動かす 〜

昨今の円安のため香港ドルが高い (>_<)。 昨年は 10円/HK$ 台だったのに、いまや 13円/HK$ を超えている。 香港 (に限らないが) の人たちが大挙して日本に買物に来る気持ちが分かる。 これだけ円安が進めば、 日本じゅうどこへ行っても、 全てのものが安く感じられるのだろう。

ARENA Scientific Icey QI Charging Pad

逆に、 日本人が香港へ行くと、全てのものが以前より 3割ほど高く見えるわけで、 物欲が萎えてしまいほとんど買物しなかった (おまけに、香港に行く直前に日本で nexus 5 を買ってしまったし)。 とはいえ、 香港までわざわざ行っておきながら何も買わないというのもアレなので、 Qi 充電器を買ってみた。 深水埗 黄金電腦商場 地下35號舖 Sunny Computer Digital Co 力生電腦數碼公司 →

HK$199 = 約2700円なので、 ちっとも安くない。 「おにぎり」 こと、 ワイヤレスチャージャー 03 なら 2200円くらいで売っているが、 「おにぎり」 の電源が専用アダプタであるのに対し、 これは汎用の micro USB ケーブルが使えるのでよしとしよう。

この Qi 充電器を USB ハブの余っているポートにつないで机の上に置き、 その上に nexus 5 を置く。 使ってみると想像以上に便利。 電話がかかってきたとき、 以前はいちいち USB ケーブルを抜いていたのだけど、 Qi 充電器ならサッと nexus 5 を手に取れるし、 電話が終わったら Qi 充電器の上に戻すだけ。 はやく全てのケータイが Qi に対応して、 喫茶店などのテーブルに Qi 充電器を標準装備して欲しいなどと思う今日このごろ。

充電がワイヤレスなのに、 PC との通信に USB ケーブルを使っていては片手落ちである。 私は普段 rsync を使って nexus 5 上のデータを丸ごと PC へバックアップしているが、 有線な adb (Android Debug Bridge) を使うのは止めて Wi-Fi を使うことにした。

ここで注意したいのは、 主導権を握る (コントロールする) のは PC 側でなければならない、 ということ。 スマホ側 (nexus 5) が主導して rsync を起動するアプリならすでにいくつか出回っているが、 PC が目の前にあるときに何が嬉しくてスマホの小さい画面をいじらなきゃならないのかと思う。 Qi 充電器の上に置いたら、 もう 1 タッチといえどスマホには触りたくない。 全ての作業は PC のキーボードで完結させたい。

つまり、 PC がクライアントとなり、 スマホをサーバとして扱いたい、 ということ。 サーバのキーボードやモニタはトラブル発生時でもなければ使わないのと同様、 家にいるときはスマホは充電器の上に置きっぱなしにしておきたい。 あるいは寝室専用になってしまっているスマホ (各部屋に一台以上、専用スマホ/タブレットが置きっぱなしにしてある) は、 寝室に置きっぱなしのままで (別の部屋の) PC から操作したい。 スマホを PC から操作できれば、 コマンド一発で、 家じゅうのスマホ (10台くらいある) をいっぺんにバックアップしたり、 相互にデータを同期させたり、 何でも思いのまま (^^)。

スマホをサーバとして扱うには、 スマホ上で ssh サーバを動かしておけばよい、 ということで早速 dropbear サーバ (軽量 ssh サーバ) と rsync を nexus 5 (だけでなく私が持っている全ての android スマホ) にインストールした。

以下、インストールのメモ:

もっと読む...
Filed under: Android,システム構築・運用 — hiroaki_sengoku @ 09:07
2013年11月23日

nexus5 に ストラップを付けてみた ~テグスを使って~

ほとんどの人にとって無用なケータイ ストラップ。 iPhone を最右翼として、 最近の (海外製) スマホのほとんど (全て?) にはストラップを付ける穴 (ストラップ ホール) がない。 しかしながら (私を含めて) ストラップが必要と思う人にとっては、 ストラップが付けられないケータイは使う気がしない。 私が使うストラップは、 腰に付けたまま電話できる長いタイプ。 日本ではあまり見かけないので香港でまとめ買いした。 一本約 80円。 常に腰と結び付けたままなので、 ケータイをどこかへ置き忘れるということがないし、 頭の高さからケータイを落下させても、 ストラップが最大限に伸びたとき地面に激突しないような長さのものを使っている。

同じように考える人が少なくないようで、 ストラップ ホールが無いケータイに、 なんとかストラップを付けようと模索する WWW ページが沢山見つかる。 nexus 5 においても、 早速ストラップを付けた人がいるようだ。

しかし、 nexus 5 の裏蓋と nexus 5 本体との間には隙間がほとんどなく、 このページで解説されているようにストラップの紐 (直径 0.7mm くらいある) を間に挟むのは少々無理がある。 裏蓋には NFC や Qi (チー) などのアンテナがあり、 本体と裏蓋が密着していないとアンテナとの接触が不良になる恐れがある。

そこで、 nexus 5 の機能には極力影響を与えず、 もちろん nexus 5 を傷付けずに、 ストラップを付ける方法を考えてみた。

nexus5 with strap

幸い、 nexus 5 の下部には、 スピーカーとマイク用の穴 (直径約 0.8mm) が、 左右にそれぞれ 16個づつある。 しかもスピーカー穴の内部には、 スピーカーとの間に直径 0.5mm 程度の糸なら無理無く通せる空間がある。 内部がギッシリ詰まっている nexus 5 において、 この空間は例外的な存在。 そこで、 太さ約 0.52mm の 10号テグス (ナイロン ライン) をスピーカー穴に通してみた。↓

put a thread through the hole of nexus5

写真 ↑ の LG-D820 と書いてある部分に、 スピーカーが入る。 写真では見にくいが、 スピーカー穴の裏側の周囲にはクッションがあり、 テグスはスピーカーとは接触しない。 もちろん、 16個あるスピーカ穴のうち 2個をテグスで塞いでしまっているので、 そのぶん音量は小さくなると思われるが、 その差は (少なくとも私には) 体感できない。

ナイロン糸が釣り糸に使用される以前は、テグスサンというヤママユガに近い蛾の幼虫の絹糸腺から作ったテグスや、スガ糸(絹)などが使用された。
釣り糸の販売は、江戸中期に徳島の漁師が薬剤を縛る半透明の紐を見て「これを使えば魚はいくらでも釣れる。」と言ったのをきっかけに大阪の船場にある薬問屋だった「広田屋」がテグス商としてスタートさせたのが始まりである。
釣糸 歴史 から引用

穴周囲の筐体の強度が不明なので、 テグスに強い荷重をかけると筐体が変形あるいは損傷する可能性も否定できない。 私の場合、 ストラップに力が加わるのはケータイを落下させた場合などに限られるので問題無いと判断したが、 ストラップの使い方によっては問題になるケースもあるかもしれない。

ちなみに、 内部には LG-D820 (北米向けモデル) と書いてあるが、 この nexus 5 は LG-D821 (その他地域向けモデル)。 EMOBILE が 39,800円で売っていた nexus 5 を、 20,000円引 (GL06P とセット割) で購入した

私は常々、 スマホの画面の最適サイズは 6インチだと思ってる (Galaxy Mega 5.8 Duos GT-I9152 を愛用している) のだけど、 google が nexus 6 を出さないのは、 デッカードに退治されてしまうからだろうか?

スピーカー/マイク モジュールを元に戻し、↓

put a speaker/microphone module

裏蓋を嵌め込んで完成。 テグスを輪にするため、 釣り糸の結び方1 を参照した。

何度も裏蓋を開け閉めしていたら、 1分もかからず簡単に開けられるようになったが、 最初は力の加減が分からず大変。 スピーカー/マイク モジュール ↑ の両端に両面テープが貼ってあり、 裏蓋がくっついているので、慎重に剥がす。 nexus 5 に傷をつけないように、 写真 ↓ にあるようなヘラ (赤色 2本) を用いる。

tools for tearing apart nexus5

青色のドライバー (+) は、 スピーカー/マイク モジュールを留めているネジ 4本を外すために使用。

Filed under: Android — hiroaki_sengoku @ 08:51
2012年3月5日

新規一括 0円の Galaxy Nexus (SC-04D) を買ってみた 〜 国際版 Galaxy Nexus と全く同じにする

mandatory option よほど在庫が積み上がってるのか、 ドコモ SC-04D Galaxy Nexus が新規一括 0円で売っていた。 あんなに大々的な宣伝を行なっておいて何をやってるんだか...

私が見た店は、 0円の条件として、 ひとりでも割50 が必須。 つまり 2年間の契約期間中に割引サービスを廃止 (あるいは回線ごと解約) する場合は、 9,975円の解約金が必要となる。 契約事務手数料 3000円の他、 初月のみ 「パケ・ホーダイ ダブル2定額」 など諸々のオプション (写真→) を付ける必要があり、 違約金以外に 5000〜7000円ほどかかる。 加入条件のオプションの多さに圧倒されるが、 「パケホダブル」 以外のオプションは初月無料がほとんどで、 今月中に解約すれば費用はかからない。 パケホダブルは月額2,100円だが日割が適用されるので、 月末近くに契約すればもっと安くなる (あいにく私が買ったのは月初だが)。

なんたって Galaxy Nexus である。 わずか 3ヶ月前に HK$5398 (約 54,000円) もしたケータイが、 2万円かからずに入手できるのは見逃せない。 思わず衝動買い (0円なので 「買った」 とは言えない?) してしまった。

SC-04D System Update Dialog 帰宅して SC-04D の電源を入れようとすると... う、電源が ON のままだったか。 てっきりショップで電源を OFF にして渡してくれたものと思い込んでいた。 そしてディスプレイが点灯してそこに表示されたのは、 無情な 「システムアップデート」 の文字。

あとで分かったが、 ショップを出て帰宅するまでの短い時間に、 9.3MB ものアップデートファイル (yakjusc_ITL41D_to_ICL53F.zip) が転送されていて、 この日のパケット代が、 いきなり 3800円。 SC-04D を安く入手しようという目論見が、いきなりパー。 なにもこんなタイミングでアップデートファイルを送りつけなくても... 無線LAN に接続するまで待って欲しかった。

で、 こんなアップデートのお知らせはサックリ無視して真っ先に行なったのは、 ブートローダのアンロック (fastboot oem unlock)。 いきなりドコモの保証がパー。

一度フツーに起動させてフラッシュメモリの初期化を行なった後 (一度フツーに OS を起動しないと、 フラッシュメモリにアクセスできない)、 Clockwork Mod Recovery を fastboot で起動する (fastboot boot <kernel>)。 そして、 初期状態のドコモ純正ROM を、 ベースバンド込みで丸ごとバックアップ。 これでいつでも元の状態に戻せるようになったので、 ClockworkMod Recovery をフラッシュメモリの 「recovery」 領域 (リカバリ用のカーネルを格納する領域) に書込む (fastboot flash recovery <kernel>)。

senri:~ $ fastboot oem unlock
...
OKAY [ 52.022s]
finished. total time: 52.022s
senri:~ $ fastboot boot recovery-clockwork-5.5.0.2-maguro.img
downloading 'boot.img'...
OKAY [  0.553s]
booting...
OKAY [  0.329s]
finished. total time: 0.882s
senri:~ $ adb shell
~ # dd if=/dev/block/platform/omap/omap_hsmmc.0/by-name/radio of=/sdcard/SC04DOMKKD.img bs=1024
16384+0 records in
16384+0 records out
16777216 bytes transferred in 6.601 secs (2541617 bytes/sec)
~ # exit
senri:~ $ adb pull /sdcard/SC04DOMKKD.img
4569 KB/s (16777216 bytes in 3.585s)
senri:~ $ mkdir backup
senri:~ $ adb pull /sdcard/clockworkmod/backup/ backup/
pull: building file list...
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/nandroid.md5 -> backup/2012-03-04.01.09.21/nandroid.md5
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/cache.ext4.tar -> backup/2012-03-04.01.09.21/cache.ext4.tar
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/data.ext4.tar -> backup/2012-03-04.01.09.21/data.ext4.tar
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/system.ext4.tar -> backup/2012-03-04.01.09.21/system.ext4.tar
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/recovery.img -> backup/2012-03-04.01.09.21/recovery.img
pull: /sdcard/clockworkmod/backup/2012-03-04.01.09.21/boot.img -> backup/2012-03-04.01.09.21/boot.img
6 files pulled. 0 files skipped.
4308 KB/s (384848109 bytes in 87.229s)
senri:~ $ fastboot flash recovery recovery-clockwork-5.5.0.2-maguro.img
sending 'recovery' (5300 KB)...
OKAY [  0.552s]
writing 'recovery'...
OKAY [  1.015s]
finished. total time: 1.567s

再び通常起動して、 (今度は抜かり無く) 無線LAN の設定を行なってから、放置 (念のため、 「データ通信を有効にする」 を無効にしておく)。 ほどなく再びアップデートファイルがダウンロードされてきた。

フラッシュに書込んだ ClockworkMod Recovery を起動して、 /cache に格納されていた 94ec403ff247.update_yakjusc_ITL41D_to_ICL53F.zip (アップデートファイル) を /sdcard へコピー。 で、ClockworkMod Recovery からこの zip ファイルをインストール。 この時点で (ClockworkMod Recovery を書込んだ) recovery 領域は、 ドコモ (というか Google) 純正リカバリ用カーネルで上書きされる。

これでビルド番号が ICL53F.SC04DOMLA1 になった。 ちなみに末尾の 「LA1」 というのは、 「L」 が 2012年 (L は 12番目のアルファベットだから) を意味し、 その次の 「A」 が 1月 (A は 1番目のアルファベット) を意味し、 その次の 「1」 は、 その月にリリースされた最初のバージョンであることを意味する。

「L53F」 も同様に、 「L」 が 2011年第4四半期 (2009年第1四半期を A として) を意味し、 「53」 が、 その四半期で 53日目であることを意味し、 「F」 は同じ日の 6番目のリリースであることを意味するらしい。 先頭の 「I」 は、 Ice Cream Sandwich の頭文字。

このバージョンのドコモ純正ROM も、 上記と同様に ClockworkMod Recovery を使って、 ベースバンド込みで丸ごとバックアップ。 無線LAN の設定を行なったので厳密には初期状態ではないが、 初期化するのが面倒なので、 まあよしとする。

以上で、 いつでもドコモ純正ROM に戻る手段を確保できたので、 ここでドコモ純正ROM にサヨナラする。 私が普段使ってる Galaxy Nexus (3ヶ月前に香港で買った) を丸ごとバックアップし、 そのバックアップファイルを SC-04D へ、 ClockworkMod Recovery を使って丸ごとリストア (もちろん、リストアする代わりに Google 純正ROM を書き込んで、 国際版の初期状態にしてもよい)。

Galaxy Nexus * 2 左が香港で買った Galaxy Nexus i9250 GSM (もちろん SIM ロックフリー),
右が今回買ったドコモ SC-04D

裏ブタ記載の文字が異なる (なぜ SC-04D には Google ロゴがない?) 他は、 全く同じ外観。 丸ごとリストアしたので、 フラッシュメモリの中身も全く同じ (もちろん IMEI など、端末固有のデータは異なる)。

丸ごとリストアしたことによって OS も書き換えてしまったので、 ドコモのテザリングの制約 (勝手に APN が dcmtrg.ne.jp に切り替わるとか) から解放される (はず)。 「パソコンなどの外部機器を接続した通信」 ではなく スマートフォン定額通信の範囲でテザリングできるはずだが、 私は興味がない (ドコモは今月一杯で解約するつもりだし) ので試していない。 OS が書き変わっても、 IMEI 上は 「ドコモ純正端末」 なので、 フツーに spモードを利用できる。 こうなってくると、 ドコモが何のために接続する端末の IMEI を制限しているのか分からなくなる。

二つの Galaxy Nexus の OS は同じになったが、 SC-04D にはまだ SIM ロックがかかっている。 ドコモショップで SIMロック解除の手続きを行なってくれるが、 ブートローダをアンロックした Nexus も対象となるのか? ブートローダだけならまだしも、 OS ごと入れ替えてしまっていても拒否されないのか?

SIMロックは、 (Samsung製) Android 端末の場合 /data/radio/nv_data.bin などで設定されている。 このファイルを 「正しく」 書き換えることができれば SIMロックを解除できるのだが、 このファイルが改変されていないか検証するために、 /data/radio/nv_data.bin.md5 に MD5 値が保存されている。 そして残念なことに、 この MD5 の算出方法が不明。 もちろん、 単純に nv_data.bin の MD5 を算出するだけではダメで、 何らかの秘密の seed が必要なのだと思われる (ファイル名の通り MD5 が使われていると仮定してだが)。

MD5 の値が一致しなかったなどの理由で検証にパスしなかった場合、 あるいは (Android を初期化したなどの理由で) そもそも /data/radio/nv_data.bin が存在しなかった場合は、 /factory/nv_data.bin を使って /data/radio/nv_data.bin が作られる。 ところが、 /factory/nv_data.bin にも、 /factory/nv_data.bin.md5 があって、 その内容が書き換えられないように保護されている。

/factory/nv_data.bin が検証をパスしないと、 /factory/.nv_data.bak が使われるらしい。 何段もの防御があって、 なかなか突破するのが難しそうである。 そこで、 改変した nv_data.bin を /factory/nv_data.bin と /factory/.nv_data.bak にコピーして、 検証が通らなくて書き戻そうにも、 本来の nv_data.bin を参照できないようにしてみた。

すると... 驚いたことに、 ドコモ以外の SIM でも使えてしまった。 google で検索すると、 あちこちで SIMロックの解除方法を説明したページが見つかるが、 ほとんど (全て?) は同様の方法であるようだ。 しかし、 この方法には重大な欠点がある。 それは、 IMEI の値が 「004999010640000」 になってしまう点。 キャリア側で IMEI の値をチェックしていなければ、 そのまま使えてしまうのかもしれないが、 これでは 「ここに不正改造無線局があります〜」 と吹聴して歩き回るのと大差なく、 甚だ具合がよろしくない。

SIM Unlock PIN というわけで万策尽きたので、 解除コード (Unlock Code) を業者から買うことにした。 だいたい $30 前後で、 ドコモ (3,150円) より若干安い。 この期に及んでドコモのサービスを使わないのは、 前述した懸念点があるのと、 ドコモショップでは 「解除PIN」 を教えてもらえなかった、 という話をネット上で見かけたため。

ドコモショップの店長が、 「このコードはドコモの内部情報になるため、お客様にはお伝えできません」 と言ったらしいが、 この話が本当なら、 とんでもない話だと思う。 3,150円も取っておきながら PIN 一つ教えないとはどーいうことだ。

ドコモショップで SIM ロック解除したケータイを海外に持って行き、 現地の SIM を入れて電源を入れたら、 「SIMネットワークのロック解除PIN」 を入力する画面になってしまい往生した、 という怨嗟の声をネット上で見かけるが、 おそらく何らかの理由で /data/radio/nv_data.bin の内容が壊れてしまい、 /factory/nv_data.bin の内容で書き戻されたために、 ロック解除PIN の入力が必要になってしまったものと思われる。

つまり、 ロック解除PIN を入力して SIM ロックを解除した後、 /data/radio/nv_data.bin および /data/radio/nv_data.bin.md5 を /factory へコピーしておけばこのような事態に陥ることを回避できる。 ただし、 Android の root 権限が必要。 root 権限がないと、 そもそも /data/radio/nv_data.bin を読むことができない。 だから、 何かあったときのため、 ロック解除PIN を記録しておくことが重要。

Cell Unlocker .net で、 device 名として 「Galaxy Nexus」、 SIM ロック先のキャリアとして、 「All Asia Countries」 を指定し、 IMEI (「*#06#」 をダイヤルすると表示される) を入力した。 すると PayPal の支払い画面に遷移するので、 $29.99 の支払いボタンを押すだけ。

7時間半後、 ロック解除PIN が書かれたメールが送られてきた。 メールには、

Video proof will be required if code does not work, it's a good idea to film inputting the unlock code so we can help trouble shoot what the problem is.

と書かれていたので、 まず、 デジカメ (ビデオカメラは持ってない) を三脚にセットして動画撮影する準備を整えた。 SingTel の SIM (ドコモ以外ならどこでも) を SC-04D に入れて電源を入れる。 すると、 ↑ の写真にあるような 「SIMネットワークのロック解除PIN」 を入力する画面になったので、 デジカメで動画撮影しつつ、 メールに書かれていた unlock code を入力した。 すると、 「ネットワークのロック解除をリクエスト中...」 と表示され、 すぐ 「ネットワークロックを解除しました。」 と表示された。 数秒後、 Android のホーム画面が表示された。

以上で、 二つの Galaxy Nexus は (IMEI 以外は) 完全に同じになった。 今まで Galaxy Nexus で使っていた Softbank SIM を、 SC-04D に入れて、 今後は SC-04D のほうを使ってみようと思う。 普通に使っている限り、 たぶん、何の違いも見いだせないに違いない。

もっと読む...
Filed under: Android,SIM — hiroaki_sengoku @ 20:21
2012年2月1日

adb (Android Debug Bridge) 経由で rsync を使ってバックアップできるようにしてみた 〜 shell の echo back を回避する方法

最初の 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 上で行ないたいと思うのが人情というもの。

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

もっと読む...
Filed under: Android — hiroaki_sengoku @ 09:44
2012年1月4日

スマートフォン用の外付バッテリー

あけましておめでとうございます。今年もよろしくお願いします。

近頃のスマートフォン (スマホ) は、 ちょっと使ってるとバッテリーが一日もたない。 出先でバッテリー切れになると大変困るので、 外付バッテリーを携帯している人も多いのではないか。 外付バッテリーには、 リチウムイオン二次電池 (充電式電池, 充電池) を利用するものと、 単三乾電池 (あるいはエネループ等のニッケル水素二次電池) を利用するものがあるが、 前者は (安全性の観点から) 充電池を交換できないことが多く、 充電池が寿命を迎えると使い捨てになってしまう (eneloop mobile booster KBC-L54D など。3900円もするものを使い捨てにするのはモッタイナイ)。

一方後者は、 リチウムイオン充電池に比べると質量あたりの蓄えられる電力量 (重量エネルギー密度) が小さい。 18650 リチウムイオン充電池が、 3.7V * 2400mAh / 47g = 188Wh/kg 程度あるのに対し、 単三のエネループは 1.2V * 1900mAh / 27g = 84Wh/kg と、 リチウムイオン充電池の半分以下しかなく、 スマホの充電用としては力不足。

特に、 単三形ニッケル水素充電池 2本を用いる外付バッテリー (eneloop stick booster など) は、 2.4V (1.2V * 2) を倍以上の 5V (USB の電源電圧) に昇圧して出力するため、 900mAh 程度 (1.2V * 2 * 1900mAh / 5V, 損失があるはずなので実際にはもっと少ないはず) しか出力できず、 スマホを充電しても満充電にはほど遠い。 単三形ニッケル水素充電池を用いるなら 3本〜4本を直列すべきだが、 そうすると重く大きくなってしまい常時携帯するには不適。

というわけで、 私はスマホの充電に、 いわゆる中華充電器 (18650 Batttery Powered USB Bright Torch, 本体側面に 「PORTABLE POWER」 と書かれている) を使っている。 これはリチウムイオン充電池を利用する外付バッテリーだが、 18650 と呼ばれる (直径 18mm 長さ 65.0mm という意味) 安価な汎用リチウムイオン充電池 (一個 300円〜500円) を用いるため、 充電池が寿命を迎えたら充電池のみ交換できる。 18650 充電池の電圧 3.7V を 5V に昇圧して USB コネクタで出力する他、 充電回路も組み込まれているので、 USB ケーブルをつなぐだけで充電も可能。

18650 battery

写真 ↑ の直方体 (白と黒) が中華充電器。 黒い方は裏蓋を外して中身の 18650 充電池が見える状態にして撮影。 手前の面の USB A ソケットに USB ケーブルを接続して充放電を行なう。 中の赤い 18650 充電池は、 ノートPC 用のバッテリーを殻割りして取り出した充電池なので、 接着剤を剥した痕がある。 その隣の青い (「UltraFire」 と書いてある) 18650 充電池は、 香港の鴨寮街 (深水埗駅の出口すぐ) で買った 18650 充電池 2個パック (2個で HK$68 = 約 680円)。

Battery Graph while charging

もちろん、 安全回路なしのリチウムイオン充電池をセル単体 (つまり 18650) で扱うことは危険であり、 発火や爆発の可能性も考慮にいれた運用が求められる。 その危険性故に、 日本では 18650 は、 一般には市販されていない (秋葉原などでは売っている店もある)。 18650 を充電器から日常的に出し入れするなど、 ニッケル水素充電池 (エネループ等) と同様の感覚で扱うことは絶対に避けるべき。

この中華充電器は軽量コンパクトでありながら、 スマホを (ほぼ) 満充電にできるくらいの電力量があるので、 私は常に持ち歩いている。

Galaxy Nexus (香港で購入した GT-I9250) のバッテリーが残り 10% になった段階 (左のグラフで 19:47 の時点) で、 中華充電器による充電を開始してみた (ディスプレイを消灯したまま放置)。 2時間55分後 (22:42) に充電が停止し、 94% まで充電することができた。

Galaxy Nexus のバッテリーは、 1750mAh のリチウムイオン充電池 (スマホの中では容量が大きい方)。 3.7V 2400mAh の 18650 を 5V に昇圧して出力する中華充電器で、 Galaxy Nexus を 10% から 94% まで充電できれば悪くない。 つまり、 充電電気量は 3.7V * 2400mAh / 5V ≒ 1700mAh 程度になる (実際には損失がある) ので、 84% (94% - 10%) を充電できれば充分。 3時間弱の充電中も Galaxy Nexus が 150mAh くらいは消費しているはず (Galaxy Nexus など大抵のスマホは、 ほとんど使わない待受け状態で放置していても 12時間くらいしかバッテリーが持たない) なので、 実際に充電された電気量は 1750mAh * 84% + 150mAh = 1620mAh くらいになっていると思われる。

充電 (中華充電器にとっては放電) が停止したときの中華充電器の 18650 の電圧が 3.38V で、 リチウムイオン充電池の放電終止電圧 2.7V よりだいぶ高いが、 中華充電器の昇圧回路が機能する電圧がこのあたりなのだろう。 また、 中華充電器を満充電したときの 18650 の電圧は、 4.13V だった。 充電中の電圧は 4.2V を超えていないようなので (オシロスコープを持ってないので正確なところは不明)、 まあ大丈夫なのだろう。

Filed under: Android,香港 — hiroaki_sengoku @ 11:56
2011年8月23日

Android 端末で Picasa を使用して画像を共有できなかったので、対策を考えてみた

share - Picasa

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

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

add Google Account

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

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

Google Account exists already

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

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

delete Google Account

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

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

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

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

もっと読む...
Filed under: Android — hiroaki_sengoku @ 07:31
2011年6月2日

Android 端末上で透過型プロキシを動かしてみる 〜 VPN のように使えて、しかも省電力

透過型プロキシ (Transparent Proxy) というのは、 ブラウザから 「見えない」 プロキシのこと。 ブラウザ自身は WWW サーバにアクセスしているつもりなのに、 ブラウザが送信したリクエストをプロキシが横取りし、 プロキシから出し直す。 サーバからのレスポンスは当然プロキシに返り、 プロキシがそれをブラウザに送信するのだけど、 パケットがブラウザに届くまでの間に送信元アドレスが書き換えられて、 サーバから直接レスポンスが届いたようにブラウザからは見える。

フツーの 「見える」 プロキシは、 ブラウザ等でプロキシ設定が必要であるのに対し、 透過型プロキシだと設定が不要。 だから一部の ISP (インターネット接続プロバイダ) などで、 フツーのプロキシの代りに使われていたりする (ユーザにプロキシ設定の方法を説明する必要がなくてサポートコストが削減できる)。 あるいは企業等で、 従業員が仕事と関係ない Web ページを閲覧していないか監視するために、 社内から社外へ接続するゲートウェイ等に透過型プロキシを設置して、 社外への http アクセスを記録していたりする (監視だけならパケットをダンプするだけでも用が足りるが、 アクセス先のサイト毎に細かな制御を行なおうとすると、 プロキシを使った方が楽)。

このように、 透過型プロキシはその存在を隠すために使われることが多いが、 ブラウザにプロキシ設定の機能が無い場合は、 透過型プロキシを使わざるを得ない。 例えば、 Android 端末で使われるブラウザの多くが、 なぜかプロキシ設定の機能を持っていない。 プロキシ経由でアクセスされると、 モバイル端末からのアクセスなのか、 フツーの PC からのアクセスなのか、 区別がつかなくなってしまうので、 あえてプロキシ設定できないようにしているのかも知れないが、 プロキシを使わないとアクセスできない場合は困ってしまう。

私の場合、 勤務先の LAN 内のサーバに社外からアクセスするとき、 社内アクセス専用のプロキシ (ここでは仮にホスト名を proxy.klab.org とする) を利用している。 例えば senri.gcd.org (自宅のサーバ、つまり社外) からこのプロキシをアクセスすると、 こんな感じ:

senri:~ $ openssl s_client -connect proxy.klab.org:443 -cert cert.pem -key key.pem -CApath /usr/ssl/certs -quiet
Enter pass phrase for key.pem:xxxxxxxx

depth=1 /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
verify return:1
depth=0 /serialNumber=-cn4oMJtlqoqfQZaTat68U68dNVbM8iQ/C=JP/O=*.klab.org/OU=GT41256819/OU=See www.rapidssl.com/resources/cps (c)09/OU=Domain Control Validated - RapidSSL(R)/CN=*.klab.org
verify return:1
CONNECT irc.klab.org:6667 HTTP/1.1

HTTP/1.0 200 OK

:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

行末に 「」 がある行が入力行。 「」 は Enter キー押下。 秘密鍵 key.pem でクライアント認証を受けて proxy.klab.org に接続し、 CONNECT リクエストを送信することにより、 社内の任意のサーバ:ポートに接続できる。 上記の例では社内 IRC サーバである irc.klab.org:6667 に接続しているが、 もちろん社内の任意の WWW サーバにも接続できる。

説明を簡単にするため proxy.klab.org と書いたが、 実際には VPN Warp を使っている (だから proxy.klab.org というサーバは存在しない)。 VPN Warp も stone で接続することができるので、 以下の説明は VPN Warp の場合もほとんど同様に適用することができる。

プロキシというと、 ファイアウォールの内側から外部のインターネットをアクセスするために用いるものと思っている人が多いせいか、 外からファイアウォールの内側をアクセスするためのプロキシは、 特にリバースプロキシ (reverse proxy) と呼ばれることもある。

proxy.klab.org を透過型プロキシとして利用できれば、 社内の任意のサーバに透過的にアクセスできるようになる。 例えばこんな感じ:

senri:~ $ adb shell
$ getprop ro.build.description
soju-user 2.3.4 GRJ22 121341 release-keys
$ su
# busybox traceroute irc.klab.org
traceroute to irc.klab.org (10.10.0.18), 30 hops max, 38 byte packets
 1  110.158.20.29 (110.158.20.29)  701.203 ms  90.517 ms  85.570 ms
 2  *  *  *
 3  *  *  *
 4  110.158.18.138 (110.158.18.138)  79.540 ms !A  *  *
 5  *  *  *
 6  *  ^C
senri:~ $ adb shell
$ telnet irc.klab.org 6667
:irc.klab.org NOTICE AUTH :*** Looking up your hostname...
:irc.klab.org NOTICE AUTH :*** Found your hostname

soju-user 2.3.4 GRJ22」 つまり Android 2.3.4 な Nexus S で、 パケットが届かないはずの irc.klab.org (10.10.0.18) に対して、 telnet でアクセスできている。 telnet でアクセスできるということは、 もちろん任意の IRC アプリで irc.klab.org にアクセスできるということ。

VPN (Virtual Private Network) でも同じことができる! という声が聞こえてきそうだが、 VPN だと TCP でデータを送受信していないときも、 VPN セッションを張っているだけでいろんなパケット (例えば ARP) が行き交って、 そのたびに電波が飛んで電池を消耗するので、 あまりモバイル向きではないと思う。

あるいは、 ConnectBot などを使って ssh で port forward を行なう方法もあるが、 これまた ssh セッションを張りっぱなしだと電池消耗が心配だし、 かといって IRC を使う前に毎回 ssh 接続を行なうのはメンドクサイ。 また、 通信先/宛先ポートが増えるたび port foward 設定を追加するのもメンドクサイ。

その点、 透過型プロキシだと実際にパケットが飛ぶときのみ通信が行なわれるので、 電池消耗をあまり心配せずに TCP セッションを張りっぱなしにできる。 また、 LAN 内の通信先/宛先ポートが増えても設定変更は不要。 モバイルで LAN 内にアクセスする方法として最適だと思う (便利なのに普及していないのはナゼ?)。

もっと読む...
Filed under: Android,stone 開発日記 — hiroaki_sengoku @ 09:41
2011年5月18日

nook color を買って CyanogenMod 7 をインストールしてみた 〜 レンガ化リスクが無い PC のようなタブレット端末

ハワイ滞在中、 泊ったホテルのすぐ近くに米国最大の書店チェーン Barnes & Noble があった。 当然しばしば立ち寄ったが、 電子ブックリーダ nook のデモ機を店内の一番目立つ場所 (入口を入ってすぐのところ) に並べて説明員が張り付いていて、 いつ訪れても、 来店する人々に nook を勧めたり説明したりしていた。 昨年 (2010年4月) 訪れたときもこういう状態だったので、 もうかれこれ一年以上やっているのだと思うが、 今回は昨年と違って、 nook color がラインアップに加わっている。

電子ブックリーダというと、 初代 nook や Kindle や BORDERS (米国二番手の書店チェーン, 経営再建中) の kobo eReader など、 電子インク (E Ink) をディスプレイに用いた機種が思い浮かぶが、 nook color は普通の液晶ディスプレイ。 電子書籍を読むなら圧倒的に電子インクの方が適していると思うが、 あいにく日本では電子書籍の普及は今一つだし、 近い将来普及が進むかというとなかなか難しそう (そもそも普及に懸ける書店の意気込みがぜんぜん違う)。 だから (英語がニガテな私は) 電子インクなブックリーダにはあまり興味がなかった (自炊は大変そう)。 でも、 nook color は液晶ディスプレイなので Android タブレットとして使えそう。

店頭デモ機をいじってみると、 そのままでも WWW ブラウザで日本語表示できるし、 ちょっと検索してみるとハックもいろいろ進んでいる (Android 3.0 honeycomb も動く) ようだ。 しかも $249 と Android タブレットとしてみると格安。 同じく 7インチ液晶の Galaxy Tab (382g) よりは重いが、 9.7インチ液晶の iPad2 (601g, ずっしり重くて私には無理) よりは軽い 450g.

というわけでハワイ滞在最終日に衝動買い (^^;)。 ちょうど円高が進んでいる昨今でもあるし〜 (言い訳)。 説明員のお姉さんに、 コレちょうだいと言うと、 すぐカウンターの下から (そんなところに在庫を入れていたのか) 取り出してレジへ。 ハワイ州の Sales Tax 4.710% が加算されて $260.73 (約 21000円)。 そのままスーツケースに放り込んで帰国。

で、 まず root 化。 Auto-Nooter 3.0.0 を使うと、 root 権限の取得から各種ソフトウェアのインストールまで、 全自動でやってくれるらしい。 Auto-Nooter をダウンロードして、 micro SD カードに書込み、 nook color に挿入して USB ケーブルで PC とつなぐと、 勝手にブートして勝手に全部やってくれる。 なんて簡単な...

ところが!

もっと読む...
Filed under: Android,Hawaii — hiroaki_sengoku @ 07:43
2011年5月7日

米国 T-Mobile のプリペイド SIM カードで Nexus S を使ってみた

米国 AT&T のプリペイド SIM カードは、 $100 ぶんの度数を購入 (refill) すると、 1年間有効。 昨年訪米したときに $100 refill しておいた (さらに直前に Data Package 100MB を購入しておいた) ので今回の訪米では、 最初から (飛行機の外へ出た直後から) Nexus One で通信できた。

ところが今回は Nexus One の他に Nexus S も (ついでに言うと Galaxy S も) 持ってきている。 Nexus S は、 UMTS (W-CDMA) I/IV/VIII (2100MHz/AWS/900MHz) のみ対応で、 AT&T の UMTS II (1900MHz) は対応していない。 もちろん EDGE (Enhanced Data Rates for GSM Evolution) なら Nexus S でも対応しているが、 3G 対応スマートフォンで EDGE を使うのは悲しすぎる。 そこで AWS (Advanced Wireless Services, 上り1.7GHz 下り2.1GHz) を使う T-Mobile のプリペイド SIM カードを購入してみた。

いたるところにある AT&T ストア (ホノルル市で 7ヶ所) と比べると、 T-Mobile ストアはホノルル市に 2ヶ所しかないが、 うち一軒は幸いダウンタウンの比較的アクセスしやすい場所 1100 Alakea St にあるので、 T-Mobile store ハワイ唯一の公共交通機関 TheBus で行ってみた:

ちなみにホノルル市のもう一軒は Kahala にあるようだが、 (車無しでは) とてもアクセスしにくそう。 しかも Google Map で見ると、 「存在しないと報告されました」 などと書いてある。

ダウンタウンの T-Mobile ストアに入るなり、 スタッフが寄ってきたので Prepaid SIM を 「Pay As You Go」 プランで買いたい旨を伝えた。 ID (写真入りの身分証明書) を求められたので、 写真入りの Debit カードを提示したら、 住所を言う必要もなく、 携帯電話を見せる必要もなく、 すんなり購入できて、 しかも (頼んでないのに) Activation まで行なってくれた。

店内に椅子がなかったので、 店の外に出て石段 (上の写真の 「1100 ALAKEA」 と書いてあるブロック) に腰掛けて、 購入した SIM を Nexus S に入れてみた。 Nexus S から、 Nexus One の電話番号へかけたら、 無事 Nexus One の着信音が鳴った。 Activation はホテルに戻ってからゆっくりやろうと思っていただけに、 あっさり Nexus S が使用可能状態になってしまって拍子抜け。

もっと読む...
Filed under: Android,Hawaii,SIM — hiroaki_sengoku @ 17:57
2011年4月8日

Galaxy S を Android 2.2.1 へ更新したら、アプリが次々と異常終了するようになってしまった 〜 原因と復旧方法

Sorry! The app has stopped unexpectedly.

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 recoveryAmon 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)。 そりゃ初期化すれば直ることが多い (より事態が悪化して再起不能になるケースも無いわけではないので、 手放しで推奨するわけにはいかない) が、 トラブルの原因が闇に葬られるので、 私としてはきちんと原因究明した上で (可能なら設定等も温存したまま) 直したい。

もっと読む...
Filed under: Android — hiroaki_sengoku @ 07:57
2011年3月24日

Nexus S を素のまま root 化する方法 〜 アンロック不要、リカバリROM書換も初期化も不要 (GRH78 まで)

遅ればせながら 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 権限を奪取できてしまうわけで、 いいんだか悪いんだか...

もっと読む...
Filed under: Android — hiroaki_sengoku @ 09:14
2011年1月17日

Huawei IDEOS U8150 の各国キャリア向けファームウェアの比較

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

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

CBSPBasebandAMSS キャリア等ビルド日時 CST
127818052210B235 香港 數碼通2010-08-08 16:16:18
1978210322201003B238 台灣 遠傳2010-09-03 19:57:29
0082222201003B239 Singapore C2O Mobile2010-09-11 12:31:46
18282222201003B239 Pakistan CMPak2010-09-11 12:31:46
19182222201003B239 Australia2010-09-11 12:31:46
1268230122201003B239 USA T-Mobile2010-09-17 21:21:49
2038230122201003B239 Belarus Velcom2010-09-17 18:37:35
2038230122201003B239 Australia BP CJ2010-09-17 18:37:35
12682522201003B239 New Zealand 2degrees2010-09-26 17:15:43
12682622201003B254 Australia Virgin mobile2010-10-14 20:39:16
12682622201003B254SP01 Mexico Iusacell2010-10-14 20:39:16
12682722201003B254 Peru Movistar2010-10-21 20:53:39
12682722201003B254 BrightPoint2010-10-21 20:53:39
12682722201003B254 Philippine TCI2010-11-06 12:23:13
028270122201003B254 Italy Vodafone2010-10-19 22:28:32
1268270322201003B254 Italy Vodafone2010-11-20 12:39:21
12682822201003B254 Australia Vodafone2010-10-27 18:48:49
1268280122201003B256 Singapore M12010-10-27 18:48:49
2308280122201003B256 Pakistan Ufone2010-10-27 18:48:49
12682922201003B257 Normal2010-11-01 22:52:56
12682922201003B257 Cambodia Beeline2010-11-01 22:52:56
12682922201003B257 South Africa Vodacom2010-11-01 22:52:56
12682922201003B257 Finland Techdata2010-11-01 22:52:56
1268290222201003B257 Vietnam VHH2010-11-01 22:52:56
12683022201003B259 EMOBILE2010-11-24 21:19:04
1268300122201003B257 Norway Telenor2010-11-10 03:55:12
1268310222201003B257SP01 日本通信2010-11-25 16:54:11
1268310322201003B257SP01 日本通信2010-11-25 16:54:11
12683222201003B257 Cambodia CamGSM2010-11-23 18:38:55
1268320122201003B257 India Aircel2010-11-29 18:18:52
1268320222201003B257 India Tata DoCoMo2010-11-29 18:18:52
1268320422201003B257SP01 India Tata DoCoMo2010-11-29 18:18:52
12683322201003B257 Italy WIND2010-12-03 12:04:10
25383622201003B257 Germany2011-01-11 17:35:05
1678360322201003B266 Sudan Zain2011-01-28 12:00:11
12683622201003B257 Holand2011-02-14 12:33:39

ビルド番号は、 どのファームウェアも 「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) 上で動作する.

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 以降では何かが変わったようだ。

もっと読む...
Filed under: Android — hiroaki_sengoku @ 09:52
2011年1月6日

香港で Hutchison (3HK) SIM カードと Galaxy S (GT-I9000) を買ってみた

2009年の年末に香港に行ったときは、 Hutchison と CSL の SIM を比較して CSL を選んだが、 単に CSL の HK$1000 Prepaid SIM の有効期限が 2年だった (フツーは 6ヶ月) ことに魅力を感じたからで、 データ通信自体を比較したわけではなかった。 そこで今回は Hutchison Telecom Hong Kong (和記電訊, 3HK) の 3G Int'l Roaming Rechargeable SIM Card (3G 國際漫遊循環儲值咭) HK$98 (約1080円) を買うことにした。

3HK 3G Int'l Roaming Rechargeable SIM

今回の訪港は夜のフライトで、 しかも向かい風 (偏西風) が強くて到着が大幅に遅れ、 香港国際空港に着いたのは 23:00 過ぎ。 出発ロビーの 3Shop (3HK の店) も 1010 Centre (CSL の店) も既に閉ってる (正確に言えば到着ロビーに着いた時点で 23:30 だったので行くのを断念)。

ホテルへのバス (パックツアーなので空港⇔ホテルの送迎が含まれてる) の中で 24:00 を過ぎたので、 さっそく Nexus One (2009年の年末に購入した HK$1000 Prepaid SIM を入れてある) で 「179179」 にダイヤルして、 CSL の Mobile Broadband Service の 5-day pass を申し込む (HK$178, 約1960円)。

CSL の Mobile Broadband Service (データ通信サービス) は 24:00 が課金の区切りとなるので、 24:00 前に申し込んでしまうとそれが一日目とカウントされてしまう (例えば 23:00 に使い始めると、 1-day pass なのに 24:00 までの 1時間しか使えない恐れがあるが、 本当にそうなるのか恐くて実験できない ^^;)。 もっと早い時間に香港に着く場合だと、 最初の日に Mobile Broadband Service を申し込むべきか悩ましいことになる。
その点、 3HK SIM だと、 24:00 区切りなのは CSL と同じだが、 一日の上限 HK$28 (約310円) に達するまでは HK$2/MB の従量課金なので、 何時に着こうが迷わずデータ通信を開始することができる。
CSL の 1-day pass は HK$50 (約550円) なので 3HK の HK$28 が圧倒的に安く感じられるが、 5日間で考えると CSL の HK$178 に対し、 3HK は HK$28*5 = HK$140 と、 差が縮まる。

で、ホテルに着いて Nexus One を WiFi AP (ポータブル Wi-Fi アクセスポイント, Android 2.2 の標準機能) として使う。 ホテルの部屋でも無線LAN サービスが提供されているのだが、 一日の利用料が HK$100 (約1100円) とバカ高いので、 滞在中はずっと Nexus One をアクセスポイント代わりに使った。 ノートPC 2台 (前回前々回、香港で購入した NetBook) と Android 端末 2台 (今回購入した Galaxy S と IDEOS U8150-B) でこの 「WiFi AP」 を利用したが、 常に安定して利用できた。 しかも日中は (当然だが) スマートフォンとして使えるわけで、 これならモバイル WiFi ルータ専用機なんて要らない。

翌日、 旺角へ行って適当に歩いていて見つけた 3Shop (亞皆老街40-46號) で
3G Int'l Roaming Rechargeable SIM Card (3G 國際漫遊循環儲値咭) HK$98 を買う。
そして、 そこからほど近い電器店、 百老滙 Broadway (西洋菜南街78號) で Galaxy S (i9000) を買った。

もっと読む...
Filed under: Android,SIM,香港 — hiroaki_sengoku @ 09:36
2010年12月31日

香港の深水埗で華為 IDEOS U8150-B (EMOBILE S31HW) を買ってみた

年末に香港へ行って電脳街を巡るのが毎年の恒例行事になってきた。 香港の電脳街は、 すでに秋葉原を追い越した感じがする。 近頃の秋葉は面白いモノをあまり見かけなくなり、 たまに見かけても、 大抵は香港などで流行ってるモノを単に持ち込んだだけで、 しかも値段は香港の倍以上だったりする。 デフレと言われて久しい日本だが、 PC にしろケータイにしろ値段が高すぎる。 これから発展していくアジアと、 これから衰退していくだけの日本ということなのか。

いつものように深水埗の高登電腦中心を巡回していたら、 大一(香港)有限公司IDEOS U8150-B を HK$1380 で売っているのを見つけた。 U8150-B といえば来年1月中旬にイー・モバイルから発売される予定の Pocket WiFi S (S31HW) の同型機。 ただし、 ファーウェイによれば、 グローバル展開されている 「IDEOS」 と日本向け S31HW は別の製品、 ということらしい。 なぜ日本は 「グローバル展開」 の対象ではないのだろう?

「Pocket WiFi S」は、 音声通話機能とAndroid™ 2.2を搭載したWi-Fiルーターです。 Android™ 2.2搭載端末としては国内最安※1となる端末価格19,800円(税込)での提供と、 国内最軽量※2の重さ約105gサイズを実現しました。

「国内最安」 「国内最軽量」 つまり世界基準では安くもなければ軽くもないということ。 本来 Android は 2.2 froyo 以降からデフォルトで 「ポータブルWi-Fiアクセスポイント」 として使えるのに、 わざわざ 「Wi-Fiルーター」 と呼んでいるあたりにも、 いかに日本が世界標準からずれてきてしまっているかを感じる。

とはいえ、 日本では 19,800円でしか買えない端末が HK$1380 (約 14,500円) で買えるのなら悪くない。 思わず衝動買いしてしまった。 画面が QVGA (2.8" 320x240) だったり、 内蔵カメラが貧弱 (一応 320万画素なのだが...) だったり、 CPU が MSM7225 528MHz だったりと、 Android 端末としては見劣りするものの W-CDMA I/II/V/IX (2100/1900/850/1700MHz) に対応したスマートフォンが 15,000円弱で買えるとなると、 一気に普及が進むヨカン。 ちょうど 2年前、 ここ香港で 4バンド GSM 機を HK$899 (約 10,000円) で買ったのが遠い昔のことのようだ。

中華 Android 端末なんて 「安かろう悪かろう」 だろうなどと思ってはいけない。 カスタマイズしすぎて Android とは別物になりつつある国産スマートフォンより、 よほど素直で使いやすい (そして圧倒的に安い)。 買った当初は値段相応の期待しか持っていなくて、 メイン端末が壊れたときなどの非常用端末くらいの感覚だったのだが、 高解像度の画面 (およびマルチタッチ) を必要としないアプリのほとんどがそのまま動いてしまった。 これなら非常用としてだけでなく、 大きな端末を持ち歩きたくない時とかにも使えそう。 Android 2.2 へアップデートできない一部の国産 Android 端末だと、 動かないアプリが沢山でてきてしまう。

ただし、 多くのアプリ開発者が QVGA などという尋常でない低解像度を想定していないためか、 Android マーケットでダウンロードできないアプリが少なからずある。 そういうアプリも別の Android 端末でダウンロードして得た apk ファイルを、 「adb install」 コマンドなどで IDEOS へインストールしてみると、 ほとんどが特に問題無く使えるようだ。

購入時のファームウェアは、

Androidバージョン2.2
ベースバンドバージョン2210
カーネルバージョン2.6.32.9-perf
huawei@product #1
ビルド番号U8150V100R001C127B818SP05

だったが、 この 「ビルド番号」 だと、 日本の一部(?)のキャリアの SIM でデータ通信できないという問題がある (音声通話は可能)。 例えば、 ドコモの SIM で mopera U を使う場合は 3G 通信可能だが、 ソフトバンクの銀SIM/黒SIM や、 WILLCOM CORE 3G の SIM では接続できなかった。

Huawei のページで U8150 のファームウェアを検索してみると、

ProductSoftware NameRelease Date
U8150U8150 V100R001C02B82 7SP02(Italy Vodafone ) 2010-12-15

が見つかった。 Italy Vodafone と書いてあるあたりが気になるが、 google で検索してみると、 このファームウェアを書込んだら 3G 通信できるようになった、 という旨のページを見つけた:

huaweidevice.comのサイトから、 「U8150 V100R001C02B82 7SP02(Italy Vodafone ) Host Software」 をダウンロードして解凍し、 出てきたファイルをmicroSDにコピーして、 ボリューム上と終話ボタンを押しながら電源を入れればファームアップが始まります。 一度目最後に失敗したら一度電池を抜いてもう一度同じ操作をすれば、ファームアップが正常に完了です。
ファームアップ後は、 まっさらに初期化されるため、 最初から設定しなおしです。 とはいえ、Andorid2.2とマーケットアプリのおかげで、 Googleアカウントを入れれば、 アプリも全部自動で勝手にマーケットからダウンロードして復活してくれるので楽です。 ファームアップ後のrooted も可能です。

さらに、 元のファームウェア V100R001C127B818SP05 も Huawei サイトからダウンロードできるようなので、 最悪の事態になっても元に戻せるだろうと思い、 上記ファームウェアを IDEOS に書込んでみた。 ファームウェアに同梱されている 「U8150 Software Upgrade Guideline」 に書込み方法の説明がある (英語版とイタリア語版の説明書が同梱)。

こばこのひみつ」 に書かれている通り、 書き込みの最後で 「失敗」 するのだが、 いったん電池を抜いて再起動すると正常に起動した。 また RageAgainstTheCage exploit を利用して root 権限を再取得できた。

更新後のバージョンは以下の通り:

Androidバージョン2.2
ベースバンドバージョン22201003
カーネルバージョン2.6.32.9-perf
huawei@product #1
ビルド番号U8150V100R001C02B827SP01

ダウンロードしたファームウェアのファイル名は末尾が 「...7SP02」 だったのに、 ビルド番号が 「...7SP01」 なのが気になるが、 ソフトバンクの銀SIM や WILLCOM CORE 3G SIM で試してみたところ、 正常に 3G 通信できている。

Filed under: Android,香港 — hiroaki_sengoku @ 01:11
2010年12月4日

Android 端末 IS01 のカーネルを入れ替えてみた 〜 さよならデッカード LSM

先週末 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 の開発チームは致命的なミスを犯した。

もっと読む...
Filed under: Android — hiroaki_sengoku @ 12:59
Older Posts »