スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

SH-12C 新・root取得方法

はじめに

以前、SH-12Cのroot取得方法をまとめたのだが、
準備編実行編
最近はSHbreakのおかげでnandunlockまで出来ちゃうし、MiyabiLSMの解除もカスタムROMを焼くことにより出来てしまうので、過去の記事はそんなに見る必要も無くなってきたと思う・・・w

しかも、452さんが作ってくれたROMには、詳しい説明が書かれているreadmeファイルも付いているので、知識のない自分がわざわざ恥を晒す事もないのだが、なにせやることが無いので・・・www
最近のroot取得からrom焼きまでサラっと手順を踏んで書いてみたいと思う。

追記履歴:
※コメントによりご指摘頂き、何箇所か修正しました。ありがとうございました。
※最後の方、boot領域にカスタムROMを焼く所の、/dataパーティションの指定を、/mnt/dataに修正。ごめんなさい^^;
※自分でboot_rescue0910を/data/local/にコピーしておきながら、焼く時はSDから焼くって・・・www修正^^;
※コメントもらって気付いたけど、最初のrecoveryにflash_imageの所は、
 ./flash_imageじゃないとダメな気がしたので、修正w
※Superuserのインストールを書き忘れてたので追加w
※boot.imgとrecovery.imgのバックアップにて、正しくバックアップ出来ているか検証する方法を追加。
※recovery領域に通常のrecovery.imgを焼き直した時に、正常に焼き治ってるかどうかを確認する方法を追加。
※USBデバッグにチェックするのを書いてなかったので追加。コメント頂いて気づきましたwありがとうございます。


前準備

1.adb環境を整える
とりあえず、絶対必要ってわけではないのだけれど、あったほうが絶対便利なので、
PCには、adb接続環境を整えておく事をお勧めする。
方法は、
WindowsにUbuntuでadb環境
とかを参照にして導入してみる・・・
「Ubuntuとか知らないし、Windowsにadb環境入れれば良いじゃん!」って人が大多数だとおもうので、
そう思う人は、Windowsにadb環境導入とかでググッテクダサイw
下記コマンドも、全てWindowsユーザー向けに、コマンドプロンプトによりadb接続を行なう例を書いているのだけど、自分はWindows自体使ってないので許してくださいw
Windowsで検証してないので、おかしかったら、これまたごめんなさいwww

2.SHbreak4をインストール
これがないと始まらないので、とりあえず最初に入れておく。
でも、まだ起動はしないほうがいい。 携帯端末の動作がおかしくなってしまう可能性もあるから、まだ起動は我慢。

3.カスタムROMを入手or作成
これに関しては、自分の好きな方法で良いと思うけど、
ここでは452さんが作ってくれたROMを使うことにする。
何故かというと、バックアップが簡単だし、レスキューモードが優れているから。
sh12c_boot_rescue0910.zip (直リンクごめんなさい・・・)

4.必要ファイルを携帯端末に移動(コピー)
ここで実行予定の、sh12c_boot_rescue0910の必要ファイルを端末にコピーしていく。
ここからadb接続をしてコマンドを打っていくのだけど、USBデバッグってのを有効にしないといけない
SH-12Cの設定>アプリケーション設定>開発と開いていき、”USBデバッグ”って所にチェックを入れる。
そうするとadb接続により、コマンド操作でSH-12Cをいじれるようになる。
PCにadb環境が整っているなら
PCのC:\Android\sh12c_boot_rescue0910と言うディレクトリに解凍されているとして、ターミナルorコマンドプロンプトにて

cd C:\Android\sh12c_boot_rescue0910
adb push boot_rescue0910.img /data/local
cd 初回導入用
adb shell mkdir /data/local/bin/
adb push flash_image /data/local/bin/
adb shell chmod 755 /data/local/bin/flash_image
adb push Superuser2.3.6.3¥su /data/local/bin/

こんなところかな・・・。

それから、suをどこに置きたいかによって変わるんだけど、
suを /sbinに置きたいって人は

adb push autoexec.sh /data/local/bin/

も上に追加して打ち込む必要がある。(autoexec.shもコピーするって事)
suを/system/binに入れたい人は(自分はこっちの方がおすすめ)、root取ってから入れるのでautoexec.shのコピーは省いて良い、と言うか、入れないほうがいいかもw


準備はここまでやればOK。


実行

