SHL24 MMCのハードウェアプロテクト

シャープもなにやらアレな感じですが・・・・。

あまり反応もないようなので、ニーズも大してないのかもしれませんが、一応、mmc_protect.koのロードに成功したので記事にしておきます。

これで、永久root取得に必要な事は全て確認出来た感じなので、SH-06Eと同様の状況に出来たといった所でしょうか。
とりあえずは、unclok_lsm_miyabiで、ｌｋｍのロードに対するソフトウエアプロテクトを回避するための情報。
パッチデータは他機種と同じなので省略してます、以下の情報を元に、unlock_lsm_miyabi.cを修正します、caseに対する追加も必要です、このとき、get_essential_addressでdevice.dbにSHL24のデータを追加した場合、caseの値となる、device_id(detect_device()の戻り値)はDBの中身を見ないと分かりません、以下のデータをDBに追加してしまえば(追加可能かどうかは確認していませんが)、caseの修正は不要だと思います。
ちなみに私の場合は、10000で登録されていました。

security_ops_shl24_01_00_01     0xc0a29278
n_security_ops_shl24_01_00_01   173

0xc031fa7c, 0xc031d22c
0xc031fa84, 0xc031d2c4
0xc03203b4, 0xc031d68c
0xc03201dc, 0xc031f68c
0xc031fc8c, 0xc031f694
0xc0320048, 0xc031f69c
0xc03200c8, 0xc031f784
0xc031fa8c, 0xc031f78c
0xc031fbf8, 0xc031f7a4
0xc031ffc8, 0xc031f7b4
0xc031fcf8, 0xc031f808
0xc031fb60, 0xc031dbd4
0xc032045c, 0xc031f998

unlock_module_patch_address_shl24_01_00_01  0xc01ca7e4

最近のLinuxのkernelはlkmを読み込むときに色々とチェックしているので、適当にmakeしたlkmモジュールではロードすることが出来ない様です。
これには参りました、結局、mmc_protectが利用している関数のチェックサムが必要となるため、kernelを曲がりなりにもmakeして、Module.symversを作成しなければなりません、make modulesでは作成される関数が足りないのでロード出来るモジュールを作成することが出来ません。
また、kernelのmakeが一筋縄では行かない、なんかエラーが出る・・・・・・・。
・kernelだけではだめで、hardwareとvendor辺りも展開しておく必要がある、symlinkが貼られている。
・miyabi_sandbox.lstがエラーになる、これは原因が分からず、makeの最初で,miyabi_sandbox.lstを作成する過程でなにやら壊してるようなんで、最初からあるmiyabi_sandbox.lstのwriteパーミッションを落として、書き込めないようにして、-iでエラーを無視して回避
・いくつかのヘッダーファイルが読めないので、ソースを修正、相対パスが1つに'<>'を'""'に変更が2つだったかな
・これは私だけかもしれないけど、scripts/mksysmapがエラーを吐くので、nmのパスを変数ではなく直接書いて逃げる
こんな感じで、Module.symversは無事に作成できました。
これで、mmc_protect.koをmakeしたところ、無事にmodversionのチェックは通りましたが、今度はなにやら未サポートのリロケーションタイプだとエラーを吐く、うーん、is12fの時にも出たなぁ・・・。
GCCのバージョンを確認するとなんと、一致していない、一応、GCCのバージョンは4.6で同じなのですが、SHL24のバージョンは、4.6.x-google 20120106でNDK(r9)のバージョンは4.6 20120106と微妙に違う。
結局、4.6.x-googleはgoogleにあるらしいことが判明、gitで落としてみるもバイナリーが64bit版しかない・・・・・。
　git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6
makeしていた環境は32bitなんで使えない、結局、VirtualBox上に64bitの環境を作成して凌ぎました。
ようやく、使えそうなmmc_protect.koが出来上がりました。

結果など。

127|shell@android:/data/local/tmp/tool $ ./install_backdoor
./install_backdoor
Attempt acdb exploit...
SHL24 (01.00.01) is not supported.
Attempt put_user exploit...
ioctl: Bad address
Attempt futex exploit...
futex_exploit: Server started
install_mmap: success
shell@android:/data/local/tmp/tool $ ./run_root_shell
./run_root_shell
shell@android:/data/local/tmp/tool # ./unlock_mmc_miyabi
./unlock_mmc_miyabi
/system/bin/sh: ./unlock_mmc_miyabi: not found
127|shell@android:/data/local/tmp/tool # ./unlock_lsm_miyabi
./unlock_lsm_miyabi
  13 functions are fixed.
 Patch Data:
  kernel module is enabled.
