boot,recovery, > systemを自由に書き換える

「boot,recovery,/systemを自由に書き換える」の編集履歴(バックアップ)一覧に戻る

boot,recovery,/systemを自由に書き換える - (2010/12/01 (水) 12:16:13) のソース

boot, recovery, /systemを自由に書き換えられるようになりました。 
goroh_kun、ありがとう!!!!

local.prop等インストーラ
http://hotfile.com/dl/86086609/df7750d/bootkit.zip.html 
カーネルモジュールとrilのプラグインのソースコード
http://hotfile.com/dl/86092190/3aa9b5c/drivers_source.zip.html

>>317
>  自動起動仕込むところを大体見つけました。 
>  どなたか協力お願いします。 
>  
>  /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に引き渡すようにします。 
>  
>  これでいけるのではないかと思っているのですが、やるよって方は 
>  いらっしゃいますか? 

>>318
>  おそらく、上の方法であれば、 
>  local.propの中に 
>  
>  ctl.start=qcom-sh 
>  と入れておけば、サービスの起動も可能だと思います。 
>  /init.qcom.shの内容をlibril-wrapper.soにて上書きし、その後 
>  このシェルを起動することも可能だと思います。 
>  
>  さらには、module_disabledを書き込むよりも前で起動されることが 
>  分かっていますので、この段階で任意のkernelモジュールが読み込めるのではないかと 
>  思っています。 

>>319
>  上の動作をするrild用のプラグインをビルドしました。 
>  
>  これで、起動時に任意のkernel moduleをinsmodできます。 
>  
>  http://hotfile.com/dl/86056401/b7bb5a2/libril-wrapper.zip.html 

>>321
>  起動時にinsmodスクリプトに入れることで、 
>  boot, recovery, /systemを自由に書き換えられるようになりました。 
>  
>  http://hotfile.com/dl/86060655/63e2abf/msm_nand_ex.zip.html 
>  
>  分かる人だけ使ってくださいね。 
>  
>  (1) /data/local.propを作成 
>  中身は、 
>  cat /data/local.prop 
>  rild.libpath=/path/to/libril-wrapper.so 
>  rild.wrapper.cmd=/path/to/autoexec.sh 
>  rild.libpath2=/system/lib/libril-qc-1.so 
>  
>  (2)/path/to/libril-wrapper.soを配置 
>  
>  (3)/path/to/autoexec.shを作成、中身は 
>  insmod /path/to/msm_nand_ex.ko 
>  ほかにもやらせたいことを書きます。 
>  スクリプトの最後にrildのプラグインを設定しなおします。 
>  setprop rild.libpath `getprop rild.libpath2` 
>  
>  分かる人だけやってください。あとは起動のこの仕組みを利用して、 
>  いろいろなバージョンのandroidを起動できるようにしてみましょう。 
>  boot.imgの書き換えは慎重にやってくださいね。 
>  私のほうは、recovery領域を触って、いろいろ検証してみます。 
 
>>322
>  これで、とりあえず私の目的は達成できたので書き込み頻度は 
>  少なくなるかも知れないです。チェックはしてますので、何かあったら 
>  書き込んでください。 
>  ではでは 

>>327
>  あとは、recovery の、adbd の立ち上がりを禁止してたのを、許可するように、 
>  0 -> 1 の編集したら、recovery からadb経由で何でも書き換え出来るようになる? 
>  
>  まだ、recovery を電源ONから、直接立ち上げるキー操作とかは不明なんだよね? 

>>331
>  >>327 
>  そうですね、まずはそこからになるかと。 
>  ubiデバイス側から書くのがよいのか、mtdblock(またはmtd)から書くのがいいのか調べてみないとですが。。 

>>342
>  local.prop等インストーラを作ってみたのでお試しください。 
>  できれば、ワンクリック版に組み入れてもらえると・・ 
>  
>  http://hotfile.com/dl/86086609/df7750d/bootkit.zip.html 

>>352
>  カーネルモジュールとrilのプラグインのソースコードを公開しておきます。 
>  http://hotfile.com/dl/86092190/3aa9b5c/drivers_source.zip.html 

>>353
>  systemを書き換えるには、書き込み可能なsystemとして 
>  mtd10で認識しているのでマウントしてみてください。 
>  その際、安全のため/systemはアンマウントしておいたほうがよいかと思います。 

>>365
>  kernel書き換え試してみるのはとりあえず、自己リスクで。 
>  /system書き換える場合も、androidを起動しなくても 
>  adbがつながるようにしてからやるのが安心だと思います。 
>  
>  現状androidが起動しない&adbでつながらないときに元に戻す 
>  手段がないので危険だと思います。 
>  現在bootloaderにそういったモードがないか確認中です。 
>  自分の場合はandroid起動しなくてもadbでつなげられるのですが 
>  qxdmを有効にした状態ですので、もしadb認識してない人は 
>  qxdmを有効にしてみてください。 
>  
>  echo 1 > /sys/devices/platform/msm_hsusb_periphera/qxdm_enable 

[[ブートローダー]]へ続く。
ツールボックス

下から選んでください:

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