1.携帯端末の再起動
これはやっておいたほうがいい。
何故かというと、焼き時にメモリ足りなくなる可能性があるし、SHbreak4の動作の副作用をなるべく起こさないようにしたいから。
あと、再起動後は、端末が完璧に立ち上がるまで放置しておくこと。
これもSHbreak4の副作用を起こさないため。
とにかく、再起動して端末が完璧に立ち上がるまで放置する。
再起動後ホーム画面が出てきても、内部でアプリがいろいろ起動をかけているので、再起動後はホーム画面が見えてから5分くらい放置しておいたほうがいいかな・・・。
そこまでする必要は無いと思うけど、念には念を入れて。。。w

2.SHbreak4の起動・1回目
この起動により、SUIDを壊しroot権限を取得している模様。
プロセスを一度終了させる必要があるため、SHbreak4を終了させる。
端末の戻るボタンでも大丈夫だった。
ここで、終了してから30秒ほど待つ。ちゃんと待つ。
プロセスをちゃんと終了させるためなのかな?。。。w
3.SHbreak4の起動・2回目
この起動はnandunlockするための起動。
チェックボックスが2個チェック済みで見えると思うけど、そのままでOK。
その状態で”break”ボタンを押す。
これでnandlockも解除されているはず。
logがズラッと出てきて、最後にsucceeded(?)みたいに出てくれば成功している。

サービス等を止めたりしたいだけの人は、ここでチャチャッと作業を終わらせ、チャチャッと再起動をかけた方が良い。
今回のSHbreak4の一時rootedは、そのまま使用はしちゃダメ。危険。
まあ、前バージョンもダメなのはダメだったけど。。。ね

4.boot/recoveryイメージのバックアップ
説明の必要は無いと思うけど、バックアップは確実に取っておくこと。
adb shellに入り、バックアップを取っていく。

au
mkdir -p /mnt/sdcard/mtdbackup/
cat /dev/mtd/mtd0ro > /mnt/sdcard/mtdbackup/boot.img
cat /dev/mtd/mtd3ro > /mnt/sdcard/mtdbackup/recovery.img
# 念の為、別の方法でもバックアップ
dd if=/dev/mtd/mtd0ro of=/mnt/sdcard/mtdbackup/boot_dd.bin
dd if=/dev/mtd/mtd3ro of=/mnt/sdcard/mtdbackup/recovery_dd.bin
# 序に他の非yaffs2パーティションもバックアップ
cat /dev/mtd/mtd2 > /mnt/sdcard/mtdbackup/mtd2.img
cat /dev/mtd/mtd4 > /mnt/sdcard/mtdbackup/mtd4.img
cat /dev/mtd/mtd7 > /mnt/sdcard/mtdbackup/mtd7.img
exit
exit

452さんのreadmeからコピペです。ごめんなさいm(_ _)m

これでSDcard内にバックアップは取れた。

バックアップしたboot.imgとrecovery.imgが正常かどうかを検証する。

mkdir C:\Android\backup
cd C:\Android\backup
adb pull /mnt/sdcard/mtdbackup/boot.img
adb pull /mnt/sdcard/mtdbackup/recovery.img
adb pull /mnt/sdcard/mtdbackup/boot_dd.bin
adb pull /mnt/sdcard/mtdbackup/recovery_dd.bin
fc /b boot.img boot_dd.bin
fc /b recovery.img recovery_dd.bin

この最後のfcと言うコマンドで相違点を確認する。
もし、相違点があると判断されてしまったら、バックアップが失敗しているので、相違点が無くなるまでバックアップ・検証を続ける。
まあ、バックアップ失敗なんて無いと思うけど、boot.imgとrecovery.imgは確実に正常なバックアップをしたいからね・・・
他のバックアップファイルをPCに移動はまた後で・・・。(各自好きな時に^^;)


5.いよいよROM焼き
boot領域に焼くか、recovery領域に焼くかは自由だけど、まずはrecovery領域に焼き、動作テストをしてからboot領域に焼くってのがおすすめ。
そのROMが既に動作検証済みで、動作に問題がないとわかっているなら、最初からboot領域に焼いちゃったほうが手間が少なくていいと思う。
なんで、boot領域に焼くのがおすすめかと言うと、
文鎮からの復帰
あたりを参考にしてください。

とりあえず、recovery領域に焼く方法を書く。
それで、後からboot領域に焼く方法を書こうと思う。
adb shellに再び入り、

su
cd /data/local/bin/
./flash_image recovery /data/local/boot_rescue0910.img

