Transcript

• 1. cocos-2dxアプリの サーバーサイド事始め ～チート編～
• 2. 初めに •ソーシャルアプリで悩みの種になるチートにつ いて、その手口や対策などを紹介していきたい と思います
• 3. 本講演の対象者 •アプリ開発していてチート問題について聞かさ れてガクブルしている方 •チートについて興味のある方 •チートに悩まされてきた方
• 4. チート問題についてザックリと… •クライアントのメモリ改ざん事件 •不正にヒットポイントが増えるなど •通信データ書き換え事件 •通信で取得するカードパラメータ等を不正に強くしてゲー ムなど •データ再送信による二重付与問題 •クライアント側で二回データを送信されても大丈夫なよう に… •不正課金事件 •不正レシートによる課金
• 5. チート問題 •クライアントのメモリ改ざん事件 •不正にヒットポイントが増えるなど •通信データ書き換え事件 •通信で取得するカードパラメータ等を不正に強くしてゲー ムなど •データ再送信による二重付与問題 •クライアント側で二回データを送信されても大丈夫なよう に… •不正課金事件 •不正レシートによる課金
• 6. クライアントのメモリ改ざん事件 •脱獄したiPhone / root化したAndroidで動作する GamePlayerというツールを使用することで、アプリ内の メモリを書き換えられてしまう •書き換えたい数値を検索して、その数値のデータを書き換 えることが可能 •HPが2000だったとした場合、2000という数値を検索し、メモ リ上に2000となっているのをユーザーが好きに書き換えら れてしまう ⇒HP 999999 のキャラとかを作成されてしまう ※とあるタイトルでの実例： http://www.xn--gameplayer--w94j5c19a.com/124.html
• 7. クライアントメモリ改ざんに対する対抗策 •大事なデータは暗号化してデータを置きましょう。 •生の値でなければ、データを検索されても見つか りにくい •暗号化は排他的論理和(XOR)を使うと、とても楽 に実装できます •A xorB => C の場合、C xorB => A となるので、暗 号・復元がとても楽です。
• 8. クライアントメモリ改ざん対策の実装例 Class MyCharacter{ private: static constintKEY= 0xfedcba98; intmHp; //<=直接セットせずに、setHp,getHpを介してアクセス public: inline intgetHp()const{ return mHp^KEY;} inline void setHp( inthp){ mHp= hp^KEY;} };
• 9. チート問題 •クライアントのメモリ改ざん事件 •不正にヒットポイントが増えるなど •通信データ書き換え事件 •通信で取得するカードパラメータ等を不正に強くしてゲー ムなど •データ再送信による二重付与問題 •クライアント側で二回データを送信されても大丈夫なよう に… •不正課金事件 •不正レシートによる課金
• 10. 通信データ書き換え事件 •サーバーへ送るデータ/サーバーから受け取るデータを通信経路上 でデータ書き換えを行うことで不正に強いデータの作成・ゲーム結果 の詐称などが行えます。 •ゴーストルーターという製品が実際にあります データ 処理結果 ココでデータを書き換 えられてしまう！！
• 11. 通信データ書き換えを詳しく図解 ルーター Wifi サーバー ここでデータを書き換えられてしまっ たら？
• 12. 通信データ書き換えを詳しく図解 Wifi サーバー ルーターの役割をPCが行う。 ソフトウェアでヤリタイ放題！ チーターのPC
• 13. 通信データ書き換えの例 Wifi サーバー チーターのPC キャラ 一覧要求
• 14. 通信データ書き換えの例 Wifi サーバー データをそのままゲームサーバーへ 転送 チーターのPC キャラ 一覧要求
• 15. 通信データ書き換えの例 Wifi サーバー 要求があったプレイヤーは、LV１の キャラを５体所持しているので、その データを返却 チーターのPC 所持キャラ LV１×5体 キャラ 一覧要求
• 16. 通信データ書き換えの例 Wifi サーバー 本当はもっていないキャラも、持って ることにしたり、既存キャラのLVを９９ に書き換えて、クライントに返す チーターのPC 所持キャラ LV１×5体
• 17. 通信データ書き換えの例 Wifi サーバー 結果として、本来ユーザーが持って いないキャラやLVでゲームプレイが 行える！ チーターのPC キャラ 一覧要求 所持キャラ LV99×10体
• 18. 通信データ書き換えの例 Wifi サーバー ここで、サーバーからのデータを書き 換えることでチートされた！！ チーターのPC 所持キャラ LV１×5体 キャラ 一覧要求 所持キャラ LV99×10体
• 19. 通信データ書き換えの対策 •書き換えられてしまうのを防ぐことは原理的に不可能 •端末外かつサーバー外で行われている ⇒ならば、書き換えられているかを検知出来ればよい。 ※データが途中で書き換えられているようなら不正扱いして受け付け なければいい（サーバー・クライアント両方とも）
• 20. 通信データ書き換えの対策 •ハッシュ値によるデータチェックを行いましょう •サーバー/クライアントから送るデータの末尾にハッシュ 値を入れてチェック ※ファイルが破損していないかチェックしたりするためのMD5 チェックやCRCチェックなどと同じ原理です。
• 21. ハッシュ値の原理 ※データのダイジェストを作成しておきます。 データの不正書き換えが発生した場合には、ダイジェストが 変わってしまうので、エラーを検知できる仕組みです データ 646da9ae5d90e6b51b06ede01b9fed67 MD5/Sha-1等のアルゴリズムを用い ることで、データに対応した16Byteの ダイジェストが得られる
• 22. チート問題 •クライアントのメモリ改ざん事件 •不正にヒットポイントが増えるなど •通信データ書き換え事件 •通信で取得するカードパラメータ等を不正に強くしてゲー ムなど •データ再送信による二重付与問題 •クライアント側で二回データを送信されても大丈夫なよう に… •不正課金事件 •不正レシートによる課金
• 23. データ再送信による二重付与問題 •クライアント側から、ゲーム結果送信等のデータが二 回送られてしまうことで、二重にキャラの付与処理等 が行われてしまう •実はデータ通信の途中で失敗するなどのケースで、わざ とではなく偶然発生してしまう事もあるので、注意が必要
• 24. クライアント サーバー １．サーバーに、ＩＤとパス ワード、遊んだダンジョン、 取得したスコアを送信 ｛”id”:” a7c4eab”,”passwd”:”te32BG”,” dungeon”:2,”score”:100｝ ユーザー行動のデータ再送信のケース
• 25. クライアント サーバー 2．受け取ったデータを元に ユーザー認証を行い、正し ければサーバー内のユー ザーデータを書き換える ユーザー行動のデータ再送信のケース ｛”id”:” a7c4eab”,”passwd”:”te32BG”,” dungeon”:2,”score”:100｝
• 26. クライアント サーバー ３．サーバー内で書き換え たデータ等を返そうとしたと 失敗します ｛”money”:20,”getCard”:[1,2,3]} ユーザー行動のデータ再送信のケース
• 27. クライアント サーバー ４．通信に失敗したみたい なので、もう一回データを 送ります ｛”id”:” a7c4eab”,”passwd”:”te32BG”,” dungeon”:2,”score”:100｝ ユーザー行動のデータ再送信のケース
• 28. クライアント サーバー 5．既に処理済みのデータが 来たので、データの更新は 行わずに結果だけ返さない といけない。 ユーザー行動のデータ再送信のケース ｛”id”:” a7c4eab”,”passwd”:”te32BG”,” dungeon”:2,”score”:100｝
• 29. データ再送信の対策について •通信ごとにユニークなIDを割り当てて、サーバー側で 最後に行われた通信をキチンと把握しておきましょう •サーバー側でプレイヤーのゲームプレイのステータ ス管理をしましょう •ゲームプレイ開始してないのに、結果が送られてきたら オカシイなどなどの判定が出来ます
• 30. チート問題 •クライアントのメモリ改ざん事件 •不正にヒットポイントが増えるなど •通信データ書き換え事件 •通信で取得するカードパラメータ等を不正に強くしてゲー ムなど •データ再送信による二重付与問題 •クライアント側で二回データを送信されても大丈夫なよう に… •不正課金事件 •不正レシートによる課金
• 31. 不正課金事件について •不正なレシート（購入証明書）を送り付ける事で、課 金していないのに課金アイテムを得ようとするケース があります •別のアプリのレシートを送って、購入したことにしようとし てみる •かなり昔に処理をしたレシートを送って、購入したことにし ようとしてみる
• 32. 不正課金事件の対策 •Android / iphone共に送られてきたデータが自分のアプリ内課金商 品が購入されているか確認しましょう •AndroidではorderID、iPhoneではtransactionIDと呼ばれる決済ごと にユニークなIDがあるので、過去に決済されたデータは全て残して おきましょう。
• 33. チート対策回りでのまとめ •クライアント側は、重要なデータは暗号化・ハッシュ チェック等を行うようにしましょう •サーバー側は、クライアントから来たデータは信じな いスタンスで行きましょう。 •通信は、暗号化・ハッシュチェック等を行い改ざんさ れないようにしましょう •通信は同じものが何回か行われてしまうことを想定し ましょう
• 34. Appendix Hashによるチェックや通信経路の詐称などの細かい話は 「新版暗号技術入門秘密の国のアリス」という書籍が詳しく説明されてい ます。 セキュリティなどに関する基本的なところが学べるのでお勧めです。 http://www.amazon.co.jp/%E6%96%B0%E7%89%88%E6%9A%97%E5%8F%B7%E6%8A%80%E8%A1%93%E5%85%A5%E9%96%80- %E7%A7%98%E5%AF%86%E3%81%AE%E5%9B%BD%E3%81%AE%E3%82%A2%E3% 83%AA%E3%82%B9-%E7%B5%90%E5%9F%8E-%E6%B5%A9/dp/4797350997