光iフレームのファイルシステムを調べる(1)

Linuxのソース探検の次は、光iフレームのファイルシステムを調べてみます。
まだ途中ですが…。

基本的な情報はコンソールに出てくるメッセージで確認できます。
通常、このメッセージはdmesgコマンドで確認できますが、光iフレームではroot権限が必要です。
adb bugreportで得られるレポートでも一部情報は得られますが、root権限があるほうが何かと便利なので、ここは素直に(?)取りに行きます。

もちろん、これはOSの脆弱性を攻撃してroot権限を取るという行為なので、以後何が起きても自己責任です。念のため。

やり方は、いつものこちらにも記載されている通りです。

(-_-): WDPF-701ME

rageagainstthecage-arm5.binを実行したら、私の場合は一発でroot権限が取れました。

SuperUser.apkをインストールしておくと、suすると端末の画面上に許可を求めるメッセージが出るようになります。

これで、Linux起動時のシーケンスはもちろん、ファイルシステムのそこかしこが覗き放題になりました。

…が、これって結構危険な状況ではあるんですよね。
遅かれ早かれ、何かしくじってシステムを壊してしまうことになる気がします。
スーパーユーザー権限は不必要に使うものではないです。

そこで、今後に備えて、2つほど安全策を考えてみました。

1つは、光iフレームのファイルシステムのバックアップを取ること。
光iフレームに毎回shellで接続するのではなく、ファイルシステムのコピーをMac側へ持ってきてしまえば、少なくとも中身の調査はMac側だけで行えます。

持ってくるには、adb pullするという強引な手もなくはないですが、それよりもディスクイメージを作成し、Mac側でイメージファイルをマウントするほうがスマートです。

もう1つは、コンソールとしておそらくシリアルポートが使われているはずなので、光iフレームの基板上からシリアルポート信号を引っ張りだすことです。

これができれば、adbの助けを借りずとも、コンソールから直接shellへ入れるようになります。

さて、まず1つ目のディスクイメージですが…
光iフレームはフラッシュメモリ上にファイルシステムを作っています。
ディスクに相当するデバイスは、/dev/mtd**になるようです。

ただ、ファイルシステムは通常のLinuxのようなext3などとは違います。
dmesgを見ると、

kernel: VFS: Mounted root (jffs2 filesystem) on device 31:6.

というログがありましたので、jffs2ですね。
これはフラッシュメモリをターゲットに設計されたファイルシステムです。

ところで、光iフレームはルートファイルシステムを2つ持っているようです。

kernel: 0x000000000000-0x000000080000 : “boot1”
kernel: 0x000000080000-0x000000100000 : “boot2”
kernel: 0x000000100000-0x000000200000 : “ctrl”
kernel: 0x000000200000-0x000001200000 : “nvdata”
kernel: 0x000001200000-0x000001500000 : “k0”
kernel: 0x000001500000-0x000001800000 : “k1”
kernel: 0x000001a00000-0x000009800000 : “root0”
kernel: 0x000009800000-0x000011880000 : “root1”
kernel: 0x000011880000-0x000038e80000 : “userdata”
kernel: 0x000038e80000-0x000058e80000 : “dpfdata”
kernel: 0x000058e80000-0x000060e80000 : “firmwarestorage”
kernel: 0x000060e80000-0x000068e80000 : “factoryreset”
kernel: 0x000068e80000-0x000068f00000 : “serialdata”
kernel: 0x000001800000-0x000001a00000 : “vcfw”

こんな感じになっているので、boot1とboot2、k0とk1、root0とroot1があります。
ファームウェアの更新のために、起動に必要なファイルシステムは2つずつ持っているのかもしれません。

さて、とりあえずルートファイルシステムはroot0ないしroot1ですから、boot1が/dev/mtd0とすると、/dev/mtd6と/dev/mtd7がroot0、root1に相当すると思われます。

このディスクのイメージを取るには

dd if=/dev/mtd6 of=/sdcard/mtd6.bin

こんな感じでSDカード上に保存します。

このファイルをMac上に持ってきて、調べたいわけですが、残念ながらMacはjffs2を読めないんですね…。

というわけで続きます。

WDPF-701MEのソースコードを眺める

光iフレームのソフトウェアのうち、オープンソースを利用しているものはソースコードがNTT-MEからダウンロードできます。

弊社製光iフレーム WDPF-701ME をご購入のお客様へ

これをダウンロードして、中身を覗いてみました。

予想通り、中身はAndroidとLinuxカーネルです。
Androidはよく分かりませんが、Linuxは昔それなりに使い込んでいたので、ちょっと見てみました。

カーネルは2.6.29ですが、ファイルの更新日付を見てみると、2010年10月21日付けのものと、2009年のものがあります。
新しいファイルは、おそらくBroadcomが自社プラットホーム向けに手を加えたものだと思われます。

find . -mtime -250d | wc

してみると、1600ほどのファイルが更新されていました。

