遠隔操作ウイルスで気になるところ

前回は無視したんですが、メソッド名などの他に気にしている点があります。前回の補遺になりますから、技術的な興味がある方だけ参考にしていただければと思います。

公開資料が不完全

まずは簡単な指摘から。警察庁のPDFには Main メソッドがありません。ということは、エントリポイントを変更するという謎設定をしてない限り、あの資料はそもそも不完全ということです。（なお、通常であれば、Visual Studio が Program クラスと Main メソッドを自動で生成します。）

不完全なものになってしまった原因を推測してみたいと思います。

  1. private メソッドを記載しなかった。
    Main メソッドは自動生成では private ですし、Program クラスは Main しかないので、資料から取り除かれた説。
    しかし、hbTimer_Tick などのVS自動生成メソッドは private で生成されますが、載っています。したがって、この説の妥当性は非常に低いです。
  2. static メソッドを記載しなかった。
    この場合、Common クラスなどの（記載されている）メソッドはインスタンスメソッドということになります。あれらは static であるほうがより良いので、もしそうであれば開発者のスキルに多少疑問符がつきます。
  3. Main なんて当たり前だから警視庁判断で記載しなかった。
    技術情報の取り扱いについてのセンスがないと思います。
    「上記の情報は、合同捜査本部において、特定の手法により分析した結果ですので、別の手法を用いた場合には、細かい点について異なる場合があります。」なんて言い訳している余裕があったら、誠実に公開すればいいのに。もしくは「特定の手法による分析」とやらを明記するとか。

まあ、私の主観では 3 です。Main の他にも InitializeComponent という自動生成メソッドがあるはずなのにありませんし。あとキーロガーとか画面キャプチャに Win32 API を使わないのかな？　使っているとしたら export されたメソッド定義があるはずです。

フィールドの情報がない

ところで、メソッドは公開されているのに、フィールドは公開されていません。どういうことですかね。hbTimer_Tick というのがあるのですから、十中八九 hbTimer というインスタンスフィールドはあるはずです。

もしかしたら、警察のサイバー現場が上層部に掛け合って、ようやく引き出した公開範囲が「クラス名とメソッドの一部」なのかもしれません。某踊るなんとか的な想像ですが。

あの規模ならメソッドとフィールドの情報から振る舞いをおおよそ推測できますから、ちょっと残念です。

クラスが少ない

さて、公開の仕方については以上として、今度は再び中身についてです。

ウイルスに含まれるクラスは、 Form1, Common*, Fileman (File Manager?), Operec (Operation Recording?) とされています。

ただちに分かるのは、Form1 以外すべて機能分解的なモジュールであって、オブジェクト指向的なクラスがないということです。

これから次の妥当な推論ができます。

  1. ほとんどのロジックが Form1 にあり、機能的モジュールを中央集権的に制御している。
  2. Form1 内部では各種データをバラバラの変数で扱っている。抽象データ型を利用していない。これは、オブジェクト指向設計(OOD)ではありません。機能分解による設計です。

順に見ていきます。

メソッドの粒度が大きすぎる可能性がある

まず1についてです。

Form1が主制御を実装しているとすると、そこには遠隔操作コマンドを実行するロジックがあるはずです。

探してみると、runIns, doUrl が怪しい。ですが、たとえば doSuica とか、「あるコマンドを実行する」というメソッドがありません。とすると、runIns か doUrl の中にはすべてのコマンドのロジックが含まれている可能性があります。これは”一般的には”良くない設計です。（一般的には、と断る理由は下記。）

良くない設計は何を意味するのか

そして2と、設計についてです。

犯人からのメールでは「一から作った」となっていますから、全体設計には開発者の設計力が反映されていると思います。しかし、設計がOODではないことイコール開発者のスキル不足とは限りません。その理由を説明します。

ソフトウェア開発のセオリーでは、まずオブジェクト指向分析・設計 (OOA/OOD) なりでソフトウェアの輪郭を描き出せとされています。OOなんとかで開発を進めるので、この場合は出来上がりもOOっぽくなります。しかし、「このOOなんとかで行え」の前提は、要件定義を行える状況にあるということで、それは暗黙的に「要求仕様を把握している誰かがいる」ということです（普通は、曖昧にせよ顧客が要求を持っている）。

ところが、本件ウイルスのように「誰も正しい作り方を知らない／聞けない」という開発の場合、難しいのは「何を」開発するのか決めることです。「なにができれば遠隔操作ウイルスとして成り立つの？」に対する答え探しともいえます。

これはコロンブスの卵で、事後には簡単に見えるけど当事者には難しい問題です。正解はありませんが、答えを見つけるよい方法にプロトタイプの作成があります。遠隔操作ウイルスも、プロトタイプとして作られたと思います。

プロトタイプは良い設計を備えるべきか

ながながと書きましたが、要点は下記です：

  1. 遠隔操作ウイルスはプロトタイプである。（反論は少ないと思う。）
  2. プロトタイプの目的は実証であり、設計は二の次である。

そうすると、プロトタイプである遠隔操作ウイルスが「あまり設計されていない」ことは、実は開発者の賢さの現れとも捉えられるのです。いわゆる “premature optimization is the root of all evil” です。

そうすると、遠隔操作ウイルスにクラスが少ないことは、次のどちらにも考えられます：

  1. オブジェクト指向に対する理解が浅い。
  2. プロトタイプでの過剰設計を避けた。

プロファイリングにおいてこれをどう評価するかは難しいので、クラス構成に基づいた論評は避けました。

リファクタリングすべきか

ここまで書くと「リファクタリングして当然」という反論が思い浮かぶので、あらかじめ書いておきます。

現状として遠隔操作ウイルスが所望の機能を果たしているのであれば、リファクタリングのみを目的としてコードを改変するのは愚かなことです。「コードをきれいにしたい」という欲求に突き動かされて目的を見失うのは二流だと思います。（とはいえ、遠隔操作ウイルスの構造が、開発者のそういう自制の結果かどうかは分かりません。）

上位20%

これまでのすべての論点について、技術的バランスをとった妥当な判断の結果としての遠隔操作ウイルスなら、開発者は上位1%未満の「非常に優れたスキル」と思います。しかし、すでに述べたように、開発者がそういう優れた判断をしているかは個別の事象からは分からないことが多いです。ですから、メソッド名だけだと分からんなあ……と思ってしまいます。

ですから結局おおざっぱに言えば「実装している」「運用している」「目的をほぼ達成している」という点からの上位20%評価です。

ソフトウェア技術者の客観的評価

ソフトウェア設計における判断は、個別評価が難しいので、優れた技術者ほど第三者評価が低い可能性もあります。なぜなら：

  1. ソフトウェア技術者の能力を正確に評価するには、私の経験では、その技術者以上の能力が必要です。
  2. 優れたソフトウェア技術者ほど、正確に評価される可能性が少なくなります。
  3. 優れた判断の中には、単体では未熟さによるものと見分けがつかないものもあります。
  4. したがって、普通の技術者は、優れた技術者をなかなか見分けることができません。

ちょっと暴論ですが、私はこんなふうに思っています。

上位20%というのは、そこらへん（賢さと未熟さの混同）も考慮したうえでの、まあなんとなくの数字です。