このコマンドを打って、out of memoryとかエラーが出なければ正常に焼けている。
もしなにかエラーら出てたら、もう一度flash_imageしなおしてみる。
out of memoryのエラーが出ずに、なにも無かったように再び#が出てきたら成功。
exitを2回とかでadb shellを抜けておく。


6.recovery領域からの起動
recovery領域に目的のbootイメージを焼いたわけだから、recovery領域から起動をかける。

adb reboot recovery



7.rescueモードに入る
上のコマンドにより、再起動がかかりdocomoのロゴが出てくる。
recovery領域にちゃんと焼けていれば、ちょっとしたら、menu、home、backボタンが薄く点滅を始める。
点滅を始めたら、homeボタンを押す。
すると、点滅が早くなり、それがレスキューモードに入ったという合図。


8.バックアップを取っていないパーティションのバックアップ
上でバックアップ取れる部分は取ったけど、yaffs2パーティション部分のバックアップはまるで取っていないので、ここでバックアップを取っておく。
レスキューモードに入れていたら、adb接続が可能になっているので、adb shellに入り、

su
mount_sd
mkdir -p /mnt/sdcard/mtdbackup
dump_image_oob persist /mnt/sdcard/mtdbackup/mtd1_persist_oob010106.img
dump_image_oob system /mnt/sdcard/mtdbackup/mtd5_system_oob010106.img
dump_image_oob cache /mnt/sdcard/mtdbackup/mtd6_cache_oob010106.img
dump_image_oob battlog /mnt/sdcard/mtdbackup/mtd8_battlog_oob010106.img
dump_image_oob calllog /mnt/sdcard/mtdbackup/mtd9_calllog_oob010106.img
dump_image_oob ldb /mnt/sdcard/mtdbackup/mtd10_ldb_oob010106.img
dump_image_oob userdata /mnt/sdcard/mtdbackup/mtd11_data_oob010106.img

これで一応oobを含めたバックアップがSDに取れているのだけど、心配なら続けてtar.gz(linuxOSではtar.gzでのバックアップが主流(?のはずw))でバックアップを取っておくといいと思う。。。けど、
ここでは面倒なので割愛w
どうしても取りたい場合は、sh12c_rescue_0910にあるreadmeに詳しく載ってるので、そちらを参考にしてください。
Androidでのバックアップの取り方
も少しは手助けになると思うので参考にどうぞ。

一応SDをumountしておく。

umount /mnt/sdcard



9.suの設置(/system/bin/に置きたい人用)
/sbinにsuを置きたい人は既に前準備にてsuを置く準備は整っているので、この項目は省略する。
/systemをmountしてから、rmでremountして、/system/binにsuを置く。
先に、/data/local/binにsuをコピーしたので、/dataもmountしてそこからコピー。
権限等の変更もする。
そしてこの項目が終わったら、今の所レスキューモードに用はなくなるので、抜けてAndroid起動。
最初にごちゃごちゃ説明しちゃったけど、次のコマンドを打っていけばよしw
最初のsuは、上のバックアップの項目に続けて打つなら、すでにsuなので打つ必要はなし。

su
mount_system
mount -o remount,rw /mnt/system/
mount_data
cp /mnt/data/local/bin/su /mnt/system/bin/su
chown 0.0 /mnt/system/bin/su
chmod 6755 /mnt/system/bin/su
cd /
umount /mnt/system/
umount /mnt/data/
rm /rescue

ここまで打つと、レスキューモードを抜けてAndroidが起動する。


10.バックアップファイルをPC等に移動する
上の作業を全てこなしてきた人は、/mnt/sdcard/mtdbackup/って言うフォルダに、
(SDカード内の、mtdbackupって言うフォルダね。)
必要なバックアップは全て取ってあるはずだから、好きな方法によりそれらを保存しておく。 方法は割愛w
adbでpullするとか、PCにSDカード挿してコピーしておくとか、何でも良いと思う。

11.アプリSuperuserをインストール、起動する
アプリのSuperuserをインストールするのを忘れてた・・・w
インストールはコマンドプロンプトにより、次の手順で。

cd C:\Android\sh12c_boot_rescue0910\Superuser2.3.6.3
adb install Superuser.apk

これでSH-12CにSuperuserがインストールされているはず。

adb でインストールじゃなくても、

cd C:\Android\sh12c_boot_rescue0910\Superuser2.3.6.3
adb push Superuser.apk /mnt/sdcard/

