■とっかかり
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さんのを利用したため、
ヘッダー部分も取得時の状態によって変化していたのだと推測できます。
参考になりますか?
最終更新:2010年12月06日 15:56