不正対策技術

**名前は開発中のものです。** · 2009/03/25(水) 04:53:05

バイナリやメモリの改変とかの不正に対する技術について。
とりあえずC#でお願いします。

例えばチェックサムとかでバイナリ改変チェックを入れたとして
そのチェック自体をバイナリ改変でスルーすることができると思いますが
その対策とかはあるのでしょうか？
おそらくどんな対策（nProにしても）も上級者には破られると思いますが
中級者くらいまで防ぐ目的でお願いします。

**名前は開発中のものです。** · 2009/03/25(水) 12:12:32

またしても、このまま何年も残るスレがここに誕生。

**名前は開発中のものです。** · 2009/03/25(水) 17:38:14

なぜC♯なのかと小一時間考えたが、理由が見つからなかった。

ハードウェア認証にすれば、コストはかかるけどほぼ破られないよ。
ソフトウェア的な対策では、すぐに破られるので、
ドングル使いましょう。

**名前は開発中のものです。** · 2009/03/25(水) 17:49:41

トングル使ってもチェックしてるのがソフトウェアだったら大して変わらんとおも

**名前は開発中のものです。** · 2009/03/25(水) 18:19:09

まずは C# 難読化で検索とかしたのか？

**名前は開発中のものです。** · 2009/03/25(水) 20:37:40

チートについて知りたいなら、まず自分でゲームのチートしてみれ。
バイナリ改変チェック、デバッガー感知、プロセスメモリ読み書き＆
メモリ（CODE）改変チェック、フック感知、プロセスリスト改変、SDT改変チェックetc

nProは実質rootkitだしえぐいことやってるけど、専用のサーバが必要だから
オンラインゲーム専用。

ソフトウェアセキュリティは、アプリ領域、カーネル領域に渡ってもう
何十年も議論されてることだから、やりだすときりがないよ。
パッキングやデバッガー感知程度じゃすぐ破られるからチート対策に
時間をかけるのは諦めてゲーム作りに注力しれ。

1 · 2009/03/26(木) 09:05:14

C#というのは現在作成しているものがそれだったからです。
難読化につきましては参考になりました。
チートについてはツールでメモリ変えたりとかくらいで
バイナリ改変とかはどこを変えればよいかは分かりません。
デバッガーで追って探すのかと思いますがよく分かりません。
あまり時間はかけたくありませんがミジンコ級＋αを排除するにあたって
バイナリ改変チェック、プロセスメモリ読み書き＆メモリ（CODE）改変チェック
あたりについて何かご教授ねがえませんでしょうか？

**名前は開発中のものです。** · 2009/03/26(木) 12:13:25

チートする旨みを無くせばいい。
個人ゲームの場合は、自らデータ改変ツールも配布するとか。

**名前は開発中のものです。** · 2009/03/26(木) 12:47:00

ゲームする旨みも無くなるな

**名前は開発中のものです。** · 2009/03/26(木) 13:15:07

たしか、webブラウザハッキングコンテストでランダムメモリになってるとむずいってあったな

**名前は開発中のものです。** · 2009/03/26(木) 13:32:02

チートを防ぐのは難しいが、チートする人間を分離するのはやりやすい

例えば全国対戦ゲームなら
チートや回線切りを繰り返すユーザーを懲罰マッチングに入れてしまう
もちろんそういう情報は公開しないし、判定はセンターサーバーにやらせる
kickは集団チーターに対処できないから駄目
垢削除もサブ垢を増やすだけなので根本的な解決とは言えない
違反者を知られぬように隔離するのが有効
なぜなら、チートをしないまっとうなユーザーを守れれば目的は達成されるから

こういう風に考え方を変えないと、作業量が多くなりすぎてゲーム製作自体が成り立たなくなると思う

**名前は開発中のものです。** · 2009/03/26(木) 20:01:27

>>11
>>違反者を知られぬように隔離する
いいアイディアだな

**名前は開発中のものです。** · 2009/03/26(木) 23:32:51

めちゃくちゃうまい人が誤って入っても、俺より強い奴がまだ居るんだなと練習し続けるかも名

**名前は開発中のものです。** · 2009/03/28(土) 01:58:28

>7
同人レベルのオフラインゲーならチート対策なんかに労力使わないほうが
いいと思うけどね。まぁちょっとだけ書いとく。
チートは基本アセンブラだから、開発言語は関係ない。ランタイムにちょっと
癖があるかもだけど。

・バイナリ改変、デバッグ起動対策→パッキング
　asprotect や upx なんかをぐぐれ。exe をパッキングするだけ。

・デバッグアタッチ対策→ IsDebuggerPresent() (kernel32.dll) をスレッドで
　常時回してチェック。olly等のアプリデバッガーに有効。カーネルデバッガには効かない。
　また、普通の解析者ならこの関数callはすぐ潰すので気休め程度。
　少し気合いれるなら、ゲームプロセスを2つに分けて親プロセスから子プロセスを
　デバッグアタッチしてしまうことで、他からのデバッグを防ぐことも可能。
（続く）

**名前は開発中のものです。** · 2009/03/28(土) 02:00:03

・プロセスメモリ読み書き対策→プログラムで工夫
　チートする場合、うさみみハリケーンのようなツールでゲームパラメータの数値をサーチし
　プレイヤーのＬｖ値やらなにやらを割り出してメモリを書き換えるのが一番簡単。
　外部プロセスからのReadProcessMemory/WriteProcessMemoryを阻止するのは
　困難なので（グローバルフックやシステムコール改変が必要）、プログラムで工夫する。