とかしておいて(別にSDカードに移動する方法はどうでもよい)、そのapkをタップしてインストールしても良い。

初回は起動しないといけなかったような・・・気が・・・するから一応起動してみるw

12.作業は終了
recovery領域に焼き、そこから起動したことで、普通にroot権限が必要なアプリ等は使えるようになっているはず。
なので、recovery領域でいいやって人は、動作確認をひと通りしたら、ここで作業終了。
でも、recovery領域にカスタムカーネルブートイメージを焼いても意味がないってことを覚えておいてください
文鎮からの復帰を参照。

なので、これから、boot領域にsh12c_boot_rescue0910を焼いてrecovery領域にバックアップしてあるrecovery.imgを焼き直す作業をする。

12.boot領域にカスタムROMを焼き、recovery領域は元に戻す
上から順番に作業をしてきた事前提で話を進める。
必要ファイルが入っているディレクトリとかね。
ディレクトリを自分好きに変えている人は読み替えて作業する。

レスキューモードに入る。

adb reboot recovery
#再起動がかかり、docomoロゴが出てきて、menu,home,backキーが点滅を始める。
#homeキーを押す→点滅が早くなる→adb接続OK


レスキューモードに入り、adb shell出来たら、次のコマンドにより焼きやき作業。

su
mount_sd
mount_data
flash_image recovery /mnt/sdcard/mtdbackup/recovery.img
flash_image boot /mnt/data/local/boot_rescue0910.img

flash_imageに何のエラーも出てなかったら、焼き焼き終了。
何らかのエラーが出ちゃったら、エラーが無くなるまでflash_imageしなおす事。
recovery領域にflash_imageでエラーが出てる分には後で修正可能だけど、boot領域にflash_imageでエラーが出たまま再起動をかけると、文鎮確定。。。
なので、エラーが出てないことは重要。

通常起動に戻る。
上のコマンドに続けて、

#adb shellを抜ける
exit
exit
#boot領域から再起動をかける
adb reboot

これで通常起動されて、常用root&レスキュモード可能なSH-12Cの出来上がり。
ちゃんとboot領域にboot_rescue0910.imgが焼かれていないと、トラブルが起きた時にレスキューモードに入れなくなるので、心配な人はもう一度普通に電源ボタン長押しより再起動をかけてみて、docomoロゴでボタンが点滅し、レスキューモードに入れることを確認してみるといいと思う。

ここまでやったら、メーカーアップデートをしたりしない限り、文鎮になることはないはず。

ここでrecovery領域を元に戻せているかどうかの確認方法を・・・。
reboot recoveryしてみて、ドロイド君がビックリマークと共に出てきて、そこから何も起こらなかったら正常に戻せています。
SH-12Cのrecovery.imgはリカバリ時(初期化時)に使用するイメージなだけで、通常起動はしないものなので。
rootスレでも結構びっくりされる方がいましたからね。

つ、疲れた・・・www
他にも色々書こうと思ったけど、疲れたのでこの辺で。。。

他になにか気付いたら、追記で後から書き足そうと思う・・・^^
スポンサーサイト

SH-12C 01.01.06 root取得

ありがとうございます!&01.01.06の皆様おめでとうございます。

SHbreakが最新のver4になり、SH-12Cに対応してくれました><

ほんとに、感謝感謝です;;

ずっとモヤモヤしてたけど、ほんとにスッキリ晴れた気分です。


明日は朝早くから仕事なので、超簡単にと言うか、作者様の説明通りに方法を書きます。

あたり前のことながら、自己責任で。

1.SH-12CにSHbreak4をインストール
2.WiFiがONの場合はOFFにする。
3.SHbreak4を起動し、何もせずに終了ボタンで一度終了する。(端末の戻るボタンでもOK)
4.30秒ほど待つ・・・・・・・。(ここでちゃんと待たないと失敗する恐れが)
5.再びSHbreak4を起動。
6.breakボタンを押す!(チェックはそのままでOK)
7.PCに接続 & adb shellに入り、"au" で # になれる。(suでは無いので注意)
8.おめでとうございます。nandもunlockされているので、焼き放題です。


以上!

一回で簡単にと言うか、失敗なしでroot取得&rom焼きまで出来て、

今までのモヤモヤは何だったのだろうか・・・と言う感想www

ホントに、Marijuanaさんには感謝です。ありがとうございます!


みなさん、快適なroot生活をお送りください^^





追記:
rom焼きに関しては、

