さまざまな物や事に関する、役に立ったり立たなかったりするテキストが綴られるブログ。

2016/09/06

[Android] suhideを試してみる

しっかりとroot認定されてます
SuperSUで有名なChainfire氏の新作"suhide"を試してみました。これがナニモノかというと、root化済みの端末を非root端末に偽装するツール。

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"導入前(冒頭の画像)とは異なり、非root端末であるとの表示が。うまく騙せたようです。この結果に気分を良くして、root化済み端末では動作しないゲームや銀行系アプリを試してみました。

が、すっかり玉砕。これらのアプリには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は通らなくなりました。



Related Posts with Thumbnails

7 件のコメント:

匿名 さんのコメント...

suhide v0.53 の前提条件にSuperSU v2.78 SR1以降をsystemlessでと書いてますが、SR1以外のsystemlessは見つけれたんですが、SR1のはありませんでした。これは自分でsdkとかで処理しないといけないのでしょうか?

WHMaster さんのコメント...

普通にリカバリモード(TWRP)で2.78SR1のzipをフラッシュすればsystemlessモードでインストールされます。
ただ、それ以前にSuperSUをユーザアプリとしてインストールしていた場合、SuperSUの設定から"ルート権限を放棄(アンルート)"を実行しておいた方がよろしいかと思われます。

匿名 さんのコメント...

SuperSU2.78を削除し、その後TWRPで2.78SR1をフラッシュしたんですけどsystemlessではなく、systemに書き込まれsuhideのインストールでエラーが出たので質問しました。
ルート権限を放棄を実行しないとやはりうまくいかないんですかね・・

WHMaster さんのコメント...

ズバリそのものな解決策ではありませんが...

1.SuperSUのインストール前にターミナルから以下のコマンドを実行してみる。
echo "SYSTEMLESS=true" > /data/.supersu

2."ルート権限を放棄(アンルート)"を実施してみる。

3.フルワイプを実施してみる。

...を上から順に試してみると何か変化があるかもしれません。

匿名 さんのコメント...

SuperSU2.78をアンルート
TWRPターミナルにてSYSTEMLESS=trueを入力
2.78SR1をフラッシュ→suhide v0.53をフラッシュ
で一応suhideは入りました。
ですがその後の記事にある「TWRPで"suhide"のZipファイルをフラッシュしてからSuperSUを上書きすればOK。」とありますが「SuperSUを上書き」とはどの「SuperSU」でしょうか?
2.78SR1であれば試したのですが、その後リブートしても「ルート無し」の状態になってしまいます。

WHMaster さんのコメント...

SuperSU上書きの件ですが、以前のバージョンにおいてsuhideのインストール後に再びSuperSUをフラッシュする手順が推奨されておりました。その名残りで、文章的にもそのような記述が残っておりますが、現在はSuperSUを上書きインストールする必要はなくなったようです。

で、unloot状態になってしまう件ですが、suhide v0.5から当方の端末(Nexus4)でも似たような症状が発生しておりました。が幸いにしてv0.53にて改善。

正直、何が原因でどうすれば直るのか不明です。当方ではsuhideが動かない間、Magiskを導入することでお茶を濁しておりました。

次のネタとして準備しているのですが、Magiskも関連ツールが揃いつつあり、使い勝手的にはsuhideと同様かそれ以上となっております。「どうしてもsuhideでなければダメ」というのでなければMagiskを考えてみるのもよろしいかと思われます。

匿名 さんのコメント...

丁寧な説明、ありがとうございます。
Magisk関連のことを調べてみようかと思います。

新しい投稿へ 以前の投稿へ ホームへ