　例えばC#で、プレイヤーのクラスがあったら
　public class PlayerInfo {
　　int m_key = 0xe6c5b4a3;
　　int m_exp = 0 ^ m_key;
public int getExp(){ return (m_exp ^ m_key); }
　　public void addExp(int num){
m_exp = (num + getExp())^ m_key;
}
}

　こんな感じで、メモリ上にパラメータを生で持たせないようにすれば、
　外部ツールで経験値の値をメモリ検索されてもすぐには割り出せなくなる。
　ミジンコ程度なら防げるだろう。

やりだすときりがないから。
フリーや同人ゲーのチート対策は労力に見合わないよ。

1 · 2009/03/28(土) 09:11:53

詳しくありがとうございます。
こちらもいろいろ調べましてパッキングとか
デバッグアタッチしておくとかプロセス一覧から隠すとか
やってみたところです。
プロセス一覧から隠すのがかなりあやしいですが・・
あとパラメータを生で持たせないようにするってのも入れてみたいと思います。
とりあえずこれで対策は一段落つきました。
いろいろ参考になる意見ありがとうございました。

**名前は開発中のものです。** · 2009/03/28(土) 09:58:56

チートに関しては「チートされて損をするか？」って議論も必要

例えば会社が作るオンラインゲームなら、チート対策は必須だろう
課金システムを改変されたりしたら大損、BOTなどの使用はユーザーを減らすし、
対戦でチートを使われるだけでもプレイヤーの顰蹙を買う

逆に、個人で作るゲームやオフラインゲーム、アーケードのオンラインゲームは気を使わなくてもいい
チートをやったところで誰かに迷惑をかけるわけではないし
アーケードゲームならば、チートをやった店に懲罰が降りかかるので、違反が限りなく起こりにくい

チート対策にコードを書いたり、監視スレッドを走らせたりすると、ゲーム自体の挙動が遅くなる恐れがある
データの保護に暗号化などを使っても同じ
ゲームを守るために面白さが犠牲になってしまっては意味がないということ
「その対策は本当に必要か？」という議論を常にやってほしい

**名前は開発中のものです。** · 2009/03/28(土) 12:10:58

>>17
同感。
また徒に対策を強化することで、かえって対抗心を煽るってケースもあるしな。
チートすることよりもプロテクトを破ることに燃えられては、ますます無意味。

**名前は開発中のものです。** · 2009/03/28(土) 16:27:27

チートって攻撃力とかパラメータの数値をイジルだけ？
たとえば、こういうゲームはチートできるの？
http://d.hatena.ne.jp/ku-ma-me/20081216

**名前は開発中のものです。** · 2009/03/29(日) 00:14:00

>>19
おもろいねこれ。
チートはできるよ。
Life10の数値をLife1万とかにすればゲームバランスくずれちゃうでしょ。

**名前は開発中のものです。** · 2009/04/06(月) 21:58:18

毎フレーム数値をチェックして本来変化するわけのないタイミングで数値が変化したらエラー吐いて強制終了とか効かないかなぁ

**名前は開発中のものです。** · 2009/04/07(火) 01:05:27

>>21
デバッガでエラー用文章を参照している部分を検出されたらアウト
もしくは、終了処理から辿られてもダメ
たぶんほとんど効かないと思うよ

**名前は開発中のものです。** · 2010/04/24(土) 01:16:22

宮島

**名前は開発中のものです。** · 2010/05/09(日) 15:32:46

あ

**名前は開発中のものです。** · 2010/05/10(月) 00:40:18

ピドさん、まだいたのか。最近どうよ？

**名前は開発中のものです。** · 2011/01/21(金) 19:59:44

知識もないのに言語指定する>>1が立てるスレにロクなのがあったためしがない。

**名前は開発中のものです。** · 2011/04/08(金) 00:10:20.62

ちょっといいか？
プログラムの最初に乱数出してその数だけ変数作ったらどうなるんだ？
これでランダムアドレス作れねーかな

**名前は開発中のものです。** · 2011/04/08(金) 11:43:27.59

その乱数を求めるルーチンをクラックされて終了だと思う・・・。

**名前は開発中のものです。** · 2011/04/10(日) 09:18:47.29

ランダムジェネレータに /dev/random とか使えばいけるし、
現代ではごく普通に知られているアイディア。
http://en.wikipedia.org/wiki/Address_space_layout_randomization

**名前は開発中のものです。** · 2011/04/10(日) 10:59:25.04

アホなの？それとも本気で言ってるの？
乱数の質が問題なんじゃねえんだよ。
アプリ内にせよOSやCPUが提供するものにせよ、アプリ内の乱数ジェネレータにアクセスする部分のコードをバッサリと削除or改変して、変数領域が常に同じ場所に留まるようにされたらそれまでだろうが。
仮に、それを検出するコードを付加したところで、さらにその部分を探し出してクラックされたらそれまでだ。

そもそも、PS3のCellのSPEのアイソレーションモードみたいな例外を別にすれば、殆どの汎用CPUは、プロセスを完全に外部から保護・隠蔽する手段がない。
たとえ、不正対策ルーチンを一般のプロセスより上位に持って行こうと、カーネルデバッガで追われたらそれまでだ。
ローカルで処理する限り、クラッカーに手がかりを与えないことなど原理的に不可能だ。

変数領域を動かすなんてチンケな手法は、昔から普通に実装されていて、そして普通にクラックされまくりなんだよ。
市販の改造ツールで解析ごっこしてる素人に対する目眩まし程度にはなっても、本気でクラックしてる奴には何の障害にもならん。

**名前は開発中のものです。** · 2011/04/10(日) 11:00:09.48

訂正
＞アプリ内の乱数ジェネレータにアクセスする部分のコードを
アプリ内から乱数ジェネレータにアクセスする部分のコードを