[Android] suhideを試してみる
2016年9月6日
2016年10月13日
SuperSUの存在を隠すことによって、root化済み端末では動かないハズのアプリが動くようになる(かもしれない)という便利アイテムです。
特に必要性は感じなかったですが、面白そうなので試してみることに。
前提条件として求められるのは、SuperSU(v2.78 SR1以降)がsystemlessモードでインストールされたAndroid 6.0以降の端末。また、インストールおよび設定のためにTWRPも必要となります。同氏のアプリ"FlashFire"でも大丈夫らしいのですが、守備範囲外なので、ここではTWRPに限定させていただきます。
なお、インストールから準備までの話が長めなので、結果だけ知りたいという方は、2枚めの画像の辺りから読み始めるのがよろしいかもしれません。
それではまずインストールから、"suhide"の本体は上記xdaの最初の書き込みの末尾に添付されておりますので、そこからダウンロードしておきます。インストール自体は非常に簡単で、TWRPで"suhide"のZipファイルをフラッシュしてからSuperSUを上書きすればOK。けれども設定は少々面倒です。
まずは"suhide"の動作対象にしたいアプリのUIDを調べる必要があります。UIDはインストールされたアプリに割り振られる固有の番号(5桁の数字)で、端末ごとに異なる可能性が大。なので自分自身での調査が必須となります。
***Edit***
現在のバージョンでは、インストール時にデフォルトで"Google Play開発者サービス"のUIDが登録されるようになっており、何も設定しなくてもSafetyNetのCTSチェックをパスできます。なので、他のUIDを登録する場合に限り、以下の手順をご参照いただきたく。
***Edit***
で、そのUIDを知るための方法としてはターミナルエミュレータからの操作が推奨されております。その下準備として必要なのが、ターゲットとなるアプリのパッケージ名。
ここでは、root化済み端末をチェックするアプリ"Root Checker Basic"をターゲットとして話を進めます。このアプリを"suhide"の導入前に実行した結果が冒頭の画像となっております。
パッケージ名を調べる方法はいろいろあるのですが、お手軽なのはシステムの設定を使う方法。"設定"→"アプリ"を開き、対象となるアプリをタップするとバージョンの下にパッケージ名が表示されます。そのパッケージ名を引数として以下のようにlsコマンドを実行します。
ls -nld /data/data/com.joeykrim.rootcheck
すると、以下のような結果が返されます。
drwxr-x--x 11 10141 10141 4096 2016-09-01 07:41 /data/data/com.joeykrim.rootcheck
結果の中に5桁の数字があり、これが目的のUIDとなります。この場合には10141がそれ。ターゲットが複数あるのなら、その数だけ上記作業を繰り返してUIDを調べておきます。
ちなみに、ここまでの作業は"suhide"がなくてもできるので、ターゲットが明確なら"suhide"のインストール前にチェックしておくと効率的です。
ここからがやっと本番。"suhide"の設定となります。まずはTWRPを起動して、ターミナル機能を起動。先ほど調べたUIDを引数として"add"スクリプトを実行します。
/su/suhide/add 10141
実行後に何のエラーも出なければ成功...なのですが、ウチの環境では"not found"と言われてしまいうまく行きません。なので、推奨方法とは異なるのですが、システムを起動し、SU後のターミナルエミュレータアプリから同スクリプトを実行しました。
このスクリプトは、suhide.uidというUIDのリストに指定されたUIDを追加するスクリプトです。実行後にsuhide.uidをチェックしてみましたが、きちんと追加されている様子。なのでこの方法でも問題はないと思われます。
なお、登録したUIDを削除したい場合には"rm"スクリプトを使用します。書式は"/su/suhide/rm xxxxx"こんな感じ。xxxxxにはもちろんUIDの数字が入ります。
UIDの登録が完了したら、念のためシステムを再起動しておきます。これで準備は完了。ということで、ターゲットとして登録したアプリである"Root Checker Basic"を起動してみました。
が、すっかり玉砕。これらのアプリにはroot化済み端末と判断されてしまい、起動することはできませんでした。お金がからむと本気度が異なるようです。
他の手法を組み合わせることで、上記アプリも動くようになるかもしれませんが、それを目的としている訳ではないので今回はやりません。
何かいまひとつな雰囲気ではありますが、この結果を持って"suhide"がダメであると決めるのは早計というもの。xdaではSafetyNetのチェックをパスしたという報告もあり、root化済み端末でAndroid Payが使えるようになる...可能性を秘めております。
登録済みのアプリに関しては"suhide"が自動的に動作するためユーザが操作する必要がない点、そして登録外のrootedアプリには影響がなく普通に動作する点は"suhide"の大きなアドバンテージといえます。
もし、"suhide"で効果があるアプリをターゲットとするなら、これ以上便利なツールはなさそう。今のところ使い道はほとんどありませんが、覚えておくといつか役に立つかもしれません。
最後になりますが、もしご自身でお試しの際には、何ごとも自己責任でひとつよろしくお願いしたく。
***Edit***
検証にCM13を使ったためか、suの痕跡が残っていたようです。
/system/xbin/su
/system/bin/su
上記2ファイルを削除することでSafetyNetのチェックをパスできるようになりました。ちなみに、使用したアプリはこちら。
けれども、ゲームや銀行系アプリに関しては変化がありませんでした。
***Edit2***
SafetyNetですが、サーバ側で対処されたらしく、再びチェックを通らなくなりました。
***Edit3***
バージョン0.5以降でSafetynetのチェックをパスするようになったようですが、当方の環境ではうまく動かず検証はできておりません。
***Edit4***
バージョン0.53にて再び当方の環境でも動作するようになり、SafetynetのパスならびにポケモンGoの起動を確認。また、ディレクトリおよびコマンド名の変更に伴い内容を修正しました。
***Edit5***
2016/10/6辺りでSafetynetがアップデートされたらしく、またチェックを通らなくなりました。
***Edit6***
バージョン0.54にて上記アップデートに対応しました。
***Edit7***
2016/10/13 SafetyNetのアップデートによりsuhide v0.55は通らなくなりました。
ー記事をシェアするー
コメント
ただ、それ以前にSuperSUをユーザアプリとしてインストールしていた場合、SuperSUの設定から"ルート権限を放棄(アンルート)"を実行しておいた方がよろしいかと思われます。
ルート権限を放棄を実行しないとやはりうまくいかないんですかね・・
1.SuperSUのインストール前にターミナルから以下のコマンドを実行してみる。
echo "SYSTEMLESS=true" > /data/.supersu
2."ルート権限を放棄(アンルート)"を実施してみる。
3.フルワイプを実施してみる。
...を上から順に試してみると何か変化があるかもしれません。
TWRPターミナルにてSYSTEMLESS=trueを入力
2.78SR1をフラッシュ→suhide v0.53をフラッシュ
で一応suhideは入りました。
ですがその後の記事にある「TWRPで"suhide"のZipファイルをフラッシュしてからSuperSUを上書きすればOK。」とありますが「SuperSUを上書き」とはどの「SuperSU」でしょうか？
2.78SR1であれば試したのですが、その後リブートしても「ルート無し」の状態になってしまいます。
で、unloot状態になってしまう件ですが、suhide v0.5から当方の端末(Nexus4)でも似たような症状が発生しておりました。が幸いにしてv0.53にて改善。
正直、何が原因でどうすれば直るのか不明です。当方ではsuhideが動かない間、Magiskを導入することでお茶を濁しておりました。
次のネタとして準備しているのですが、Magiskも関連ツールが揃いつつあり、使い勝手的にはsuhideと同様かそれ以上となっております。「どうしてもsuhideでなければダメ」というのでなければMagiskを考えてみるのもよろしいかと思われます。
Magisk関連のことを調べてみようかと思います。