SH-12C root取り方2 実行編

SH-12C 新・root取得方法

あたりを参考にしてください。

SHbreakのroot取得方法が変わっただけで、他は同じ方法でいけます。


ただし、SHbreak4はnandunlockまでしてくれているので、上の記事のnandunlockとかはしなくてOKです。




ちょっと記事的に古い気がするので、今度、最新のrom焼き方法とかまとめようかと思うので、

古い記事を読んで自信がない人はちょっと待っててください。

必要ないかも知れないけど、ロックシステムの解除とか、既に必要ないものも多いので、書き直した方がいいかと…(笑)

SH-12C 文鎮化からの復帰

何度か、SH-12Cの文鎮化より復帰は?と言うコメントを頂いたので、少しだけどその事について書いてみたいと思う。

文鎮化しないための条件とか


root取得記事にもほんの少し触れているんだけど、
文鎮SH-12Cは、boot領域にレスキュー(リカバリ)可能なbootイメージを焼いていないと、復旧はほぼ不可能と言っていい。
※ほぼと書いたのは、過去にバッテリー抜いたりしてたら治ったとかスレにあったのでw まあ、それは正しくは文鎮化していなかったと言う事なんだろうけど、そんな事もあるかも知れないってことで。。。w

この”boot領域に”って言うのが重要で、なぜrecovery領域に焼いている状況で文鎮化した時に復旧不可能かと言うと、、、

普通の再起動と言うのは基本的にboot領域から行われるもので、recovery領域から起動したい場合は、コマンドでreboot recoveryしないといけない(アプリでrecoveryから起動ってのも出来るけど結局は同じ事)。
又、SH-12Cは、ボタンコンボ(ボタンの同時押し)起動とかでrecovery領域からの起動は出来ない。
バッテリーを引っこ抜き再起動した場合もboot領域からの起動になり、それでも起動しない場合は、もうrecovery領域からの起動は出来ない。
つまり、boot領域からの起動に失敗すると、もうrecovery領域からの起動が不可能って事になるので、文鎮化確定。
よく、「boot領域に焼いた方が、文鎮のリスクが少ない」って見かけるのはその為。

って事。

ボタンコンボ等の方法でrecovery領域からの起動が不可能な機種では、rooted可能かつレスキュー(リカバリ)可能なbootイメージをboot領域に焼かないと意味がないと言う事なのです。

まとめると。。。。

SH-12Cでのrootedは
●rooted可能かつレスキュー(リカバリ)可能なbootイメージを、boot領域に焼かないと意味がない(断言)。
●recovery領域に焼くのは、テストの為だけで、テストが終わったら元のrecoveryイメージを焼き直す。
●出来る事なら、oobパッチの適用されたbootイメージを使い、各パーティションのバックアップは取っておく。



こうは言ったものの、上の方法でも文鎮化してしまう可能性が全くないっては言い切れない。
boot領域にカスタムイメージを焼くってことは、その行為自体失敗してしまうと即文鎮確定になる。
やはり、自己責任&しっかり理解をした上で行わなければいけないってことですね。


文鎮化してしまう原因とか


文鎮化してしまったと言っても、原因がそれぞれ違うわけで、その原因ってのを少し羅列してみたいと思う。
●起動に必要なsystemが壊れた
●止めてはいけないサービスを止めてしまった
●recovery領域にカスタムイメージを焼いていて、初期化操作をしてしまった
●boot領域へのflash(焼く行為)に失敗した
●いろいろ弄った状態でアップデートしてしまった。

・・・・これくらいしか思いつかないwww
flashの失敗は有無を言わさず文鎮確定。
アップデートも文鎮確定。
その他は条件によっては復旧可能となる
recovery領域にカスタムイメージを焼いていて初期化操作も文鎮確定だった。

その条件は、上でも言っている、boot領域にレスキュー(リカバリ)可能なイメージを焼いていること。


文鎮化からの復旧

簡単に復旧方法を書いてみる。
何度も言うが、boot領域にレスキュー可能なイメージを焼いていることが条件になる。
現在入手出来るrooted可能でレスキュー(リカバリ)可能なbootイメージはというと、

●goroh_kunが作ってくれた、起動時にadb接続可能なbootイメージ
●2chのSH-12Croot2スレで452さんが作ってくれたレスキューモード可能なイメージ

このどちらかをboot領域に焼いているってこと前提。
以下、レスキューモード(リカバリモード)に入っての作業。

