samsung@security_boot_check回避

某うんこ掲示板で、クソ野郎どもとウンコまみれになって戯れるのは、もうコリゴリなため
ここにチラ裏的にトピックを立てる
（例によって俺は新しく出たアレ持ってないし買う予定もない、
あくまでも自分が持っている機種にアプデが来た際の参考として）

https://gist.github.com/HomuHomu/6e37cc ... 1-txt-L211
↑
とうとうやってくれたな。というのか正直な感想
仕掛けは多分最近のLGやHTCに入ってるものと同じ
それに従来の罠とKnoxが入り込んで、また最悪な事になってると思われ
こんなゴミ買う意味なんてねぇわと言ってしまったらそれで話が終わってしまうから

とりあえず、Knox Warrantyを書き換えずに、必要な時だけ＃取れる姿を目的として
type６を提案（Felica云々は例によって後回し、そんなものはStock.tar.md5を焼き直せば元に戻るはずだ）
https://github.com/kbc-developers/make_ ... 49e5e489c3

/sbin/security_boot_check system
で/xbin/daemonsuもスキャンしている筈だからetcに移動
kiesexe呼び出してる部分がなくなったため、su_serverの個所をbin/mfescandに戻した

システム全体でverifyしてたら、根本的に考え直さなければならないだろうけど
そうなったら、ramdisk編集してboot.img焼くしかなくなるだろうな
まぁあれだ。そうなったら窓から投げ捨ててNexusシリーズ買い直すしかないな

いずれにせよもうSuperUser使うメリットはメーカーキャリア問わず、ほぼ無くなる

ちょっと理解していないのですが、
su入りである場合に、security_boot_checkに引っかかり起動しないということですか？

L01F/LGL22/LGL23では/sbin/security_boot_checkバイナリが存在していますが、
systemを見ていないので、systemにsuが存在していてもbootには影響していません。
例に上げてる最近のLGが示すものはGPRO2ですか？

S5自体に興味がなくこの辺調べてないのが悪いのですが、
実際にsu存在すると起動しないなどの報告があがっているという事ですか？
できればsecurity errorに関してどのような事例が上がっているのか書いていただけると助かります

さてさてフラグ立っちゃうよ程度ならいいんですけどねぇ・・・
仮にsystem改変チェックでboot不可でかつboot署名チェックでfastboot行きがセットになると終了ですよね
そうなるなら今後については
今持っているやつに対して、ほそぼそとマージbotになるだけがアレですかね。

/sbin/security_boot_check バイナリの役割がLG or HTCで入っているものと同等程度のものなら
今回のように引数にsystem指定されてる場合、どうなるかはお察し

多分、起動そのものが行われない＆warrantyフラグがつく

ただし、以前に自分が想定しビンゴだったように
System改変をチェックするのに2.7GBもの領域を起動時にくまなく舐める事はしていないと仮定
（それはSysscope.apkの役割）
もし舐めているならば、そこで終了

warrantyフラグがつくけどFelica使えるよってとこまでなら、ramdisk弄ればいいだけなので
そこは今回に関しては論外とする。

今回のトピックは、あくまでも security_boot_check systemをどこまでごまかせられるかどうかについて論ずる

SC-04Fでmake_rooted_system焼いた結果

Odin焼き完了後、DLモード画面に黄色で Set Warranty Bit : system"と表示されます。
KNOX WARRANTY VOID:0x1(3)
http://i.imgur.com/NGdGFWO.jpg

type5/rara1.3/6とも起動時ロゴループです。

KNOX WARRANTY VOID:0x1の状態でもStock ROM焼けば正常起動し、Felica等もOK。
端末状態もオフィシャル。

攻略する知識はないのでネタ投入してもらえれば実機で柱します。

検証どうもです
chainfireのようにrooted用カーネル作れば
（04Fでカスタムboot焼けるならば）
それではwarrantyを回避しつつ
保証を維持したままメインで
使用するというmake rooted systemの
本来の目的から外れてしまう。
キャリアのくそ高い端末代金と通信費は
サポート代金に多分に含まれているから
それなら白ROM買ったほうがいい
という本末転倒な話になる。
検証結果から予想するに、path通ってる箇所を
チェックしているのではなく
system.img.ext4に署名が入っているか
もしくはmd5かなにかでvalidation check
が行われてると思われる。
もうwarranty潰さすにやりたい放題するのは
手詰まりかもね。
流石にこれ以上の対策は思いつかない
ついにトドメを刺されたかという感じ

ちなみに、全く関係ない話だけど
Oneplus Oneはいつから
普通に買えるようになるんでせうかね

コメントありがとうございます。

Knox Warrantyはほむさんの想像通りかもしれませんね。
Install suしないでRepackだけしたsystem焼いてもSet Warranty Bit : systemと表示され
更にロゴループでした。
Stock ROM焼いた時はSet Warranty Bit : systemの表示は無し(当たり前か・・・)

ちな先のmake_rooted_systemのType6はinsutall_suにfunc_install_su_type6()が2つ記述あったので、
下の方(func_install_su_type6_exynos()の上)を消してやりました。

一回返信書いたのに間違って消えてやる気なし状態ですorz

＞/sbin/security_boot_check バイナリの役割がLG or HTCで入っているものと同等程度のものなら
＞今回のように引数にsystem指定されてる場合、どうなるかはお察し

答えでているようですけど、お察しできなかったので聞いています。
LGでは、repackでそのバイナリをコールしていようと起動します。
起動しないのは署名なしの場合です。　security errorになるのが別バイナリ。

＞ちな先のmake_rooted_systemのType6はinsutall_suにfunc_install_su_type6()が2つ記述あったので、
＞下の方(func_install_su_type6_exynos()の上)を消してやりました。

出張中にパッとみただけで気が付かなかったんですが、
確かにtype6はSC04Eの4.3アプデ対応で定義済みです。

S5向けをtype7などに定義を置換していただければなと思います。

type6既にありましたね。直しました。(というか、どう考えても見込みがないので、戻して push -f しました）
ではsystem.img.ext4に署名がついたということで
この問題はクローズドとしたい
まさか、ギャラがXperiaみたいなことするとは思わなかった…

追記
Warranty潰しても焼きたい需要はあると思うので
https://github.com/xiaolu/mkbootimg_tools
これを参考にどうぞ

便利なツールがあるんだ。
最近流行りのROMブレンドとかこれ使ってやってるのか。

boot.imgバラしてみたけど改変boot.img焼くとカウントアップするだろうし、おサイフどうなるか不明だし
保障は要らないけどおサイフだけ使いたいミジンコには無理ぽorz

何も考えずにmake_rooted_system焼いた時の勇気が欲しいw

週末色々調べて、悶々・・・

make_rooted_kernelを作りたい。
・カウント/Knox Warrantyは諦める
・おサイフが使えるrooted環境にする

で、先のツールでバラしたramdiskゴニョればrootedまではイケそうなのですが、
カウントアップした状態でおサイフ使えるようにするのも、ゴニョでイケますか?
ソースコードから修正となるとツール化は不可なので・・・

そもそも過去sam機でやられていたfelicaキーやらの対策の仕組み自体理解していませんm(_ _)m

まずは改変カーネル焼いてみるところから始めないとですがw