reboot recovery

■とっかかり

292
 adb reboot recoveryでリブートするとメニュー表示無しのリカバリ画面になるけど 
 nexus oneかなんかみたいにこの画面でキー入力したらメニュー出るのかも 
 
 さあみんないろんなキーを押してみるんだ!! 

308
 apk抜き出しだけならddmsで出きる。 
 てか、うちのをreboot recovery かけたら携帯にと三角の中に!マークが出てキーを受け付けない画面になるわ。 


■準備段階

496
 どなたか 
 いま、手元にis01がないので 
 /systemのbuild.propに 
 
 persist.service.adb.enable=1 
 
 を入れて、 
 reboot recovery 
 してみてもらってrecoveryからadbが認識するかどうか 
 見てみてもらえますか? 

497
 おまえら早く手伝えよ 

498
 >>497 
 いやだって否応なしでリカバリされちゃうだろ 
 ちょっと無理ッス 

500
 >>498 
 あ、いや、 
 boot recoveryしただけならリカバリーは走りませんよ。 
 それは保障します。 

501
 すみません、超初心者なのですみませんがrootをPC側でとったあとカレントディレクトリのbuild.prop 
 をどうやって書き換えたらいいのでしょうか 
 
 # mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system 
 mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system 
 mount: Operation not permitted 
 # rm /system/build.prop 
 rm /system/build.prop 
 rm failed for /system/build.prop, Read-only file system 
 
 ってでちゃいました。もしかしてmodules_enabler入れてないとダメっすか? 

502
 >>501 
 modules_enablerとsystemの書き込みが必要なのですが、 
 危険なのでわかる人待ちしましょう^^; 

503
 力不足によるご提供ができず申し訳ございません。おとなしくしております。 

507
 >>496 
 C:\android\android-sdk-windows\tools>adb shell 
 error: device not found 

508
 >>496 
 >/systemのbuild.propに 
 
 これ、recoveryパーティションの、default.prop じゃなくて? 
 
 >persist.service.adb.enable=1 
 > 
 >を入れて、 
 >reboot recovery 
 >してみてもらってrecoveryからadbが認識するかどうか 
 >見てみてもらえますか? 

509
 >>496 
 # getprop | grep adb 
 getprop | grep adb 
 [persist.service.adb.enable]: [1] 
 [init.svc.adbd]: [running] 
 
 $ adb reboot recovery 
 画面→IS01 リブート→△に!マーク と Android端末のアイコンの図 
 
 タスクマネージャで IS01 が!マークでCOM認識せず 
 (DIAG改変版インストール→COMポート認識) 
 ↑初回したときは認識して、要らなかったような気がした。 
 
 しばらく待って。。。。 
 
 $ adb shell 
 $ ls -l 
 ls -l 
 drwxrwx--x system cache 2010-12-02 19:14 cache 
 drwxr-xr-x root root 2010-12-02 19:55 data 
 drwxr-xr-x root root 2010-12-02 19:55 sdcard 
 drwxr-xr-x root root 2010-12-02 19:55 tmp 
 drwxr-xr-x root root 2009-12-31 15:00 system 
 drwxr-xr-x root root 1970-01-01 00:00 sys 
 drwxr-x--- root root 1970-01-01 00:00 sbin 
 drwxr-xr-x root root 1970-01-01 00:00 res 
 dr-xr-xr-x root root 1970-01-01 00:00 proc 
 -rwxr-x--- root root 582 1970-01-01 00:00 init.rc 
 -rwxr-x--- root root 2149 1970-01-01 00:00 init.qcom.sh 
 -rwxr-x--- root root 4693 1970-01-01 00:00 init.qcom.rc 
 -rwxr-x--- root root 2982 1970-01-01 00:00 init.qcom.post_boot.sh 
 -rwxr-x--- root root 1677 1970-01-01 00:00 init.goldfish.rc 
 -rwxr-x--- root root 121032 1970-01-01 00:00 init 
 drwxr-xr-x root root 1970-01-01 00:00 etc 
 -rw-r--r-- root root 2262 1970-01-01 00:00 default.prop 
 drwx------ root root 2010-10-18 03:47 root 
 drwxr-xr-x root root 2010-12-02 19:55 dev 
 
 $ mount 
 mount 
 rootfs / rootfs rw 0 0 
 tmpfs /dev tmpfs rw,mode=755 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/mtdblock5 /system yaffs2 rw 0 0 
 /dev/block/mtdblock1 /cache yaffs2 rw,nodev,noatime,nodiratime 0 0 
 
 $exit 
 exit 
 
 $adb reboot 
 →正常起動 