1,起動時に必要なsystemが壊れ文鎮化した


復旧方法:adb接続にて、systemをマウントし、バックアップしてあるsystemと入れ替える。

これは、当然バックアップが無ければ復旧はむずかしい。
しかし、どのファイルを弄ったかがわかっていれば、そのファイルを正しく修正すればいい。
systemファイル弄るのに、バックアップを取らない人はいないと思うので、ここいら辺は問題ないはず。


2,止めてはいけないサービスを止めてしまった

復旧方法:adb接続にて、サービスを復旧する。

どのサービスを止めてはいけないのかは、ググればスグ見つかる。
ワンセグとか、SIM Toolkitとか。。。

コマンドでの復旧になるけど、これもすぐ見つかるはず。


3,recovery領域にbootイメージを焼いた状態で初期化してしまった


復旧方法:adb接続にて、/cache/recoveryを削除

これでいけた様な気がするw
要は、初期化すると、/cache/recoveryに初期化しろと言う情報が書かれ、recoveryからの再起動がかかるんだけど、recovery領域にはbootイメージが焼かれているので、再びrecoveryから起動しろと命令が出て、ループして文鎮化って事なので、
そいつを消してやればいいって事。
まあ、やってみたことは無いので何とも言えないけど、復旧できるはず。


文鎮確定

boot領域にカスタムカーネルイメージ、recovery領域に正規recoveryイメージで初期化作業をしてみたら、
レスキューモードに移行する前にリカバリ作業が始まってしまった。
ってことは、initよりも/cache/recoveryの方が優先されるってことで、レスキューモードには入れなくなってしまうってこと。
ってことは、これまた文鎮確定ってことなんだ・・・。
勉強になった。^^:

<終わりに>
スレでも以前はたまに見かけたんだけど、
boot領域、bootイメージ、recovery領域、recoveryモード、recoveryイメージ、recovery領域からの起動
これらを混同している人が居るみたい。
簡単に説明すると(説明が適当すぎてごめんなさいw)、

boot領域:起動する時に必要な物が入っているパーティション
bootイメージ:起動情報等が書かれたイメージ
recovery領域:初期化に必要な物が入っているパーティション
recoveryモード:goroh_kunや452さんが作ってくれたイメージからの起動でのみ入れる特殊なモード
recoveryイメージ:初期化に必要な情報等が書かれたイメージ
recovery領域からの起動:recovery領域にbootイメージを焼いている人がそこから起動すること。

recoveryモードとrecovery領域からの起動を混同する人がいたってことで、452さんはレスキューモードと名前を変えてくれた。

何度も言うようだけど、root取得していろいろ弄りたいのなら、絶対boot領域にレスキュー(リカバリ)モードに入れるbootイメージを焼いておくほうがいいってことです。
boot領域へのflash時のリスクより、recovery領域にflashして使用し続けるリスクのほうが全然高いって事を理解して、楽しいrooted生活を送りましょう^^

SH-12C CIFS

久しぶりの更新となるのだけど、どうにもSH-12Cでやること(弄ること)が無くなってきちゃって、普通に使っていて不便はさほど感じないのだけれど、なにかしたいぞ!と思ったのであった。。。w

それで思いついたのが、CIFS。

スマホは外に持って出る端末なので、ネットワークファイルをマウントするなんて必要はほとんど無いと思う。
しかし! やることがないから。。。w

現在452さんが作ってくれたカスタムカーネルイメージを使っているのだけど、CIFSは対応していない。
それなら、cifs.koを作ってやろう!

と言う訳で、あれこれ調べて、やっと動くモジュール達が出来たので、晒すことにした。

まずはじめに、CIFSとは何ぞ?

CIFSとは、ネットワーク上にある共有フォルダを、Windows以外でも使ってしまおうと言う物。
それを使うと、Android上にネットワーク共有フォルダをマウントできてしまう。
マウントするか、ネットワークファイルとして使うかの違いはと言うと。。。
マウントすると、あたかもそのファイル達が端末内にあるように見えるので、ネットワークファイルに対応していないアプリ等でそのファイルを開けたり使えたりする。
今のアプリはネットワークに対応しているものが多いので、使うメリットはそんなに無いんだけど、、、
でもでも、例えば1TBのHDDをマウントしたとすると、端末の容量が1TB以上になるって事!!!w
HDD内のあんな動画も、こんなマンガもSDに移動すること無く開くことが出来るってことだよね〜www

