不正対策技術

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

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

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

**名前は開発中のものです。** · 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

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

**電脳プリオン** 【吉】【36.8m】 · 2013/04/01(月) 00:15:45.51

なぜC#？

**名前は開発中のものです。** · 2013/04/01(月) 06:15:25.17

糞コテ晒しage

**名前は開発中のものです。** · 2017/12/31(日) 20:33:39.48

簡単にお金が稼げる方法興味ある人だけ見てください。

グーグル検索⇒『来島のモノノリウエ』

WGXNVSTDUY