shell@android:/data/local/tmp/tool # insmod mmc_protect.ko
insmod mmc_protect.ko
shell@android:/data/local/tmp/tool # lsmod
lsmod
mmc_protect 13150 0 - Live 0x00000000 (O)
shexfat 54985 0 - Live 0x00000000 (PO)
shell@android:/data/local/tmp/tool # cat /sys/kernel/mmc_protect/status
cat /sys/kernel/mmc_protect/status
perm_wp = 0
temp_wp = 0
write_protect_group_size = 16384
mmc_ext_user_wp = 0x00
mmc_us_perm_wp_en = 0
mmc_us_perm_wp_dis = 0
mmc_us_pwr_wp_en = 0
mmc_us_pwr_wp_dis = 0
mmc_ext_hc_wp_grp_size = 2
mmc_ext_hc_erase_grp_size = 8
write_protect_group_size = 16384
0x00000000 (0x0155555555550055)
0x00080000 (0x5555555555555555)
0x00100000 (0x5555555555555555)
0x00180000 (0x5555555555555555)
0x00200000 (0x5555555555555555)
0x00280000 (0x5555555555555555)
0x00300000 (0x5555555555555555)
0x00380000 (0x5555555555555555)
0x00400000 (0x5555555555555500)
0x00480000 (0x0000000000000000)


0x01d00000 (0x0000000000100000)

コメント 12

shl23(01.00.07)でのハードウェアプロテクトの解除の方法をご存知でしたら教えていただけませんでしょうか
run_root_shellやunlock_lsm_miyabiは既に実行しています
by shl23 (2015-10-10 00:09) 

具体的に何をしようとされているのでしょう？
/systemをrwでマウントしたいのであれば、unlock_mmc_protectを実行すればrwマウントは可能になると思います。
そうではなく、ハードウエアプロテクトを解除してmmcを書き換えたいのであれば、この記事を参考にして、mmc_protect.koを作成しロードして解除したいパーティション名を/sys/kernel/mmc_protect/clearに送ってやれば解除できると思いますが、私は試したことはありません、なにせsharp機のプロテクトは色々とあるようなので・・・。
echo -n パーティション名 > /sys/kernel/mmc_protect/clear

by kim (2015-10-10 22:33) 

返信ありがとうございます。
自分は、shl23のsystemをrwでマウントさせたくてunlock_mmc_protectを使わせて頂いたのですが
Found mmc_protect_part! 7 partitions are fixed to readable. 1 partitions are fixed to writable
との表示があり、systemをrwでマウントさせようとすると、Read Only File systemと出てアンロック出来ませんでした。
そこで、今回教えて頂いたことから記事を参考にさせていただき、rwでリマウントできるよう頑張ります
by shl23 (2015-10-10 23:58) 

rwマウント出来ればよいのですね、であれば、ハードウエアプロテクトを解除する必要はないはずです。
unlock_mmc_protectを実行してその表示が出るのであれば、systemはrwマウント出来ると思うんですが。
以下の記事で一時rootの話を書いていますが、同じ表示ですよね？
http://hbkim.blog.so-net.ne.jp/archive/c2304132503-1
by kim (2015-10-11 00:20) 

そちらの記事を参考にしたところ、
Unlock_mmc_protectを実行し
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,relatime,data=orde
red 0 0
とsystemをrwでremountできたのですが、cpコマンドでsuを/system/xbinにコピーしようとしても、Read-Only File Systemと出てしまいます。。　その後grep systemしたところ、roに戻ってしまいました。
何度も質問をして申し訳ありません
by SHL23 (2015-10-11 09:41) 

先日アップデートをしてしまったため当方ではすぐに確認することが出来なくなってしまいました・・・・。
一応確認ですが、run_root_shell,unlock_lsm_miyabi,unlock_mmc_protect,mount,cpこれらはリブートせずに実行していますよね？
この方法はあくまでも一時rootの取得ですので、リブートすればすべてが元に戻ってしまいます、従ってもし/system/xbinにsuが転送できたとしてもリブートすれば消えてしまいます。
リブートせずにcpが失敗しているのであれば、unlock_lsm_miyabi辺りが失敗している可能性があるかもしれません。
Sharpのデバイスではsystemのイメージをファイル化して起動時に/systemとしてマウントすることでroot化するのが一般的なようです(細かいことはSH-06Eのroot化で検索してください)。

by kim (2015-10-11 10:15) 