まあ、ネットワーク環境内に居ること前提になってしまうんだけど。。。ね。


説明がちょっと長くなったけど、とりあえずファイル。。。
SH-12C カーネルバージョン 2.6.35.7-perf  専用 CIFSに必要なファイル
cifs.zip

最近、4Sharedは、サインアップしないとDLできなくなってしまったみたい。
めんどくさいと思うけど我慢してください。。。ごめんなさいw

それでは、使い方。


導入

まず、ダウンロードしたzipファイルを好きな場所に解凍する。
ここでは、例として
C:\Android\cifs
と言う場所に解凍することにする。
その中には下の4つのファイルがあるはず。

slow-work.ko
cifs.ko
nls_utf8.ko
readme.txt

ここ迄いったら、SH-12CをPCに繋ぐ。
そしてコマンドプロンプト(又はターミナル)より、(#部分はコメントなので打つ必要なし)

#ディレクトリ移動
cd C:\Android\cifs

#必要モジュールを端末に移動
adb push slow-work.ko /data/local
adb push cifs.ko /data/local
adb push nls_utf8.ko /data/local

#adb shellに入りsuする
adb shell
su

#systemが読み取り専用なので、読み書き可能にする
mount -o rw,remount /system

#モジュールをコピーする(mvで移動でもOK)
cp /data/local/slow-work.ko /system/lib/modules
cp /data/local/cifs.ko /system/lib/modules
cp /data/local/nls_utf8.ko /system/lib/modules

#パーミッションを変更
chmod 644 /system/lib/modules/slow-work.ko
chmod 644 /system/lib/modules/cifs.ko
chmod 644 /system/lib/modules/nls_utf8.ko

#なんか嫌なので、読み取り専用に戻す
mount -o ro,remount /system

#マウントポイントを作る※1
#/mnt以下にフォルダを作りたいからrwでリマウントし、作成、roに戻す
mount -o rw,remount /
mkdir -p /mnt/cifs/ShareFolder   #※2
mount -o ro,remount /

#モジュールをロードする※3
insmod /system/lib/modules/slow-work.ko
insmod /system/lib/modules/cifs.ko
insmod /system/lib/modules/nls_utf8.ko

あとは、マウントするだけ。

※1 マウントポイントとは、マウント先のフォルダとなるもの。
   例えば、/mnt/cifs/ShareFolderにマウントしたら、そこにネットワーク上のファイル達が展開されて見える。

※2 例として ShareFolder と言う名前のフォルダを作ったけど、好きな名前でOK。
   ネットワーク共有フォルダ名が Documents だったら、 /mnt/cifs/Documents とかにする。
   複数の共有フォルダをマウントしたい場合は、その数ぶんフォルダを作成する。

※3 insmodの順番は、この通りにする事推奨。とりあえず、一番最初はslow-work.koで。



マウント

マウントする方法は、大きく分けて2つある。
①コマンドによるマウント
②アプリを使用してマウント


①コマンドによるマウント
コマンドプロンプト(又はターミナル)より、adb shellに入り、suした上で、

mount -t cifs -o username=USERNAME,password=USERPASS,iocharset=utf8 //192.168.*.*/ShareFolder /mnt/cifs/ShareFolder

改行は入らないで1行。
USERNAME、USERPASS、IPアドレス、ShareFolderの部分は自分の環境に合わせて。

②アプリを使用してマウント

GooglePlayからインストール出来るアプリ
CifsManager とか MountManager とかを使う。

この2つを使ってみたけど、一長一短。
MountManagerは、必要モジュールを登録して、自動でinsmodしてくれたりするんだけど、
読み込み専用のところにあるマウントポイントにはマウントできないし。。。
CifsManagerは、cifs.koしか登録できないので、自分でモジュールをinsmodしないといけない。

自分の中で面倒だけどこれでいいかな。。。と思った使用方法は、

MountManagerにモジュールを登録しておいて、自動でinsmodさせて、
マウント自体はCifsManagerでする

って事かな。

(再起動すると、モジュールのロード(insmod)を再びやらなければならない。)
(MountManagerでモジュールロードは1回やれば再起動しなければやらなくて良い)

アプリは英語だけど、調べる必要もなく簡単(だと思う)ので、自分で弄ってみてください(手抜きw)。



アンマウント

umount /mnt/cifs/ShareFolder

当然のことながら、ShareFolder部分は、マウントポイント名で。
アプリでアンマウントなら、コマンド打つ必要はなし。



ネットワーク環境から外れる時、もしくはWiFiを切るときには、アンマウントすることをおすすめする。
自分はそれでちょっとおかしな状態になったことがあるので。(アプリ側で)


後書き

上にもちょろっと書いたけど、再起動するとモジュールはもう一度ロードし直さなければならない(insmod)。

やっぱり、再起動のたびにコマンドで insmod とか、 mount / umount するのはかなり面倒なので、
アプリを使ってやってもらうのがおすすめ。。。

readmeには、autoexec.shにinsmod部分を書けばとか書いたけど、
上でちょろっと書いた方法(MountManagerでinsmodをやってもらい、CifsManagerでmount)を実行すれば、
モジュールロードは再起動後1回やればいい(自動化も出来る)ことだし、
わざわざautoexec.shに書く必要なんか無いなって思ってきたw

と言う訳で、今更cifs楽しんで〜^^w

SH-12C 01.01.06 root(取得できずw)

最近全然更新していないのは、新しくAndroidタブレットを購入して、そっちをいじくり回してるからなのですw
購入したのはAcer A700と言うタブレット。
Naoログさんと言うブログを参考に、root取得、CWM導入し、楽しく遊んでいる。。。
また時間があったら、A700についても書いてみようかと思ってるけど、ネタがあんまり無いのでどうかな。。。w

という訳で本題。
まず最初に断っておくけど、
rootが取れたわけではありません
rootが取れない!って話


2chのrootスレで、radi_shさんが、「道は残されているかも。shdisphookは使えない?」的な発言をされており、自分と嫁はお互いSH-12Cを所有しており、嫁はrootなんか取ってないから先日01.01.06にアプでしたばかりなので、嫁の使ってやってみようかな。。。と思い立ったのが発端で、色々試してみたけど結局はダメ;;

挑戦してみてわかったけど、今回のアプデは明らかに(と言うか多分w)libsdservice_jni.soに対処するものだった。。。

とりあえず、shdisphookは/synthesis/shdisp/のパーミッションが変わってて入れないので使えない。
なので別な手段を使ってlibsdservice_jni.soを/data/data/com.android.settings/lib/に作る方法を模索してたんだけど、ぜんぜん書き込み可能な所が見つからず、、、;;

radi_shさんから何度かアドバイスを頂き、/data/fotaが行けるのではないか!と期待していたんだけど、/data/fotaがない。。。w
へ?更新とかどうするんだべ??wと思って、どっかにfotaがあるはずと探してみると、/cache/fotaを発見。
たぶん、/cacheのパーミッションを変更して中身を見ることができたら、/cache/fotaは777パーミッションだと思うんだけど、見ることも開くこともできない。

libsdservice_jni.soを/data/data/com.android.settings/lib/に作成する方法は、
・起動時にsystemが勝手に作成する書き込み可能なファイルを探す
・そのファイルを削除かリネームして、/data/data/com.android.settings/lib/のシンボリックリンクをそのファイルの名前で作成する。
・再起動すると、/data/data/com.android.settings/lib/にlibsdservice_jni.soが作成される。
って流れ。
作成された/data/data/com.android.settings/lib/libsdservice_jni.soは書き込み可能なファイルのシンボリックリンクの元ファイルとしてあるので、当然書き込み可能で作成されている。
それで、/data/localに置いてあるlibsdservice_jni.soをcatしてやればOKって事になる。
それが出来れば、SDcardのアンマウントダイアログを出せば、/cacheとか/dataとかのパーミッションを変更出来るのだけど。。。

その肝心な書き込み可能なファイルがない!!!
と言うか、書き込み可能なディレクトリが見つからないw
見つかったのは、/data/fontsのみ。。。www
そんな所見つかっても、意味ないじゃん!

という訳で、今までの方法ではおそらくlibsdservice_jni.soの設置はできなくなってしまったので、SH機ICSでのlibsdservice_jni.soの設置方法みたいな新たな方法を神が作ってくれるのを待つしか無いのではないかと思う。;;

ここまで読んだ人はわかったと思うけど、、、SH-12C root2スレに最近無駄にだらだら書いていたのは自分でしたwww
お騒がせしましたm(_ _)m

プロフィール

tozionsdoor

Author:tozionsdoor
ただ書くだけ。スクショとか取るの面倒。貼るのも面倒w

検索フォーム
FC2カウンター
最新記事 5件
最新コメント
月別アーカイブ
カテゴリ
リンク
QRコード
QR
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。