開発者の考えた対策は空しく敗れ、3度目の戦いが始まるところから話は始まります。
●3度目のクラック
開発者の考えたトラップに、クラッカーは見事に”はまって”くれました。でも、依頼者には効きません。最初のクラック結果を依頼者が見た後、「見た目上の動作は正しいけど成果物が空になってしまいます。」という投稿をしたのです。よく考えてみなくても当たり前のことでした。次のクラッカーの投稿は、火を見るよりも明らかでした。10箇所のバイナリ編集ポイントを記した、見事なクラック結果です。そのクラッカー曰く、
「あれ、前解析のパッチが対策されて、とうとうイタチごっこになったようだ。ソフト会社はここをチェックしてるな。しばらくしたら消すか。」
●いたちごっこ
ソフト開発者は、この言葉が頭を離れませんでした。開発者としての誇りを汚され黙って見ていられない反面、どう対策したらいいのかわからず苦悩していたのです。
●対策
バイナリ編集されたら、ソフトが正しい動作をしないようにしたらどうか、と考えました。EXEファイルを1バイトずつの数値としてファイルサイズ分読んで、その数値全部の和をキー数値としてあらかじめ調べておく。ソフト実行時にプログラム中でキー数値を求めて、最初に調べた値と違っていたら、正しい動作をさせない。というものです。CRCチェックみたいなもので、ウイルス感染対策にもなりそうだな、と開発者は考えました。
でも、キー数値が一致しているかどうかを行っている場所をつきとめられてしまったら、そこをスキップされてしまうわけで、元も子もないのです。
いっそのこと、編集ポイントが1000箇所ぐらいになるようにチェックポイントを多数設けたらどうだろうか。でもソースが複雑になってメンテナンスが大変だし、美しくないソースを作りたくはないし、原始的すぎるし。
試用版の機能削減しかないか、と開発者は考えてます。試用版は製品版と同様の機能を使えるというのが、開発者のこだわりだったのですが、そうとばかりも言ってられません。
今、開発者は悩んでます。傍観するか、対策を打つか、試用版の機能を削減するか。機会があったら、この続きを書きたいと思います。
おわり