ソースコードから作者を95%以上の確率で特定する技術が研究されていた!ネット犯罪の犯人特定に役立つのか?

おもしろかったら友だちとシェアしよう!

GIZMODOに掲載された、ソースコードから作者がわかるという技術が研究されていたという事についての記事ですが、以下のような研究内容と記載にされています。

米ドレクセル大学、メリーランド大学、プリンストン大学、独ゲッティンゲン大学の共同チームの研究によると、自然言語処理と機械学習によるコード分析により、95%の精度で作者は特定できるそうです。

解析されるのは、レイアウトや語彙の特性と、「抽象構文木(AST)」です。ASTとは、「コードの書き方からまったく影響を受けずに、コードの型の特性をとらえる」もので、つまり、関数の名前、コメント、スペース入れ方などのクセ以上のものを探し出し、作者を特定するカギにする、というわけです。

研究チームが開発した機械学習ソフトウェアで、Google Code Jamに公開されているコードの分析を試しに行ってみたところ、あるひとりの人が書いた630行のコードを分析すれば、95%の精度でその作者が特定できたそうです。コードの行数を増やして1,900行にすると、特定の精度は97%になるとか!

精度95%以上! ソースコードは指紋、作者はほぼ特定できる | ギズモード・ジャパン ーより引用

本当に役に立つのか?

記載そのままの内容だとすると、ですが結論から言うと役に立ちません。理由はいくつもあります。

ソースコードが入手できない可能性

ハッカーやオンライン詐欺の類のプログラマーが、犯罪のソースコードを他人から見えるところに晒す可能性はほぼ0%です。晒す必要があったり、世に広めたいコードであるならばそもそも記名されているでしょう。別人になりすまして広めているのであるのならば、上記の技術が同一人物と確定させるための役には立ちます。

犯罪プログラムは実行されるのにソースコードはないのか?

高度なプログラムの書ける低レベル言語では、コンパイルという形式でプログラムを作成します。これは、ソースコードをコンパイラーというプログラムが解析し、マシン語というコンピューターが読める形の数列に置き換えるのです。このときコメントやスペースといったプログラムの実行に不要な部分は削除されます。使用されるコンピューターにはコンパイルされたマシン語の固まりのみが配布され、ソースコードはメンテナンス用に作者のコンピューターに残されたままです。

昨今、普及しているWeb上でのプログラム言語などではスクリプトというものが使用されています。これは実行時にソースコードを解析するものでインタプリターと呼ばれる形式です。この場合はソースコードが残されたまま配布されます。ですが、現在では、このソースコードを圧縮して読み込み速度をあげる技術が進んでいて、これによってソースコードのコメントや命名規則などは消去されてしまいます。この技術を用いてソースコードの読解を難解にすることも出来るので、技術を独占したい、ユーザーに読み込み負荷をかけたくないなどの理由で広く使われています。

他の使い道は?

それでは犯罪者特定に役立たないのであれば、ソースコード管理などに企業で使用するのはどうでしょうか?

プログラマーは自分でどの程度ソースコードを書くのか?

企業でのプログラム製作は多人数が関わります。長い期間にわたって修正や追加を加えていくので、非常に多くの人がプログラムを書きかえます。

その中で、どれだけのプログラマーが自分で考えたソースコードを自分の書式で書くのか?

残念ながら、これも皆無といえます。

まず、多くのプログラマが関わるであろうプロジェクトには命名規則や書式設定が規則として作られることが多いです。これは無駄な書式合わせによるコストを省くために行われています。書式が自分の楽な書式にあっていないとプログラマが書式をあわせて書きなおしてしまうので、これによるバグの発生や書きかえに自体によるコストの発生を防ぐために、プログラマに書式を強要しておくのです。

そして、昨今ではプログラマが一からすべてのソースコードを書くことは激減しています。Web上に情報がたくさんあるので、既存の公表されているソースコードを抜粋して、自分のソースコードに貼り付けます。この手法は非常に多くなっています。この手法を取ることで動作テストを行うだけで実装が済む可能性が高いのです。この場合に動作不良を起こす可能性の危惧から、必要な書式に書き換えるコストを省くプログラマーも多くいます。ライブラリーなどのファイル形式として配布されているものでは書式修正を加えるプログラマーは皆無だと言えます。

こうなると、ただでさえ関係したプログラマーの多いプロジェクトの中に、企業に関係しないプログラマーのソースコードも混在してくる事態となります。

プログラマーとしてのコスト

また、既に自分が外れたプロジェクトから「プログラムに異常があったから」といって、お呼びが掛かるのはプログラマーとしては迷惑極まりないことです。プログラマーはプロジェクトが切り替わった時点で、プロジェクトに必要な知識を切替えます。ひとつ前のプロジェクトの知識は、ほぼ忘れてしまうのです。そして新しいプロジェクト用に知識を詰め込んでいきます。その最中に別のプロジェクトから呼び出しが掛かり、作業する羽目になると、知識の詰め込み作業を一からやらなければいけなくなります。

もちろん、このような即興での詰め込み作業に特化したプログラマーもいますが、決して楽な作業ではないことは間違いありません。順応が得意でさらに、バグ修正や機能追加などの問題点抽出や新規アルゴリズムの作成が得意であるプログラマーは希少なのです。

結局は書いたプログラマーを特定する作業を行うよりも、修正方法をそのときの担当プログラマーが考えたほうがローコストとなるでしょう。

プログラムが複雑怪奇で、当時の担当者の考えを聞きたいというケースは10年続けたプログラマーで1度あるかないか、というレアケースです。通常は、ソースコードとコメントや仕様書などから読み解けるものですし、プロジェクトリーダーが納められたソースコードの内容を把握しているものだからです。

まとめ

こういった現状の中で、いったい何のために研究を続けているのか?どのような分野で役立つのか?当初の方針で続けていくのならば、ソースコードをどこから得るのか?

研究成果がどのように活用されていくのか、興味は尽きません。

出典
GIZMODO