INT3(CC)のカウント(デバッガ対策)
伊能忠敬 2013/5/27(Mon) 00:47:34|NO.54339
INT3(CC)のカウント(デバッガ対策)を作成しております。
ブロック崩しを作成しているのですが
ゲームの中身を解析されることを防止するために
INT3をカウントしてその値が増加してたらプロセスを終了するようなものを作りたいのですが
どのようなソースを書けばいいのかわかりません。。
デバッガでブレークポイントを張ると張ったところにはINT3が代入されます(バイナリでC3)
ブレークポイントを張られたことを検出したいのですが
どうしたらいいでしょうか?
晩御飯 2013/5/27(Mon) 11:03:19|NO.54350
>デバッガでブレークポイントを張ると張ったところにはINT3が代入されます(バイナリでC3)
デバッガがバイナリを書き換えるのか?
伊能忠敬 2013/5/27(Mon) 11:33:19|NO.54351
はい。バイナリC3を書き込むことでデバッグ割り込みを入れる事が可能です。
つまりブレークポイントを設置したらバイナリC3が
プロレスメモリに一つ追加されます。
ブレークポイント検出するにはこのC3の数をかぞえて
増加してたらブレークポイントが設置されてることになります
さすがにこのソースを組める人はいないかなあ…
自分のツールのデータを改造されたり不正に使われるのは
どうしても防ぎたいものです、、
ht. 2013/5/27(Mon) 11:54:21|NO.54353
int3を検出するのは可能ですがHSPのようなインタプリタではほとんど無意味だと思います。
逆アセンブルするまでもなくHSPのソースコードの解析が可能ですので。
ゲームの改造を防ぐのは不可能と割り切った方がいいです。
KA 2013/5/27(Mon) 12:03:18|NO.54354
そのバイナリを直接解析される事は、考えなくても良いのですか。
伊能忠敬 2013/5/27(Mon) 15:14:39|NO.54355
htさん
逆コンパイルのことですかね??
確から逆コンパイル対策もできたとおもうんですが…
どうなんでしょうか…
KAさん
それはAPIを駆使して対策していくつもりです!
後CRCチェックとかも導入したいですね…。
ちなみにCRCチェックとは
プロセスメモリが改竄されてないかのチェックを行うことです!!
ht. 2013/5/27(Mon) 15:49:54|NO.54357
int3とかCRCとか名前を聞いただけで肝心なところで知識が抜け落ちているような気がします。
> 確から逆コンパイル対策もできたとおもうんですが…
HSPはソースコードをstart.axという命令群に圧縮してそれを読みながら実行します。
そしてHSPはオープンソースなのでその復号化も原理的に丸分かりというわけです。
PCで実行できる=PCで解析できる というのは覆しようのない事実です。
クラックされる可能性を少しでも減らしたいならまずはCなど他の言語で書くのが前提条件です。
> 後CRCチェックとかも導入したいですね…。
現実的に行けば所持金などのパラメータから任意の数nを減算したダミーを用意して
チェック時に演算が一致しないと誤動作を起こすなどですかね。
即興で思いついたんですがこれは中々コスパも良さそう。
伊能忠敬 2013/5/27(Mon) 19:46:55|NO.54369
ht.さん
> 確から逆コンパイル対策もできたとおもうんですが…
HSPはソースコードをstart.axという命令群に圧縮してそれを読みながら実行します。
そしてHSPはオープンソースなのでその復号化も原理的に丸分かりというわけです。
PCで実行できる=PCで解析できる というのは覆しようのない事実です。
クラックされる可能性を少しでも減らしたいならまずはCなど他の言語で書くのが前提条件です。
ふむふむ。。
確かに逆コンパイル防止はできるけど
完全には阻止できないですよね、やっぱり。
> 後CRCチェックとかも導入したいですね…。
現実的に行けば所持金などのパラメータから任意の数nを減算したダミーを用意して
チェック時に演算が一致しないと誤動作を起こすなどですかね。
即興で思いついたんですがこれは中々コスパも良さそう。
なるほどー!
なかなかいいアイデアですね!
試しにいろいろやってみることにします^^
ありがとうございます
ZAP 2013/5/27(Mon) 20:02:24|NO.54371
思わず解析したくなるような新技術やアイデアが詰まった
今まで見たこともないブロック崩しが完成するのですね!
ちょっと期待しています。
コンテスト辺りで出るのかな?