511
 >>508 
 ソースコード見ると、/system/build.propで/default.propは上書きはしてくれているので、 
 /system/build.propに書けばいけるかなぁと期待したのですが、無理そうですね。 
 /dataは、recoveryのほうではマウントしていないので。 
 残念 

512
 >>509 
 あれ?いけたってことかな。 

513
 おーー 
 びっくりマークでたねw 

514
 >>512 goroh_kun 
 いけてます。 
 $ adb reboot recovery 
 後に、 
 $ adb shell 
 は ok でした。 

516
 >>509 自己レス 
 誤:タスクマネージャ 
 正:デバイスマネージャ 

517
 >>512 
 すいません。 
 DIAG改変版インストールでOKでした。 

518
 >>509 
 > /dev/block/mtdblock5 /system yaffs2 rw 0 0 
 
 これって、/system を rw で書き込みマウントってこと? 
 recovery とか、boot とかも、rw マウント出来るの? 
 
 recovery の default.prop も書き換えが出来るし、 
 どのパーティションのバックアップや、リストアも出来るってこと? 
 
 あとは、電源ONから、何らかの操作で、リカバリーを立ち上げることが出来たら、 
 is01が、我々の物になるってこと? 

519
 >>511 すごい。ソースは読むものだ!よく、抜け穴見つけるものです!(うなってる 

520
 >>518 
 基本すでに丸裸では? 

521
 >>520 
 丸裸ですね。gorou_kun 天才。 
 
 電源ONから直接 recovery を立ち上げる方法があると、 
 system や boot が壊れても、 
 リストア出来るので、無敵。 


■本番

522
 さて、ここからが本番 
 
 recoveryを修正します。 
 recoveryのイメージを抜きます 
 
 dd if=/dev/mtd2 of=/path/to/recovery.bin bs=131072 count=10000 
 抜いたrecoveryのイメージをバイナリエディタで開き、 
 ro.secure=1をro.secure=0に書き換えます。 
 また、persist.service.adb.enable=0になっているところを1にします。 
 
 続いて、書き込み(msm_nand_exso)をinsmodする必要があります。 
 flash_image recovery_wr /path/to/recovery_mod.bin 
 
 で、再起動をかけてadbで接続した際にプロンプトが#になるか 
 見てみてみてもらえますか? 
 
 よろしくお願いしますっ! 

523
 一応、念のために確認ですが、adbの機能は全部使えて、 
 どのパーティションも書き込みマウント出来るんですよね? 
 今までのことがあるから、疑っちゃうw 

524
 recovery領域が壊れてしまっても、普通の領域でブートできるので 
 まったく問題ないことを保障します。bootloaderのコードは全部読みましたが、 
 recovery領域が正常かどうかとう、そういったチェックは入ってませんでした^^ 

525
 >>522 なるほど、まだ先があるんですね。(お祈り・・・・ 

526
 どなたか 
 kernelモジュールの作成or修正・動作確認お願いs増す。 
 
 (1)モジュールの初期化時に物理アドレスの0番地からをアクセスできるようにする 
 char* spladdr; 
 spladdr = ioremap(0, 0x30000); 
 
 (2)物理アドレスの0x145cをNOPにする。 
 (unsigned*)(&spladdr[0x145c]) = 0xe1a00000 
 
 以上のことをやると、ram上のsplにて、fastbootが使えるようになる可能性が高いです。 
 
 reboot fastboot 
 
 動いたらいいなぁ・・ 

533
 先ほどのspl領域のパッチのほうは自分で起こしてみました。
 
 http://hotfile.com/dl/86595851/7a2666a/spl_patch.zip.html
 
 modules_enablerにより、insmodできる状態にした後で、
 
 insmod spl_patch.ko
 cat /proc/spl_patch
 
 とやった後、
 
 reboot bootloader
 または
 reboot fastboot
 
 とやるとどうなるでしょうか。
 メモリ書き換えるだけなので、壊れる心配はないです。
 よろしくお願いします。

534
 どなたか、
 
 dd if=/dev/mtd/mtd2 of=/data/mtd2.bin bs=131072 count=10000
 
 として出来上がったmtd.binをいただけますか?
 よろしくお願いします

536
 >>533
 modules_enabler動作環境で
 insmod spl_patch.ko
 cat /proc/spl_patch
 まではうまくいきましたが、
 残念ながら、
 reboot bootloader
 reboot fastboot
 双方とも、通常のAndroid起動です

538
 上で説明したパッチを当てましたので、
 書き込み後reboot recoveryでadb接続、root権限が
 取得できるか確認お願いできますか?
 
 http://hotfile.com/links/86604829/32b00e3/mtd2_patched.zip
 
 modules_enabler, msm_nand_exのモジュールをいれ、
 
 flash_image mtd2.bin recovery_wr /path/to/recovery_mod.bin
 
 を実行後、
 reboot recovery
 です。

540
 bootloader部分のバイナリと、逆アセンブル結果、
 および元になると思われるブートローダのソースコードを
 upしておきました。
 
 先ほどのspl_patchはboot_from_nand変数を代入している
 箇所へのパッチだったのですが、分かる方はほかの場所の
 パッチも試してみるとよいと思います。
 
541
 urlはこちらになります
 
 http://hotfile.com/dl/86605754/09168f6/is01_bootloader.zip.html
 

542
 >538
 mtd02からのダンプでは先頭部分に余分なデータが付加されているので、
 flash_imageは瞬時にプロンプトが帰ってきてしまいました。
 mtd.binの先頭から0x40800からANDROIDという文字列が入っている部分
 以降が他機種でのrecovery.imgの形式に似ていたので、先頭部分切り取って
 テストすると、とりあえずflash_image自体は書き込んでくれたようです。
 ・・・が、reboot recovery でrecovery起動しなくなりました。
 
 通常のAndroid起動は問題ないようなので、実害はありませんが

544
 >>542
 すみません、検証有難うございます。
 もとのオリジナルのrecoveryを書くとどうなりますか?

547
 >>544
 すみません、542の前言撤回です。
 オリジナルのリカバリー、mtdからのダンプのままでflash_imageできました。
 recovery 起動もOKです。
 
 で再度、Binary Patch適用後のダンプをflash_imageしたら今度は焼けました。
 タイミングの問題かなぁ?
 flash_imageが瞬時に帰ってくるときと、焼いているかのように少しだけ
 時間が掛かるときがあります。
 時間がかかって焼けたのではというときにパッチをあてた状態でreboot recovery
 したら、adb shell で # プロンプトが表示されました。
 万歳!

548
 >>547
 万歳!^^

566
 >>547
 flash_image がうまくいったりいかなかったりする理由が、 
 flash_imageのソースを読んでみてわかりました。 
 MTDとイメージの先頭2048バイトを読んで内容が同じならflashしないロジックが入っています。 
 なのでこの部分を回避したflash_imageを作成するか、イメージファイルの 
 先頭2048バイトを解析して変更するなどの手段が必要なようです。 
 私が旨くいったのは、とりあえず一度変に先頭カットしたものをflashしたため 
 2度目に元のファイルに戻したときにこの部分のチェックを通過したためです。 
 その後に、ro.secure=0のパッチ適用が旨くいったのも、 
 オリジナルのrecoveryイメージは自分のIS01で取得したものを使用し、 
 ro.secure適用のものはgoroh_kunさんのを利用したため、 
 ヘッダー部分も取得時の状態によって変化していたのだと推測できます。 
 
 参考になりますか? 

タグ:

+ タグ編集
  • タグ:

このサイトはreCAPTCHAによって保護されており、Googleの プライバシーポリシー利用規約 が適用されます。

最終更新:2010年12月06日 15:56
ツールボックス

下から選んでください:

新しいページを作成する
ヘルプ / FAQ もご覧ください。