SlideShare a Scribd company logo
一般的なチートの
手法と対策について
黒河 優介
本日のアジェンダ
•チート行為そのものについて簡単な説明
•チートの一般的な手法の紹介とその対策
チートとは…
• ゲームを優位に進めるため、制作者の意図しない動作をさせる不正
行為
• 特にオンラインゲームが主流になってきた昨今では、他のプレイ
ヤーやゲーム運営会社に対して損害を与えることがあり問題になっ
ている
• 対戦型のオンラインゲームではチートをして、ズルをするプレイヤーと対戦し
ても不快な気持ちになるだけです。
• 基本無料で遊べるゲームでは、強いキャラクターを押し出したガチャを売上
の基本としている事が多いが、そのキャラクターを不正に入手/弱いキャラを
無理やり強くする等が出来てしまうと売上が立ちにくく問題となってしまう。
被害の例を簡単にご紹介
チートしている人と対戦すると…
4人で対戦中
俺様の攻撃は、100%命中するぜ!
物陰に隠れても無駄だ!!
他のプレイヤーの気分が害される
楽勝、楽勝!
よくわからない
けど、ボコボコ
にされた…。
アイツの動き
おかしくね?
チートじゃね?
もう辞めようか
な…このゲーム。
オンラインランキングがあっても萎えるだけ…
Score:9999999
Score:100320
Score:100110
ズルしてスコア
書き換えちゃえ!!
上の奴どうみても
チート…萎えるわ…
本来の一位って
俺じゃね…
ゲーム運営も困る…
今ならガチャに
良い娘いますよ!
チートすれば手に入
るから、ガチャなんて
引かないぜ!
ゲーム運営も困る…
売り上げが・・・・
このような感じで、他のプレイヤーや運営が
損害を受けるチート行為…。
じゃあ、一体どうやっているのか?
いくつか良くあるパターンを紹介します
一般的なチート手法
•通信データを偽装する
•メモリの中身を書き換える
•プログラムそのものを改ざん
通信データを偽装する
通信データを偽装する
• 通信対戦や、オンラインランキングでも、プレイヤーはサー
バーにデータを通信することで自身のステータスを送ってい
ます。
• 通信対戦では操作しているキャラクターの状態や他プレイヤーへの攻撃等
をメッセージとしてサーバーに送信しています
• オンラインランキングではスコアをサーバーに送信しています
• ソーシャル系ゲームなどでは、サーバーから受信してくるデータをクライアン
トに届く途中で書き換えて所持キャラクターを偽装します
※話を簡潔にするためにP2P通信モデルの話はおいておきます
つまり何が言いたいかというと…
• ゲームアプリケーション以外からサーバーに対してデータを
送る事も可能
• サーバーに嘘の情報を送るプログラムを作ってしまえばチートで
きる!
• サーバーから来たデータを書き換えてゲームアプリケーショ
ンに届けることも可能
• サーバーから来たデータを途中で書き換えてしまえばチートでき
る!!
通信対戦での例
通信対戦での例
各プレイヤーはサーバーを
介して通信対戦を実現して
いる想定です
プレイヤーA
プレイヤーB
プレイヤーC
プレイヤーD
※処理の流れはイメージです。
通信対戦での例
「プレイヤーBを狙撃して倒
しました」というデータを
サーバーに送ります
(本当は狙撃してないけど)
プレイヤーA
プレイヤーB
プレイヤーC
プレイヤーD
通信対戦での例
「プレイヤーAがプレイヤーB
を狙撃して倒しました」と言
うメッセージを各プレイヤー
に送ります。
プレイヤーA
プレイヤーB
プレイヤーC
プレイヤーD
通信対戦での例
プレイヤーA
プレイヤーB
プレイヤーC
プレイヤーD
プレイヤーAから送られてきた偽装
データにより、プレイヤーBが倒された
ことになります。
オンラインランキングの例
オンラインランキングの例
プレイヤーC
各プレイヤーはサーバーにスコア
データを送信し、サーバー内の
データを書き換えることによって、
オンラインランキングが実現して
います
プレイヤーD
■スコアデータ
プレイヤーC:211200
プレイヤーD:198800
オンラインランキングの例
プレイヤーA
プレイヤーAがスコアを 9999999
取ったというデータを送ります
■スコアランキング
プレイヤーC:211200
プレイヤーD:198800
オンラインランキングの例
プレイヤーA
プレイヤーAがスコアを 9999999
取ったというデータを受け取り、そ
れを元にランキングデータの書き
換えを行います
■スコアランキング
プレイヤーA:9999999
プレイヤーC:211200
プレイヤーD:198800
受信データ偽装の例
受信データ偽装の例
プレイヤーA
特にスマートフォンなどのソーシャルゲームでは、
プレイヤーのセーブデータはサーバー上にあり、
ログイン時などにプレイヤーデータを一括で取得す
る傾向にあります
■プレイヤーAの所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1
受信データ偽装の例
プレイヤーA
プレイヤーAがログインし、
サーバーに自身の持っている
所持キャラクターの情報を要
求します
(この段階では悪いことはして
いません)
■プレイヤーAの所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1
受信データ偽装の例
プレイヤーA
サーバーはプレイヤーAの
データを読み込み、それを送り
ます
■プレイヤーAの所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1■所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1
受信データ偽装の例
プレイヤーA
プレイヤーAの実行端末に
データが届く前にデータを書
き換えます
■プレイヤーAの所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1■所持キャラ
レア1 Lv99
レア2 Lv99
レア3 Lv99
受信データ偽装の例
プレイヤーA
プレイヤーAは所持していない
はずのキャラクターをゲットし
てしまいます
■プレイヤーAの所持キャラ
雑魚1 Lv1
雑魚2 Lv1
雑魚3 Lv1
■所持キャラ
レア1 Lv99
レア2 Lv99
レア3 Lv99
以上
通信データ偽装による例でした
何がよくなかったのか?
•そもそも、ゲームのアプリケーションプログラム
以外からサーバーに直接データを送信されてし
まうのが問題だった。
•ゲームのアプリケーションプログラムとサーバー
間での通信を書き換えられてしまったのが問題
だった
じゃあどうすれば良かったのか?
•ゲームアプリケーションから送信されたデータで
あることを保証する仕組み
•ゲームアプリケーションとサーバー間でデータ
が改竄されたことを検知する仕組み
これは、ハッシュの仕組みを使
えば出来ます!!
ハッシュ値チェックとは?
• ファイルの破損が起きていないか等で利用される仕組み
• データの塊から特定のアルゴリズムを利用し、ハッシュ値を生成
する
• データとハッシュ値をペアで配布し、データから再度ハッシュ値を
求めて、一致していたらデータの破損なく配れたと認識する仕組
み
ハッシュ値のイメージ
00 00 00 00 FF 0E 21 EE
FF 0E 21 EE D4 00 00 00
A0 00 00 00 00 00 00 00
FF 0E 21 EE FF 0E 21 EE
D4 00 00 00 A0 00 00 00
00 00 00 00 FF 0E 21 EE FF
0E 21 EE D4 00 00 00 A0
21 EF E1 D4 A0 28 B2 C1
データ
ハッシュ値
CRC/MD5/Sha1
などのアルゴリズムで生成
ハッシュ値チェックのイメージ
00 00 00 00 FF 0E 21 EE
FF 0E 21 EE D4 00 00 00
A0 00 00 00 00 00 00 00
FF 0E 21 EE FF 0E 21 EE
D4 00 00 00 A0 00 00 00
00 00 00 00 FF 0E 21 EE FF
0E 21 EE D4 00 00 00 A0
21 EF E1 D4 A0 28 B2 C1
データ
ハッシュ値
データとハッシュ値をペアで送信
受け取った側はデータからハッシュ値を再計
算して、整合性のチェックを行う
データ書き換えが発生した場合
00 00 00 00 FF 0E 21 EE
FF 0E 21 EE D4 00 00 00
A0 00 00 00 00 00 00 00
FF 0E 21 EE FF 0E 21 EE
D4 00 00 00 A0 00 00 00
00 00 00 00 FF 0E 21 EE FF
0E 21 EE D4 00 00 00 A0
21 EF E1 D4 A0 28 B2 C1
00 00 00 00 FF 0E 21 EE
FF 0E 21 EE D4 00 00 00
A0 AA 00 00 00 00 00 00
FF 0E 21 EE FF 0E 21 EE
D4 00 00 00 A0 00 00 00
00 00 00 00 FF 0E 21 EE FF
0E 21 EE D4 00 00 00 A0
DE AD C0 DE D0 18 21 B1
データ書き換え
発生
送信した
データ
受信した
データ
セットで送信したハッシュ値
21 EF E1 D4 A0 28 B2 C1
セットで送信されたハッシュ値
ハッシュ値計算
ハッシュ値が送られてきたも
のと違う!!
という事は書き換えが発生!
つまり、ハッシュ値チェックを使うと?
• ゲームアプリケーションとサーバー間のデータ間のデータ書
き換えが防げる
• ゲームアプリケーションの中にあるハッシュ値の生成法が
わからなければ、偽装データを作っても、一致するハッシュ
値を作れないのでうまくデータを作成できない。
※ハッシュ値生成には、HMAC-SHA1などのキーを利用した生成アル
ゴリズムを使うとよいでしょう
オンラインランキングの例
プレイヤーA
プレイヤーAがスコアを 9999999
取ったというデータを送ります
適当なハッシュ値
オンラインランキングの例
プレイヤーA
このデータはハッシュ値が正しくあ
りません。
チートですか?
どうなるかというと・・
チーター
ぐぬぬぬぬ・・・・。
どうしたらハッシュ値が出来る
かわからない…。
メモリの中身を書き換える
メモリの中身を書き換える
•プレイヤーキャラクターのHPなどの情報は、メモ
リ上にあるデータを読み書きすることで実現して
います
• もし、ゲームプログラマーの預かりしれぬ所でメモリの中
身を置き換えられてしまったら、キャラクターのステータス
はトンデモナイ事になってしまうかもしれません。
メモリ書き換えのイメージ
160/212
攻
撃
防
御
技
※RPGっぽいゲームだと思ってください
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
D4 00 00 00
A0 00 00 00
メモリイメージ
メモリ書き換えのイメージ
160/212
攻
撃
防
御
技
※RPGっぽいゲームだと思ってください
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
D4 00 00 00
A0 00 00 00
メモリイメージ
160
212
4byte (int)区切りで、
16進数→10進数変換
メモリ書き換えのイメージ
160/212
攻
撃
防
御
技
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
D4 00 00 00
A0 00 00 00
メモリイメージ
160
212
HPの数値はメモリ上に
存在している
メモリ書き換えのイメージ
160/212
攻
撃
防
御
技
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
D4 00 00 00
A0 00 00 00
メモリイメージ
HPっぽい場所発見~
メモリ書き換えのイメージ
160/212
攻
撃
防
御
技
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
E7 03 00 00
E7 03 00 00
メモリイメージ
メモリを書き換えて、
HPを増やしてしまえ!
メモリ書き換えのイメージ
999/999
攻
撃
防
御
技
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
0F 27 00 00
0F 27 00 00
メモリイメージ
999
999
HPが増えたぜ!!
何がよくなかったのか?
•メモリ上に生の数値をおいてしまっていたため、
どこを書き換えるとよいかバレてしまった
じゃあどうすれば良かったのか?
•メモリ上にintなどのデータを置くときは暗号化し
ておきましょう
•必要なタイミングで復元化・暗号化して書き戻しを
行う
•xor(排他的論理和)の性質をうまく使うと楽にコード
が書けます。
•A xor B => C , C xor B => A
こんなコードを用意します
class EncryptInt{
const int key = 0x2f4f7fe5;
int value;
public int setValue(int v){ value = v^key;}
public int getValue(){ return value ^ key; }
}
HPなどの情報を intから、このようなコードに置き換えることで可能
メモリを暗号化しておく
160/212
攻
撃
防
御
技
00 00 00 00
FF 0E 21 EE
FF 0E 21 EE
DE AD C0 DE
32 AD C0 DE
メモリイメージ
HPの数値は暗号化し
てメモリに置く
ぐぬぬぬ・・・。
HPが見つからない…。
以上
メモリ改竄による例でした
プログラムそのものを改ざん
プログラムそのものを改竄
•実行ファイルも結局は 0・1であらわされたデー
タでしかない
•ディスアセンブルすればアセンブリコードが出てく
る
•これを改造してしまえば、ゲームの挙動も変えられ
てしまう…
しかしアセンブリ書き換えまでやってくる
猛者は超絶少ない…
※凄く売れると話は違ってきますが…
その時はマネーパワー使って、専門の会社に相談を…
ただし、JavaやC#で書かれたゲーム
おめえは別だ!!
C#/Javaは別な理由
• C++やC言語はアセンブリにした時点で変数名や関数名など
の情報が欠落する
• なので、アセンブリからC言語に戻しても意味不明なソースが出来、
解読が非常に困難になる
• C#やJavaではVM用の中間コードが吐き出されるが、それに
は変数名や関数名などの情報が含まれている(Reflection
用)
• その中間コードをそのまま実行する形になっている
• そのため、C#やJavaの中間コードからは、C#やJavaのオリジナル
ソースがかなりの再現率で復元できてしまう…。
C#やJavaでの対策例①
•C#やJavaの中間コードを暗号化+改竄チェック
のためにHash化しておく
•実行中に暗号化された中間コードを読み込んで、プ
ログラムとして実行可能なように動的にリンクする
ですが、読み込むためのプログラムとかもJavaで書いてしまうと、そこを狙われがちに…。正直、マネーパワー使って専用の会社に・・・ry
C#やJavaでの対策例②
•C#やJavaの中間コードにある関数名/変数名を
グチャグチャに書き換える難読化をする
以上
プログラム改竄による例でした
他にも…
•セーブデータ改造
•ゲームデータ書き換え
等々…
いろいろありますが、基本的にハッシュによる署名、暗号化で大分
ガードできます
最後に…
• チートはいろいろなやり方があります。
• 対策の基本的な考え方は、ハッシュ値チェックによる改竄防止と暗
号化による解析防止を押さえておけば大分カバー出来る
• チートする側もあの手この手を使って破ってきます。
• ガードしてても破られるけど、ノーガード戦法なんてのはない!

More Related Content

一般的なチートの手法と対策について