ご指摘ありがとうございます。
SH-06E rooted tools ver.01.01を使用し,root取得を実行すると、unlock_lsm_miyabiとunlock_mmc_protectは正しく実行されているみたいなのですが、実行直後に勝手に再起動されてしまい効果が消えてしまっているようです、、
batファイルの処理を見ても再起動させている処理はしていなかったと思うのですが・・

by SHL23 (2015-10-11 10:56) 

SH-06Eと同様のroot化を行いたいという事でしょうか？
それとも単に一時rootを取得して/systemをrwマウントしたいだけでしょうか？
前者であれば、そもそも機種が違うので、rooted toolsそのままでroot化を完了させることはできないかもしれません。
ちなみに、/data/local/system.imgは作成されていますか？
作成されているようであれば、作成したsystem.imgを再起動時に自動マウントする部分がうまくいっていない可能性があるのではないかと思います。

あと、rooted toolsは0201があるようですが？

by kim (2015-10-11 12:14) 

toolのver0201を使用してもできませんでしたので手動でやってみることにしました。実行結果を載せます。長文失礼します

shell@android:/data/local/tmp $ ./install_backdoor
./install_backdoor
Attempt acdb exploit...
SHL23 (01.00.07) is not supported.
Attempt put_user exploit...
ioctl: Bad address
Attempt futex exploit...
futex_exploit: Server started
install_mmap: success
shell@android:/data/local/tmp $ ./run_root_shell
./run_root_shell
shell@android:/data/local/tmp # ./unlock_lsm_miyabi
./unlock_lsm_miyabi
miyabi_security_ops = 0xc0a29278
n_security_ops = 173
n_lsm_fixes = 13
#0: 0xc031f918 -> 0xc031d0c8
#1: 0xc031f920 -> 0xc031d160
#2: 0xc0320250 -> 0xc031d528
#3: 0xc0320078 -> 0xc031f528
#4: 0xc031fb28 -> 0xc031f530
#5: 0xc031fee4 -> 0xc031f538
#6: 0xc031ff64 -> 0xc031f620
#7: 0xc031f928 -> 0xc031f628
#8: 0xc031fa94 -> 0xc031f640
#9: 0xc031fe64 -> 0xc031f650
#10: 0xc031fb94 -> 0xc031f6a4
#11: 0xc031f9fc -> 0xc031da70
#12: 0xc03202f8 -> 0xc031f834
13 functions are fixed.
shell@android:/data/local/tmp # ./unlock_mmc_protect
./unlock_mmc_protect
Found mmc_protect_part!
7 partitions are fixed to readable.
1 partitions are fixed to writable.
shell@android:/data/local/tmp # mount | grep system
mount | grep system
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,relatime,data=orde
red 0 0
shell@android:/data/local/tmp # mount -o rw,remount /system
mount -o rw,remount /system
shell@android:/data/local/tmp # mount | grep system
mount | grep system
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 rw,relatime,data=orde
red 0 0
shell@android:/data/local/tmp # cp su /system/xbin/su
cp su /system/xbin/su
cp: /system/xbin/su: Read-only file system
by SHL23 (2015-10-18 18:01) 

拝見しました
マウント自体はRWになるものの、書き込みを行うとエラーで弾かれるわけですね。
lsmで蹴られているかmmcプロテクトで蹴られているかのような気がするのですが、unlock_mmc_protectもunlock_lsm_miyabiも実行結果を見る限り動いているように見えますね・・・。
私のほうでは仮rootを取れる環境がなくなってしまったため、実機での確認が出来ないので、これ以上はお役に立てそうにありません。
もしかしたら、demesgを見たりすると原因の一端がつかめる可能性はありますが。
by kim (2015-10-18 23:35) 

独学でカスタムkernelでの起動を勉強中ですがmmc_protect.koの作成でつまづいてます。
ブログを拝見する限り特別な修正をしているようには見えませんでしたが何かソースファイルに修正を加えていたのでしょうか？
こちらで再現を試してるのですがstatusの前半が表示されません。
kernelのmakeが問題なのかも知れませんが判断できません。
よろしくお願いします。
by みーや (2017-07-22 23:56) 

mmc_protect.cには特に手をいれてはいないと思います。
残念ながら私はMMCについては殆ど知識が無いので、MMCの操作で発生するエラーに関してはお答えできることは無いと思います。
/sys/kernel/mmc_protect/statusの表示でmmc_ext_user_wp辺りの表示が出ないのであればmmc_send_ext_csd(card, ext_csd)がエラーになっているのだと思いますが、なぜエラーになるのかまでは分かりません。
by kim (2017-07-23 17:45)