5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

不正対策技術

1 :名前は開発中のものです。:2009/03/25(水) 04:53:05 ID:DQcGtJGv
バイナリやメモリの改変とかの不正に対する技術について。
とりあえずC#でお願いします。

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


2 :名前は開発中のものです。:2009/03/25(水) 12:12:32 ID:23oJFWZJ
またしても、このまま何年も残るスレがここに誕生。

3 :名前は開発中のものです。:2009/03/25(水) 17:38:14 ID:zdTg+CO8
なぜC♯なのかと小一時間考えたが、理由が見つからなかった。

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

4 :名前は開発中のものです。:2009/03/25(水) 17:49:41 ID:Z98x9JtB
トングル使ってもチェックしてるのがソフトウェアだったら大して変わらんとおも

5 :名前は開発中のものです。:2009/03/25(水) 18:19:09 ID:ME26m55j
まずは C# 難読化 で検索とかしたのか?

6 :名前は開発中のものです。:2009/03/25(水) 20:37:40 ID:wUjBbi10
チートについて知りたいなら、まず自分でゲームのチートしてみれ。
バイナリ改変チェック、デバッガー感知、プロセスメモリ読み書き&
メモリ(CODE)改変チェック、フック感知、プロセスリスト改変、SDT改変チェックetc

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

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


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


8 :名前は開発中のものです。:2009/03/26(木) 12:13:25 ID:i3D+XMq7
チートする旨みを無くせばいい。
個人ゲームの場合は、自らデータ改変ツールも配布するとか。

9 :名前は開発中のものです。:2009/03/26(木) 12:47:00 ID:bDTwkiY2
ゲームする旨みも無くなるな

10 :名前は開発中のものです。:2009/03/26(木) 13:15:07 ID:8D1MhSXx
たしか、webブラウザハッキングコンテストでランダムメモリになってるとむずいってあったな

11 :名前は開発中のものです。:2009/03/26(木) 13:32:02 ID:iTPUhNHi
チートを防ぐのは難しいが、チートする人間を分離するのはやりやすい

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

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


12 :名前は開発中のものです。:2009/03/26(木) 20:01:27 ID:FCkzqPlt
>>11
>>違反者を知られぬように隔離する
いいアイディアだな

13 :名前は開発中のものです。:2009/03/26(木) 23:32:51 ID:8D1MhSXx
めちゃくちゃうまい人が誤って入っても、俺より強い奴がまだ居るんだなと練習し続けるかも名

14 :名前は開発中のものです。:2009/03/28(土) 01:58:28 ID:VmnRmpjg
>7
同人レベルのオフラインゲーならチート対策なんかに労力使わないほうが
いいと思うけどね。まぁちょっとだけ書いとく。
チートは基本アセンブラだから、開発言語は関係ない。ランタイムにちょっと
癖があるかもだけど。

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

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


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

・プロセスメモリ読み書き対策→プログラムで工夫
 チートする場合、うさみみハリケーンのようなツールでゲームパラメータの数値をサーチし
 プレイヤーのLv値やらなにやらを割り出してメモリを書き換えるのが一番簡単。
 外部プロセスからの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;
}
}

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

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

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


17 :名前は開発中のものです。:2009/03/28(土) 09:58:56 ID:dcf96ssf
チートに関しては「チートされて損をするか?」って議論も必要

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

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

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


18 :名前は開発中のものです。:2009/03/28(土) 12:10:58 ID:PoTwSL3E
>>17
同感。
また徒に対策を強化することで、かえって対抗心を煽るってケースもあるしな。
チートすることよりもプロテクトを破ることに燃えられては、ますます無意味。

19 :名前は開発中のものです。:2009/03/28(土) 16:27:27 ID:r7XGExcp
チートって攻撃力とかパラメータの数値をイジルだけ?
たとえば、こういうゲームはチートできるの?
http://d.hatena.ne.jp/ku-ma-me/20081216

20 :名前は開発中のものです。:2009/03/29(日) 00:14:00 ID:XYxGas62
>>19
おもろいねこれ。
チートはできるよ。
Life10の数値をLife1万とかにすればゲームバランスくずれちゃうでしょ。

21 :名前は開発中のものです。:2009/04/06(月) 21:58:18 ID:7OvX1Q9e
毎フレーム数値をチェックして本来変化するわけのないタイミングで数値が変化したらエラー吐いて強制終了とか効かないかなぁ


22 :名前は開発中のものです。:2009/04/07(火) 01:05:27 ID:YsFjy+bQ
>>21
デバッガでエラー用文章を参照している部分を検出されたらアウト
もしくは、終了処理から辿られてもダメ
たぶんほとんど効かないと思うよ

23 :名前は開発中のものです。:2010/04/24(土) 01:16:22 ID:9G78iIee
宮島

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


25 :名前は開発中のものです。:2010/05/10(月) 00:40:18 ID:DZxYnn6i
ピドさん、まだいたのか。最近どうよ?

26 :名前は開発中のものです。:2011/01/21(金) 19:59:44 ID:U+ZAaHOJ
知識もないのに言語指定する>>1が立てるスレにロクなのがあったためしがない。

27 :名前は開発中のものです。:2011/04/08(金) 00:10:20.62 ID:Er/SZGT/
ちょっといいか?
プログラムの最初に乱数出してその数だけ変数作ったらどうなるんだ?
これでランダムアドレス作れねーかな

28 :名前は開発中のものです。:2011/04/08(金) 11:43:27.59 ID:s8IM5VZ3
その乱数を求めるルーチンをクラックされて終了だと思う・・・。

29 :名前は開発中のものです。:2011/04/10(日) 09:18:47.29 ID:C/1vZ/r2
ランダムジェネレータに /dev/random とか使えばいけるし、
現代ではごく普通に知られているアイディア。
http://en.wikipedia.org/wiki/Address_space_layout_randomization

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

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

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

31 :名前は開発中のものです。:2011/04/10(日) 11:00:09.48 ID:HSWES0Pp
訂正
>アプリ内の乱数ジェネレータにアクセスする部分のコードを
アプリ内から乱数ジェネレータにアクセスする部分のコードを

11 KB
■ このスレッドは過去ログ倉庫に格納されています

★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)