**■とっかかり >>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 > おーー > びっくりマークでたねｗ >>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 > 万歳！＾＾ >
下から選んでください:
