SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

特集記事

入門! チートの解剖学 ~セキュアプログラミングでゲームのチートは防げるのか? ~

Webアプリケーションのセキュリティとの違いはどこか

 ゲーム開発の分野におけるセキュアプログラミングについて、チート対策の観点から駆け足で見てきました。はじめに書いたように、当稿では、セキュアプログラミングとしてどのようなことを考える必要があるのかということは、どの分野のセキュリティであるのかによって異なってくるとして、チート対策におけるセキュアプログラミングの特徴をWebアプリケーション開発におけるセキュアプログラミングとの対比によって捉えていくことを目的としています。以降では、注目すべきポイントを挙げてこの対比を進めていきたいと思います。

管理者ではなく、攻撃者によって実行される

 最大の違いとして挙げられるのは、Webアプリケーションが管理された安全なサーバーで実行されるプログラムであるのに対して、ゲームは攻撃者が所有するクライアントで実行されるプログラムであるという点です。Webアプリケーションに対して攻撃者ができることはHTTPリクエストの送信だけですが、ゲームに対してはプログラムを静的・動的に解析することから、プログラムやメモリの内容を改変して実行することまで攻撃者はほとんどなんでもできてしまいます。このため、チート対策においてはプログラムに耐タンパー性のような特殊な性質が求められます。

ユーザーを守るのではなく、ユーザーから守る

 プログラムに脆弱性があるといった場合、通常は「そのプログラムを実行するとユーザーが被害を受ける」ということになります。サーバーサイドのプログラムに脆弱性があればそのプログラムを実行したサーバーに侵入されるといった被害が発生し、アプリに脆弱性があればアプリを実行したユーザーのファイルが奪われるといった被害が発生します。

 しかしながらチート対策では、プログラムに脆弱性があると「そのプログラムを実行するユーザーから被害を受ける」ということになります。ゲームアプリにチートが行える脆弱性があればそのゲームを不正な状態で実行され、料金支払いを回避されたり、ゲームバランスを損なったりするような異常なプレイをされてしまうことになります。

 一般的な意味でのプログラムの脆弱性を考える際に登場するロールは「プログラム」「ユーザー」「攻撃者」の3つですが、チート対策でプログラムの脆弱性を考える際には「プログラム」と「攻撃者」の2つのみとなり「ユーザー」は「攻撃者」自身となります。これをロールが減って単純化されたと捉えてはなりません。これは「攻撃者」と「ユーザー」が結託している状態といえ、両者が独立に存在している場合に可能となることの合計以上のことができるようになって、状況はより複雑になります。

アプリケーションのロジックではなく、その下にあるシステムの動作機構のレベルで考える

 Webアプリケーションに対して攻撃者ができることはHTTPリクエストの送信だけであるため、Webアプリケーションのセキュリティは「どのような内容のリクエストを受けたとしても問題はないか」という観点で捉えられます。これは、正常な入力に対しては期待される効果をもたらし、異常な入力に対してはエラーを発生させるというアプリケーションとして満たすべきロジックの中にある問題といえます。これに対してチート対策では、セキュリティを「プログラムがどのように解析や改変を受けたとしても問題はないか」という観点で捉えることになります。アプリケーションとしてのロジックが正しいかではなく、実行ファイルとしてビルドされた結果の内容がどうなっているか、実行時にはOSやハードウェアに何をし何をされるのか、といったプログラムやOSあるいはコンピューターそのものの動作機構の問題としてセキュリティを捉えることになるといえるでしょう。

 実務的な面から捉えると、Webアプリケーションを開発する際にはセキュリティについてもアプリケーションのロジックの一部として同じエンジニアが同時に考えていく必要がある、ゲームを開発する際にはゲーム自体の内容を開発するエンジニアとチート対策を担当するエンジニアは分けることができる、という違いになるかと思われます。技術の高度化がとどまるところを知らず、VRのような新技術も次々に登場するゲーム業界では、エンジニアの分業化や専門化が進んでいるという話を耳にします。このような分業化・専門化の流れの中でチート対策にも専門的にあたるプロジェクトメンバーが必要になってきているのではないでしょうか。

まとめ

 ソフトウェア開発の分野が異なれば、求められるセキュリティの内容も異なるものとなります。

 ゲーム開発の場合、サーバーサイドのセキュリティにはWebアプリケーションのそれと共通する部分も多々ありますが、クライアントサイドではこれとは観点がまったく異なるチート対策のセキュリティが求められます。

 クライアントサイドでのセキュリティは「ユーザーに対する攻撃を防ぐ」という観点で分析されるのが通常ですが、チート対策は「プレイヤーによる攻撃を防ぐ」セキュリティであり脅威のモデルが異なります。

 チート対策では、攻撃者は自身が管理する端末で攻撃対象のプログラムを好きなように実行できるため、ファイル改変・プログラム改変・通信改変・メモリ改変・OS改変・デバイス改変といった攻撃も想定する必要があり、耐タンパー性のような特殊な性質が必要になります。

 多くのチートは技術的にはそう難しいものではなく、被害の頻繁な発生と広範な拡大に注意が必要です。

 チート対策は通常のプログラミングやサーバーサイドのセキュアプログラミングとは大きく異なる特殊な技術分野であり、専門的にこれにあたるエンジニアが必要になってきています。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
特集記事連載記事一覧

もっと読む

この記事の著者

舛形 謙介(サイファー・テック株式会社)(マスガタ ケンスケ)

 サイファー・テック株式会社 執行役員 / ソフトウェアエンジニア。2012年の入社以来、主にAndroidプラットフォームでセキュリティ関連の商品開発・サービス業務に従事し、現在はチート対策SDK「CypherGuard AppTrusty」の開発とクラッキング耐性診断サービス「Critical ...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/9638 2016/09/20 14:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー