リバースエンジニアリングとプロテクト開発のココが熱い！
耐タンパー（アンチクラック, アンチリバースエンジニアリング）と難読化を流行らせるにはどうすればいいか、一考してみました。とりあえずリバースエンジニアリングとか、プロテクト開発、難読化の何が熱いのか少し書きつづってみます。
果てのない戦いである
よく言われますが、リバースエンジニアリングとアンチリバースエンジニアリングはいたちごっこです。プロテクトが破られれば終了、ソフトウェアのバージョンアップによってプロテクトもバージョンアップし、戦いは再開する。プロテクトが破られないようにする方法といえば、破られた部分を修正するか、より強固なプロテクトを増やすなどなど。きりがありません。
また、ソフトウェアをネットワーク経由で逐次バージョンアップできる場合（例えばネトゲとかDRM）、戦いはより長く続きます。プロテクトを破る側とかける側で切磋琢磨してプロテクトをかける技術と破る技術が進歩していきます（たぶんね）。その進歩にどんな意味があるのか私にはわかりませんが。
相手の裏をかく戦略
リバースエンジニアはプロテクト／耐タンパーの様々な手法を知っています。これを知ることでプロテクトを破ったり、コードを明らかにしていくことが可能になります。
プロテクト／耐タンパー技術の開発者もリバースエンジニアリングの手法を知っています。これまた同様に、これを知ることで、プロテクト／耐タンパー技術の開発が可能になります。
耐タンパーはリバースエンジニアの裏をかくことにあります。そしてまたリバースエンジニアも、プロテクト／耐タンパー技術の裏をかいてプロテクトを無効化します。如何に楽をして目的*1を達成するか、リバースエンジニア対プロテクト開発者の心理戦です。プロテクト開発も解析のどちらも結構アイディア勝負なところがあります。非常に熱いです。
時と場合による
ある時、リバースエンジニアは攻める側です。リバースエンジニアは好きなときに好きなだけソフトウェアを解析できます。プロテクト開発者は、リリースしたソフトウェアをリモートから守ることは困難です。この場合明らかにリバースエンジニア側が有利で、プロテクト開発者側は不利です。
またある時は、リバースエンジニアは受け身です。頻繁に更新されるソフトウェアすべてに対して解析する必要がある場合、リバースエンジニアは受け身となってしまいます。例えば、マルウェアのリバースエンジニアリング（解析）作業は増え続けるマルウェアに対応し続けるしかありません。マルウェアを生産したり、プロテクトを頻繁に更新できる立場にあれば、時間と応用できる技術がある限りプロテクトを生産し続けることができます。この場合、先ほどとは逆にリバースエンジニア側が不利で、ソフトウェアをリリースする側が有利です。
量と質
プロテクトの作成は、質と量どちらかの戦略でリバースエンジニアを攻めることができます。破られやすいけど量を増やす、破られにくいけど量を増やすことができない。それぞれ使いどころが微妙ですが、必要に応じて両方使っても構いません。
○ 量で対応というのはつまり、簡単であるが「作業に手間がかかる」ということを指します。リバースエンジニアリングには細かい作業が多く伴います。簡単な作業であっても、リバースエンジニアの作業が増えるものは、心理的にも時間的にも大きな負担です。心理戦の続きですね。もちろん、簡単すぎて自動で解除されてしまうプロテクトはダメですけど。
○ 量を増やすことができない、というのは量を増やしても意味がなく、発見され次第無効になってしまうものです（例えばある種のアンチデバッガとか当てはまると思います）。ただし、発見されて無効化されない限り効果を示します。
完全なものなどない
完全に破られないプロテクトがあればいいのに、と思っても、実際には無理です。よく言われますが、コードがリバースエンジニアの環境で実行される場合、すべて解析される可能性があるということです。どんなに凶悪なプロテクトでも、根性で打ち勝つことができると考えると、リバースエンジニアリングは熱血感溢れそうな気がしますね*2。
他には、自動でソフトウェア全部をリバースエンジニアリング（解析）してくれるましーん（ツール）があれば便利なのに！ って思いますけど、ないですね。機能を限定すると自動化してくれるものがあるかもしれませんが、私の欲しいツールは高いのでまだ買っていません。欲しかったら自分で作りましょう。某Fuzzing本を読みましたが、http://pedram.redhive.com/PaiMei/docs/PyDbg/が中々凄くて、簡単な自動解析くらいできそうです。
まとめ
いたちごっこです。そして、心理戦が中々熱いと思います。
あまり書きませんでしたがリバースエンジニアリングもプロテクト開発の両方とも自動化が効く分野だと思います*3。それぞれの弱点を見つけては自動化、というプロセスですね（たぶん）。デバッガを自作するとか、言語処理系を作る勢いで難読化ツールを作成してみるだとか、プログラム開発的にも「リバースエンジニアリング」は非常に熱いです。
要望があればプログラム開発的な意味での「リバースエンジニアリング」と「プロテクト開発と自動化」について書くことにしましょう。
現実逃避にざざっと書いてしまったので、後から誤字脱字等を修正するかもしれません。
