rооt化する際に理解しておくべきこと
この記事はなぜその操作、手順が必要なのかを理解することを目的として作成しています
とりあえず書いてある通りにやってみたら出来たというやり方をしていればパターンや条件が変わった時に間違った操作をしてしまうかもしれません
デタラメでいい設定は無く、すべての設定に意味があります
訳も分からず書いてる通り、言われた通りに進めるのではなく、それぞれ何がどのような役割をしているのかを理解していれば条件が変わっても何が必要で何をしなくていいのか判断できるはずです
以下は大まかに概要を掴むだけのものとなっていますので実際とは多少異なる場合がございます
予めご了承下さい
Androidのrооt化とは
rооt化というのは端末の管理者権限を取得することです
実はスマートフォンの管理者はメーカーです
普段私たちはユーザー権限という限られた権限の中でスマートフォンを使用しています
rооt化することでシステム内部の調整や操作を行うことが出来るようになります
rооt化の方法
現在のrооt化の方法はMagiskという仕組みを使用するのが一般的であり、Magiskでシステムのboot.img上にSU(SuperUser)をインストールすることでrооt権限を取得しています
各メーカーは端末のシステムが改変されないようにBootLoader(起動時にシステムを読み込むためのプログラム)にロックをかけているので、rооt化するためにはこのBootLoaderがアンロックされている必要があります
BootLoaderのアンロックはどの機種でもできるというわけではなく、正規の手順でアンロック可能な機種、メーカーは限られています
また、BootLoaderをアンロックするとメーカーの保証外となり、文鎮化してもメーカーで修理してもらうことは出来なくなります
端末をrооt化する際は復旧方法も含めて事前に準備しておくことが大切です
kingorооt等、rооt化アプリみたいなものが未だに存在していますがよっぽど古いAndroid以外では不可能です
bootloaderをアンロックせずにシステムを改変できる端末はありません
Magiskについて
Magiskは台湾のtopjohnwuによって開発されたAndroid5以上で動作するrооt権限取得アプリです
Magisk23まではMagiskHideという、アプリからrооtを隠す機能が実装されていましたが、topjohnwuがgoogleのセキュリティチームに入ったことに伴い、この機能が利益相反となるとのこと等からMagisk24から排除され、新しくZygiskというシステムに変わりました
現在はDenyListとしてアプリにMagiskを適応しないことで隠すと同様の機能が実装されています
アプリによる不正検知(rооt検知)
アプリがどのようにしてrооtを検知しているのかというのはアプリによって様々ですが、最も一般的なのはSafetyNetAttestationAPIというGMS(Google Mobile Service)のシステムを利用する方法です
SafetyNetAttestationAPIの仕組みは複雑なので簡単に説明します
まずアプリがGooglePlayサービスにデバイスの整合性の検証をリクエストし、その結果をアプリがクライアントに送ります
クライアントからアプリへ診断の結果（例 アプリが起動するorしない）が返されます
この仕組みからデバイスの整合性を診断しているのはアプリ自体ではなく、GooglePlayサービスのレスポンスによって不正の診断がされていることが分かります
もちろん、中には端末のpropファイルようなデバイスのデータベースをアプリが照合し、デバイスの異常検知するアプリも存在します
例えば、中国ではGMSを利用できないので中国産アプリではSafetyNetを利用する以外の方法で不正の検知をしていることがあります
これを回避するのにMagiskモジュールのshamikoが利用されます
shamikoを使いたい場合は相性問題を避けるため、必ずshamiko開発者がブランチしているMagiskのalpha版を使用してください
クライアントから見ると、SafetyNetを利用して不正検知するほうが信頼性も高く実装も簡単なので、アプリが直接デバイス情報を検証するようなことは少ないです
Pokémon GOのようにSafetyNetのみを利用してデバイスの整合性を検証するような場合ではshamikoの効果は特にありません
▶shamikoを使う場合はmomoで不正検知をパスできているか確認することが出来ます
但し、LSPosedを使用している場合は不正な環境に判定されるのでどのみちshamikoを導入しても完全に不正検知をpassすることは出来ません
→じゃあどうすればいい？
そもそもポケGでは端末環境によるBANをしていません
BANの原因はすべてゲーム内での不正です
トラブルを避けるために位置偽裝に関係のない無用な設定は極力減らしましょう
SafetyNetの検証→廃止のため段落を削除
PlayIntegirity
PlayIntegirityAPIでは幾つかの検証を行っています
以下の検証にPassすることでデバイスの整合性が証明されます
①MEET_BASIC_INTEGRITY
rооt化端末、エミュレータ、API フックなどの改ざんが検知された端末では、この値がfalse（不合格）となります
②MEET_DEVICE_INTEGRITY
Googleの互換性認証を受けていない*端末ではこの値がfalseとなります。決済アプリで要求されることが多い
*Playプロテクト認定で確認可能
③MEET_STRONG_INTEGRITY
bootloaderがアンロックされている場合はfalseとなります
この値は改ざんすることが出来ません
PlayIntegirityFixモジュールでは、インストールするだけで①②を回避してくれます
③を回避することは現時点で不可能です
もし③が要求されるようなことになった場合はroot化はもちろんのこと、BootLoaderがアンロックされた端末では一切起動できなくなります。
以上のことからアプリ自体よりもGoogleサービスからrооtを隠すほうが重要であるということが分かると思います
現在9割以上のアプリはPalyストア及び開発者サービス、そのアプリ自体をDenyListでチェックすることで不正検知は回避可能です
ただし何でもDenyListに入れればいいというわけではなく、不正検知で起動しないアプリ以外を入れる必要はありません
特にアプリに対して何かしらMagiskが作用している場合やrооt権限を必要とするアプリを、DenyListに追加してしまうとモジュール等は無効化されてしまいます
またPlayIntegrityがPassしているかどうかはPlayIntegrity API Chekcer等のアプリで確認することができます
SmaliPatcherとHideMockLocation
疑似位置情報を使用するにはA7-A11の場合はSmaliPatcher、A7-A13ではLSPosedを導入し、HideMockLocation
(またはmockmocklocation)を使用します
SmaliPatcherは端末のフレームワークを抽出し、書き換えてシステムレスなモジュールを作成することで位置情報が偽裝ではなくGPSによる位置情報であると認識させることが出来ます
一方でLSPosedとはアプリに何かしらの操作を加えることなく、アプリの設定や挙動を変更できることを可能にするモジュールです
HideMockLocationはLSPosedを利用し、アプリごとに位置情報の取得を変更させるアプリとなります
SmaliPatcherはA12以降のフレームワークへの対応が出来ていないようですが、端末全体に機能するためアプリごとに色々設定する必要がないのであとが楽です
LSPosedはアプリごとに設定する必要があります
LSPosedはかなりコアなモジュールで文鎮、boot loopが発生しやすいので慎重に使う必要があります
A11以下の場合は基本的にSmaliPatcherをおすすめします
物理ボタンからFastbootモードに入れる端末であれば復旧出来る可能性が高いですが、入れない端末で文鎮化すると復旧させる手段はほぼありませんので慎重に行ってください
これらの設定がうまく行っていない場合エラー12が返されます
位置偽裝アプリ
GPS JoyStick(Ninja)が使用されることが一般的です
このアプリを使用するには本体にGPS機能が搭載されていることが条件となります
本体にGPS機能が搭載されていないタブレットのWi-Fiモデル等では使用できないので他の方法を使う必要があります
非rооtのシステムインストールでない限り、正しく設定されていればラババンは起きません
ラババンが起きるのは本体のGPSによる位置情報取得とアプリの位置情報を交互に取得してしまっているためです
具体的にはアプリ設定の間接的なモッキングや中断されたモッキングがオンになっている、本体設定の位置情報精度等がオンになっている場合です
GPSによる位置情報を遮断するためにこれらはすべてオフにしてください
GPSジャマー等は全く必要ありません
Androidにおける各アプリの役割
Androidでは各アプリが上図のような役割を果たしています
つまりjoystickを使わなければリアル位置でもプレイも出来ますし、チートアプリを使わなくても何も問題ありません
またそれぞれ独立しているので役割と違うことは出来ません
改造アプリはなぜ危険？
ここでは改造アプリにウイルスやバックドアが仕込まれているとかそういうことではなく、クライアント側に改造アプリと検知される可能性についての話となります
クライアント(Niantic)のサーバーでは接続してきたアプリが正当であるかどうかをアプリのハッシュ値(そのアプリ固有の値)によって判断することが出来ます
まずクライアントはAPIを呼び出したアプリ名を確認することが出来ます
アプリパッケージ名が正規と異なる場合はここで検知されます（パラレルワールド等で複製したアプリが起動しないのはここで弾かれるため）
次にPlayストアに登録しているアプリとその署名のハッシュ値を、API を呼び出したアプリの apkDigestSha256の値、apkCertificateDigestSha256の値と比較することでアプリの正当性を判断することが出来ます
値が異なっていた場合はここで改造アプリと検知されます
このハッシュ値は1bitでも異なれば全く異なる値となり、特定のハッシュ値に合わせてアプリを作るのは不可能です
改造アプリはこの値を改ざんしたり、ハッシュ値の比較をさせないようにして回避しているものと思いますが、クライアントがハッシュ値の比較を頻繁に行うようになればどこかで検証の回避に失敗し、不正と判断される可能性が高くなります（改造アプリでのBANがまちまちなのはこのためだと考えられる）
以上が改造アプリをおすすめできない理由です
正規アプリを使用し、rооt検知を回避するほうが遥かにBANへの危険性は低いです
追記：rооt化自体が要因でBANされることはありません
ユーザーの同意無しでアプリがデバイス環境を送信したり、端末内のデータをスキャンすることは禁止されています
なのでrооt化等検知された場合はアプリ内の警告が表示されるようになっています（アプリ内で動作を制限するのは問題ない）
BANの原因は改造アプリからのログインorゲーム内での不正のいずれかです
ここまで、rооt化の検知を回避する方法やその仕組み、改造アプリの危険性などを書きましたが、大まかに概要を掴むだけのものとなっていますので実際とは多少異なる場合がございます
これらに関して詳しく知りたい方は以下を読んで理解を深めてください