更新されたファイル群を、ざっとディレクトリ名だけ眺めてみます。

find . -mtime -250d -type d | more

すると、大幅な更新が目立つのは

./arch/arm/mach-bcmring
./drivers/char/broadcom
./vmcsx

というあたりです。
archの下のソースは個別のハードウェアプラットホームに依存する内容ですから、bcmringというのは光iフレームそのもの、ないしはその開発ボードの名称かもしれません。

そう思って先日の、adb bugreport で取ったログをgrepしてみると、

26 26 0% D 0K 0K fg root bcmring_ddrvpmp[ro.hardware]: [bcmring_custom]
<4>bcmring_pm_init: Initializing Power Management for BCMRING….
<6>bcmring-rtc0 bcmring-rtc0: rtc core: registered bcmring as rtc0
<6>bcmring-rtc0 bcmring-rtc0: setting system clock to 2011-06-12 10:01:52 UTC (1307872912)
<4>bcmring_net configuration: brcmMode=0, descRx=64, descTx=1024
root 26 2 0 0 fg c0059800 00000000 D bcmring_ddrvpmp
root 26 2 0 0 20 0 0 0 fg c0059800 00000000 D bcmring_ddrvpmp

という具合にひっかかってきました。
どうやら光iフレームのハードウェア依存の情報は、mach-bcmringの下のコードを見れば見つかりそうですね。

先日気になっていた、Linux起動時の

bcm11xx_wait_sesdone: no ack

というメッセージも、出所がわかりました。

sh-3.2$ find . -mtime -250d|grep bcm11xx
./i2c/busses/i2c-bcm11xx-hw.c
sh-3.2$ grep wait_sesdone ./i2c/busses/i2c-bcm11xx-hw.c
static int bcm11xx_wait_sesdone( int clear_cmd )
if ( bcm11xx_wait_sesdone(1) < 0) if ( bcm11xx_wait_sesdone(1) < 0) if ( bcm11xx_wait_sesdone(1) < 0) if ( (ack = bcm11xx_wait_sesdone(0)) < 0) if ( bcm11xx_wait_sesdone(1) < 0) sh-3.2$

ソースコードを見てみると、

static int bcm11xx_wait_sesdone( int clear_cmd )
{
(略)
ret = bcm11xx_wait_interrupt();
(略)
/* Get status from interrupt status register */
isr = ret;
(略)
if( isr & REG_I2C_ISR_NOACK )
{
I2C_DEBUG(DBG_ERROR, “no ack\n”);
i2c_errors++;
}

と、こんな流れになっています。

タイムアウトするとタイムアウトのエラーメッセージが出るようですが、ログにはそのエラーは出現していません。
なので、i2cで接続されているデバイスの何かが、反応が遅いだけなのかもしれません。

まあ、i2cで何が繋がっているのかが分からないので、これ以上は分かりませんが…

光iフレームを普通のAndroidタブレットに

これまでiPod TouchやiPadしか使っていなかったので、Androidの端末は勝手が違うこともいろいろあります。

「ウイジェット」と「ホームアプリ」もそういうものの一つです。

光iフレームのスライドショーの画面に、時計やカレンダーのウイジェットを表示させて、ウイジェットは、まあ何となく雰囲気は分かりました。

ちなみにカレンダーはこちらを使わせて頂きました。

side2.jp » Calendar Widget

ホームアプリは、感じとしてはビジュアルシェルということなのでしょうかね。

ネットをさまよっていたら、このページを見つけて、真似させていただきました。

家モバイラーの戯言 : 光iフレームに野良アプリをインストール その2

ここに書かれているLauncherProを普通にadbでインストールしたら、いつもと違ってアプリ一覧に出てきません。

再起動したら、ホームアプリを選択する画面が出てきました。

そこでLauncherProを選択。

なんと、光iフレームが普通のAndroidタブレットになりました…。

まあ最初からそういう使い方をしたいと思っていたので、願ったりかなったりですが。

動きも、標準のスライドショーアプリよりも軽快です。

あと、上記のページにはSimejiの設定方法も書かれていたので、これも実行しました。

実は前回Simejiをインストールしたものの、どうやれば入力がSimejiに切り替わるのか分からず、アンインストールしてしまっていました。

テキスト入力フィールドで長押しすれば選択ダイアログが出てくるのですね…。

何日か経って、慣れてきたせいか、この光iフレームもそこそこ使い物になる気がしてきました。

K-9 Mailでメールマガジンを見て、リンクされているページはDolphin Browserで閲覧。

一休みするときにTwidroydでツイッターを眺めたり、Tuboroidonで2ちゃんねるを眺めたり。

ビューワー中心の使い方なら、iPadには劣るけどiPod Touchより画面が大きいだけ有利かなと思わないでもありません。

これでもう少しバッテリーがましだったら、コミックビューワで電子書籍端末代わりにもなりそうだったのですが…。

ちなみにコミックビューワはACV(Droid Comic Viewer)が割といい感じでした。