• Like
[CEDEC2012]ネットワークゲームの不正行為と対策
Upcoming SlideShare
Loading in...5
×

[CEDEC2012]ネットワークゲームの不正行為と対策

  • 280 views
Uploaded on

以前、CEDEC2012にて行われた、堀口 真司/池添徹による講演資料です。 …

以前、CEDEC2012にて行われた、堀口 真司/池添徹による講演資料です。
http://cedec.cesa.or.jp/2012/program/NW/C12_P0011.html

<セッション内容>

コンシューマゲームでのメモリ改変ツールの登場から、オンラインゲーム黎明期のチート手法や対策。
MMORPG でのチート行為とその影響から見る対策。
ブラウザ、モバイルになり変化していった手法からその対策を考えていきます。

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
280
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. ネトゲの不正行為と対策 繰り返されそうな?
  • 2. 自己紹介 ● 堀口真司 (Shinji Horiguchi) ● ネトゲ好き ● DQN ● 池添徹 (Toru Ikezoe) ● セキュリティ専門 ● DEFCON-CTF
  • 3. 不正行為ついて ● 汎用的なセキュリティ内容は扱いません ● 暗号化云々とか ● ハッシュ云々とか ● バッファオーバーラン云々とか ● アプリケーション固有の問題のみ扱いま す
  • 4. いわゆるチートとは ● ずるい行為 ● 他人からの視点で ● 主にネトゲで ● たぶん「裏技」ではない ● バグ技とも違う気がする ● 特殊な技術がいる
  • 5. 家庭用ゲームでのチート例 ● なんとかリプレイなど ● 変数の変化を捉えてアドレス調査 ● 値を書き換えてアイテム個数変更などなど ● 交換中に通信ケーブル抜くなど ● ポケモン増殖
  • 6. 90年代半ば、人気ネトゲ登場
  • 7. ネトゲ初期の症状 ● 超強いアイテムが蔓延してる ● キャラスペックもいじれる ● 高ステータスキャラ Lv 99
  • 8. ネトゲ初期の手法 ● セーブデータを変更するだけ ● 編集ツールがあったり ● セーブされる前に電源を抜くとか ● 対策 ● オンライン化 ● サーバ保存
  • 9. セーブデータ以外も狙われる
  • 10. ネトゲ初期の症状 ● ふつうに遊んでたらステータスが変わっ てる ● レベルが下がったり ● 装備やインベントリ内容が変わったり ● 見たことないモノがある ● しらない魔法やアイテム ● 存在しないはずのエリア ● いつもの倍速でゲームが進んだり ● 自分には心当たりがない。 x 2
  • 11. ネトゲ初期の原因 ● ホストプレイヤー上でメモリ書き換え ● ほかのプレイヤーの情報を書き換えできる ● そのままセーブされてしまうことも… ● 世界の状態も変えられる ● 対策 ● オンライン化、サーバ運営 ● 友達としか遊べないようにする
  • 12. 完全オンラインの時代 ここから21世紀
  • 13. 完全オンライン時代 ● しかしインターフェイスは小さい ● プロトコルとか API って言う
  • 14. RPG での症状 まずはクライアントの実装に問題がありそうな件
  • 15. 症状 ● 同アカウントの別キャラが分かる ● こっそりプレイが出来ない ● おおよそのログイン状態が分かる ● 粘着行為などの悪用に ● 登録時期が分かる ● その地域にいるモンスターの分布が分か る x10 x20 x1
  • 16. 原因 ● キャラ名問い合わせ API がある ● getName(0x1234) ● 値は登録時に連番で割り当てられている ● 戻り値に ID と名前があるので集める ● Id:0x1234,name:fizzbuzz ● 応答がないときはその地域に居ない ● 問い合わせに制限なし ● 問い合わせ API は要注意!
  • 17. 原因 ● 同じ API で Mob の名前も引ける ● getName(0x0011) ←低い値は NPC 用とか ● 連番なので数千個調べれば分布がわかる ● しかも値は敵毎に固定 ● ひとつの API を使いまわさない!
  • 18. RPG での症状
  • 19. 症状 ● 他のプレイヤーのレベルが分かる ● 名前と一緒にゲーム画面に表示できる ● 他のプレイヤーが使ったアイテムが分か る ● 残個数も分かる ● PvPやRvRで圧倒的に有利! foobar 62 x12
  • 20. 原因 ● 受信パケットにレベル値が含まれている ● パケット内の名前に文字列をくっつけて表示 ● name:“hoge”,lv:80 ● name=name+” ”+lvのように。 ● クライアントプログラム改造よりお手軽! ● アイテム利用パケットにも値が。 ● user:0x1234,type:10,quantity:5 ● 自分が使っても他人が使っても同じフォーマ ット
  • 21. RPG での症状
  • 22. 症状 ● 未鑑定のアイテムが何なのかわかる ● 未鑑定アイテムは中身は分からないが ● 地面に置くと鑑定済みとして表示される ● 選別でインベントリ節約 ● RPG では持ち物の量は意外と重要な要素
  • 23. 原因 ● 地面に置かれるアイテムパケットのフラ グ ● 受信パケット書き換えるだけ ● Identified:0 → 1 ● アイテムの構成要素も含まれる ● 可視化フラグのようなものは注意! ● アイテムは特に狙われやすい
  • 24. RPGやパズル系ゲームでの症状
  • 25. 症状 ● スキル利用時にオーバーキル/ヒール防止 ● 威力を抑える事でコストも抑える ● 威力の調整は普通にできるが、 ● モンスターの残りライフ計算は困難 ● ホールインワン。
  • 26. 原因 ● 受信するダメージパケットから敵のライ フ計算 ● 敵の最大ライフは統計を取る ● 与えたダメージの累積から残りライフを出す ● スキルパケットを送信するときに書き換 え ● target:0x1234,skill:5,lv:9 → lv:3 ● 計算すればよいだけの仕組みは要注意! ● 超強い AI とか、風向き計算してホールインワ ン
  • 27. RPGやFPSでの症状
  • 28. 症状 ● 壁に隠れた敵が見える ● 壁や草、木など消せる ● 広い範囲が見える ● カメラの距離や、視野角変更 ● FPSでは致命的、RPGでも擬態系で有利に
  • 29. 原因 ● プログラムを書き換える ● 描画関係のコードを nop で埋める ● 半透明にしたり Z バッファを OFF にしたり ● カメラの動きの制限解除 ● if の書き換え ● if の書き換えは歴史的にも多いので要注意 ● 各プレイヤー間の視線チェックもサーバで
  • 30. RPGなどでの症状
  • 31. 症状 ● なにも起こらない ● 普通なら盲目攻撃で画面が暗くなったり ● 混乱攻撃で画面がぐにゃぐにゃ ● 目の前にイカスミとか ぐにゃぐに ゃ
  • 32. 原因 ● 受信パケットを消す ● 多人数が集まるボス戦で他のプレイヤー消し たり ● 弱い効果に置き換えたり ● ゲーム要素に視覚効果を含めない ● 敵の座標を通常とは違う値を送る ● 盲目ならなにも送らない
  • 33. おもにRPGでの症状
  • 34. 症状 ● 未実装の敵やアイテムが見える ● パッチ内容を先取り ● 有名人に不適切な発言をさせる ● スクリーンショットを撮って掲示板などに載 せる ● 画像編集ツールを使うと JPEG 圧縮の癖などか ら鑑定師による判定を回避 見抜きいい? しかたないなぁ …
  • 35. 原因 ● 受信パケットを変更したり増やしたり ● say( 0x1234 , ”foobar” ) ● クライアントアプリに受信させる ● 未実装の敵に見た目を変更したり ● 敵の種類の数値を書き換え ● クライアントへの受信にも要注意!
  • 36. RPGでの症状
  • 37. 症状 ● 他人の会話が覗ける ● 他のギルド内の告知などが覗ける ● 恥ずかしい会話や、戦略的要素が分かる ! ○○したった! 今週は○○を攻めて、そのあと○○
  • 38. 原因 ● パケット内の固定長の文字列がある ● char msg[24]; ● “hello world” の後に “hi” を発言すると ● メモリ内では“hi0lo world”になるので ● 短い発言をすると他人の会話が取得できる ● パケットには隙間を作らない! ● パケット構築は慎重に ● 解析ツールで検出されるかも
  • 39. FPSでの症状 わりと最近
  • 40. 症状 ● 死体のまま動ける ● 死体のまま攻撃もできる ● 他人から見ると面白い ooOoOOOooO
  • 41. 原因 ● 受信パケの”撃たれたフラグ”を書き換え ● 自分のクライアントでは撃たれてないので ● そのまま動いたりできてしまう ● ちゃんとサーバにゲームロジックを書く
  • 42. ここからサーバ側の穴
  • 43. RPGでの症状
  • 44. 症状 ● すごく遠くの敵を攻撃できる ● 画面外プレイヤーから見ると勝手に敵が死ん だり ● 誰かに殺される ● PvP エリアで、なぜか死ぬ ● ゲームバランス崩壊… !?
  • 45. 原因 ● クライアントプログラムを書き換える ● if( distance < range ) ● → if( true ) ● サーバでチェックする ● 経路や障害物の判定は実装しにくいので、狙 われやすい
  • 46. RPGでの症状
  • 47. 症状 ● 敵が勝手に死ぬ ● 敵の持ち物が無くなっている ● 盗むスキルをやられずみ ● ダンジョンから倉庫を開ける ● 世界のバランスが崩れるほど。
  • 48. 原因 ● ひとつのサーバプロセスに複数の地域が ある ● 座標系は同じ。 ● 他の地域でも ID を指定して対象に ● アイテム盗むスキルは通用したり ● NPC と会話できたり ● アジトの奥の近接攻撃しか通用しない敵も同 じ ● 複数インスタンスを扱うときは要注意! ● まったく依存しないならプロセス分けよう
  • 49. RPGでの症状
  • 50. 症状 ● アイテムを増やせる。
  • 51. 原因 ● インベントリはスタックタイプ ● 10個あればx10みたいな表示 ● 0 個で分割するパケットを送る ● アイテムが増える。 ● たぶん if( request <= quantity) みたいな ● ゼロはもちろん、マイナスが通る事がある ● ゼロや符号に注意!
  • 52. RPGでの症状
  • 53. 症状 ● 頭が地面に落ちる。
  • 54. 原因 ● 頭などの体の一部もアイテム扱い ● “捨てる” パケット飛ばして ● 頭が地面に落ちる ● インベントリの0番が頭だったりする ● 通常のアイテムは10番以降など ● アバターアイテムは要注意!
  • 55. RPGでの症状
  • 56. 症状 ● 一度しか行えないクエストやり放題 ● おいしい報酬が何度ももらえる ● いらないアイテムを生産スキルの材料に ● 複数のアイテムを合成して、ひとつのアイテ ム ● ゴミが指定できる
  • 57. 原因 ● クエストはアイテム化されている ● パケット操作でクエストの取引ができる ● 1キャラ1個のクエストも捨てキャラから集め る ● ゲームデザインがアイテム中心すぎ ● 合成時はクライアントでのみチェック ● アイテム利用時はサーバでチェック
  • 58. RPGでの症状
  • 59. 症状 ● 任意の町やダンジョンにワープできる ● 本来なら有料のワープアイテムが必要 ● 未実装エリアにもいける
  • 60. 原因 ● 死ぬとセーブポイントに戻るが ● 戻り先を書き換えできる ● 有料アイテムと同じ実装 ● API の再利用は要注意!
  • 61. ちょっとだけ自動化の話
  • 62. ● 能力向上スキルの制限時間 ● ライフ減ったら回復アイテム利用 ● 相手や状態によって効果的な装備に変更 ● 閾値以下の売値の商品を購入 ● タイミング良く押す系のミニゲーム対応 ● FPS で攻撃が絶対に当たる ● 連射パッド、マクロツール
  • 63. 従来型のオンラインゲーム開発 で おすすめの方法 おまけ
  • 64. ● サーバだけ先に作る ● クライアントなんてテキストだけでいい ● プログラマもゲームデザインする ● ちょっとしたアイデアで破たんするんだよ ● プロセスを分ける ● fork、マルチスレッド絶対ダメ ● ラグとかは後で考える ● いきなりUDPとかありえん
  • 65. いまどきの話 ブラウザアプリ スマホアプリ サーバの傾向
  • 66. ブラウザ本体をいじる ● IE はすごい難しいが Opera なんかは簡単 ● オールドタイプ向け ● DLL インジェクションしたり ● 通信などをジャック ● スピードハックなどは Flash にも有効 ● 既存ツール流用
  • 67. ブラウザアプリ ● 変数の書き換えは特殊な技術いらず ● クライアント実装は JavaScript として、 ● F12 押してブラウザの機能だけでできる ● GUI でポチポチするだけ ● アドオンで色々できる ● テストツールを流用 ● Selenium など
  • 68. スマホも視野に ● NIC が2個あるノート PC など ● 有線と無線で NAT を組む ● 仮想 PC 使ってタダで構築 ● NAT を構築して ● hosts を書き換えたり ● iptables で向きを変える ● HTTP を ReverseProxy などでいじる ● HTTPS でも自前の証明書をインストール
  • 69. サーバ特性の傾向 ● フルスタック HTTP なソリューション増加 ● プロセス内に複数インスタンス ● プロセス寿命の増加 ● 非同期プログラミング ● WebSocket の常時接続 ● これらはオンラインゲーム構成に近い
  • 70. 10年代特徴
  • 71. ブラウザアプリ特徴 ● 送受信内容をいじる ● いままでより容易 ● クライアントアプリをいじる ● いままでより容易 ● アセットをいじる ● いままでより容易 ● 別インスタンスへの攻撃 ● いままでより容易
  • 72. ブラウザアプリ特徴 ● 自動化 ● いままでより容易 ● プログラム解析、パケット解析 ● いままでより容易
  • 73. スマホアプリ特徴 ● HTTP であれば、同じ方法で ● そうでない場合は root 奪取など必要 ● しかし家庭用ゲーム機よりはずっと楽 ● PC よりは面倒 ● 常時接続型+スマホアプリパッケージ ● いままでの PC オンラインゲームに似てる
  • 74. おさらい
  • 75. ● データ書き換えは簡単すぎるので常に意 識 ● パケットキャプチャしながら ● ブラウザのデバッガ見ながら ● DBとプロセッサ間の情報の流れを意識 ● マスター分割や、スレーブ遅延に注意 ● ぶっちゃけここがすべて
  • 76. ● 問い合わせ API ● API の使いまわし、再利用 ● 不要なデータ、データ間の隙間 ● disable/enable 系フラグ ● すばやく計算できたら有利になる要素 ● 経路や地形に依存する ● アイテムに多くの機能
  • 77. ● クライアントへの受信にも注意 ● 「え?こんなところまで?」 ● 出回っているツール類は高確率でウィル ス
  • 78. ありがとうございました