クラックされないシェアウェアを作る Part2

自分なりに、少しまとめてみた。以下のようなことをされると自分としては趣味が失われて困る。

D: Developer, Difender, Shareware author
C: Cracker/Kracker, Reverser, Reverse code engineer, Atacker

１．C と D の pros/cons (Dの視点から)
− 概して D の数に比して C の数のほうが多い
− C ほうがよりハードウェアに近いレベルでのプログラミングに精通していることがしばしばある
＋ C はソースコードを持ってはいない
＋ C は常に受身にならざるを得ない(ex. 新バージョンのリリース)

２．対策
・評価版と製品版を完全に分離し、製品版は登録者のみに提供すること
　- 評価版に製品版の機能を残しておいてはいけない
・暗号系の使用（対称/非対称/hash等）
　- 少なくともキージェネレータ[keygen]を作らせない
・パッカーやプロテクター[packer/protector]の使用
　- 商用のものを使うと unpacker や deprotector が作られてしまう危険を考慮する必要あり
　- 独自に開発するのが望ましい
・オンライン認証
　- 可能ならば
・各種チェック（チェックサム、デバッガ、モニタリングツール、ローダー、パッチ等々）
　- どれだけやっても十分とうことはない
　- loader(memory patch) や patch も極力許さない
・シリアル番号形式でなくキーファイル等を使う
　- 入力は大きければ大きいほどほどよい
・登録者の識別は名前だけにせず、複数の要素を加味すること
　- マシン依存の要素を組み合わせて複雑にすること
　- シリアル集に止まっている日本では高い効果が期待できる

・難読化
　- HLL で読みやすいコードはアセンブリでも可読性が高いことが多い
　- .NET なら言わずもがな
・単一の実行ファイルにせず、複数のモジュールにして動作を許せる範囲で複雑にすること
　- 難読化と目的は同じ
・ダミーを入れる（特にキーチェック関数など）
　- 難読化の一環
・poly/metamorphic code、Slef-Modifing-Code の使用
　- 可能ならば
　- 各関数ごとに実行時 enc/dec 等もよい
・マルチスレッド化
　- 費用対効果高し
・登録情報は可能な限り分散し、わかり易いところに保存しない
　- debug されたとか、不正に使用したなどの情報もとっておくとよい
・プログラムで使用する文字列の簡単な暗号化
　- 文字列の参照による情報を与えない
・警告メッセージは表示しない
　- 趣旨は上に同じ
・ドングルの使用
　- シェアウェアでは無理だろう
　- 仮に使ったとしても、emulate されたりしたら意味がない

３．結論
CPUにコードを実行させる必要がある以上、ソフトウェア的な保護は究極的にいって不可能
HWレベルから保護することが望まれるが、突き詰めればそれも絶対ではない
可能な限り機構を複雑にしてクラッカーの手足を奪い、クラックされるのを引き延ばすこと
講じた引き延ばし策が、予定した次期バージョンのリリースまで功を奏すればよい
そして、常にその引き延ばし策が成功し続ければ、事実上クラックされないシェアウェアを作れたと考えてよいと思う