リアルタイム操作の検証（リアルタイムと推定できる）
今回のトロイがリアルタイム操作と考えられるかどうかの検証を再度実施する。(ブログ開始の頃にも5月17日「時間ズレの考察」などで行なったが現在の知見で再検証）
まず、リアルタイムと推定できる要因を以下に挙げる。
①アンカー付きレス・・・間違いなく手動かつリアルタイムとなり、一番わかり易い事例。
②遠隔操作メール・・・Yahooなどフリーメールに書込むにはログイン、送信アドレス、本文、送信ボタン等複数手順必要で、掲示板に置いた1命令だけで行わせるのは無理がある。またフリーメールアカウント取る際は、迷惑メール業者などのソフトによる自動大量アドレス取得防止の為、曲がりくねった英数字などを目視読取りして入力させている。よってこれも手動かつリアルタイム操作必須。
③他の動きに同期・・・JAL飛行機運行に合致させているとみられる事例あり。
④複数宛先又は複数スレ連続書込・・・掲示板に置いた1命令で複数宛先や複数スレ書込は命令の仕様が複雑になりすぎる。そのような仕様にする必然性もない。また、複数の書込の間に電源OFF→ONがあったと考えるなら、あとの方の書込の命令は一旦電源OFFした後に書き込んだということになる？ 電源ONのままなら、後の命令の方だけリアルタイム操作？ 考えれば考えるほど無理が出てくるのではないか。
⑤同一掲示板連続書込・・・１命令で書込回数指定する手はあるが、命令１個に一つ書き込むことで目的達成できるので、回数指定する意味が見出せない。
⑥犯人メール＆代行スレ書込・・・両方共Torによる直接アクセスで、遠隔操作ではないため「したらば掲示板」経由による遅延は発生しない。別の遅延の仕掛けを作る必然性もない。遅延させる仕掛けを作るのも容易ではない。なお、遠隔操作でTorによるアクセスを行うには被操作PCにもTorがインストールされていないと出来ないため現実的ではない。更に、犯人メールは全て10月以降で、9月までの遠隔操作犯行終了後に出されており、セキュリティソフトも対応した時期であり、遠隔操作は困難。また、少なくとも一番最初の代行依頼書込はそもそも遠隔操作の前になる。
これをWikiの「パソコン遠隔操作事件」の内容に当てはめてみる。
1．遠隔操作（手法が違うCSRFと犯人のメールにもなく今ひとつはっきりしない横浜PC除く）
(1)大阪府男性BのPC遠隔操作事件（③と④）
7月29日（日）21時45分頃 - 大阪市公式サイトの相談窓口ページ(④)
7月29日（日） - 首相官邸の公式サイトへ(④）
→二つ連続でしかも書き込み先が異なる
8月1日（水）13時25分頃 - 日本航空公式サイトの顧客対応窓口(③）
→飛行機の時間に合わせているとみられる
(2)愛知県男性CのPC遠隔操作事件(⑤）
8月9日（木）10時59分 - 2ちゃんねるに皇族殺害予告書き込み(⑤)
→二つ連続（一つは5回書き込み）・・・書込内容確認できていないが、スレが変わっていれば④になる
(3)福岡県男性DのPC遠隔操作事件(②）
8月27日（月）17時頃 - お茶の水女子大学附属幼稚園の公式サイトへメール(②)
8月27日（月）夕方 - 学習院初等科の公式サイトにメール(②)
8月27日（月） - 芸能事務所へメール(②)
8月27日（月） - 部落解放同盟中央本部の公式サイトへメール(②)
→全てメール、又メールする前にアカウント取得（犯人のメールに遠隔操作で取ったと書いてある）もあってこれもリアルタイムとなる
(4)三重県男性EのPC遠隔操作事件(①と④）
→トロイロード後約30分での書き込み、その後に別スレ書込が続くので④にする
9月10日（月）15時40分～15時49分 - 2ちゃんねるに携帯ショップへの襲撃予告に4回書き込み（①）
→アンカー付きレスでの書き込み
→スレを変えての連続書き込み
2．代行スレ書込(⑥)
→計7通あり。 ・・・Torなしが１通あるようだがリアルタイムかどうかには特に関係しないと考えられる
3．犯行告白及びクイズメール(⑥)
→計4通。
以上のようにまとめて見ると、全てが①～⑥に当てはまり、リアルタイムアクセスと考えるのが合理的になる。
ただ⑤は弱いと思われるかもしれないが、⑤の数も少なく、1の(2)に書いたように場合によっては④になる。
更に、これでもリアルタイムとは決定せずに、「リアルタイムと仮定」して被疑者にアリバイ証明を行なって貰う。
崩す必要があるのは有罪にしたい検察になるので、リアルタイムの仮定が間違っていると云うなら検察に立証責任がある。しかもどのようにしてタイムラグ付アクセスが可能で、それを被疑者が実際に行なったことまで具体的に立証する必要がある。
大変なのはアリバイ崩しの検察側であって、被疑者側の負担には少ないのだから、被疑者によるアリバイ立証をやってみる価値は十分あると思われる。
また極め付けは、iesys.exeはいずれ弁護側が証拠開示申請して検察は出さざるを得ない。弁護側が専門家に依頼したらすぐに解析できる。リアルタイムかどうかは、１週間もあれば充分調査できるレベルであろう(実際はリアルタイム性だけに絞ればもっと早くわかる可能性もある）。上記検証のようにこれだけリアルタイムを指し示す要因があるのだから、結論はリアルタイムと当方は予想。
なお、制御系の開発経験からリアルタイムと当初より予想したと前記事で書いたので、その説明も行う。
今回のトロイは犯人のPC（「ホスト側」とする）と、遠隔操作されるPC（「端末側」）の間で通信を行なって遠隔操作を実行する。このような場合制御系では通常ホスト側から命令を送って、それを受けた端末側が何らかの処理を行なって応答を返すというやり取りを行う。それを繰り返して端末に所望の動作をさせることになる。その際、ホスト側は端末側の状態を知った上で命令を出して、予め定められた応答を受け取る。
その前提で基本的なやり取りを考えてみる。まずホスト側から何らかの命令を端末側に送るが、ホスト側は端末側が命令を受けられ状態かどうかを確認してから送る。そのためには状態確認だけのような簡単な命令（例えば「CHECK」）をまず送る。端末側は命令を受けられる状態であれば応答（例えば「OK」）を返す。もし、何らかの事情で受けられない状態ならそれを示す応答（例えば「NG」）を返す。ホスト側は｛OK」が返ってきたら次の命令を送り、「NG」だったら時間を置いて再度「CHECK」を送り「OK」になるまで待つ。（今回のトロイの場合は「送る」という動作を、「したらば掲示板に書込む」と云う動作に置き換えることになる）
もし「OK」も「NG」も返って来なければ、端末側が起動していないか、途中の通信経路が途切れているなどで端末側が応答できない可能性があるので、時間を置いて「CHECK」送信を繰り返してみる。何度やっても同じなら何らかの対応が必要と判定して、その旨のメッセージを出すような動作になるのが普通である。
それで今回のトロイの端末側電源ONからの動作を考えてみる。端末側が電源ONしたらトロイが起動して、ホスト側からの命令待ち状態からスタートする方式で考える。その状態から「CHECK」命令が来たら、端末側（トロイ)は「OK」か「NG」の応答を返す。ただし、今回のトロイでは命令待ちは単にじっとして命令が来るのを待つのではなく、「したらば掲示板」を定期的に見に行っているという違いが有る。また、「CHECK」命令待ちではなく、トロイの方から自らの「OK」又は「NG」の状態を「したらば掲示板」に書き込んで、それをホスト側が確認してから命令を出す方式も考えられる。
色々やり方のバリエーションは考えられるが重要なのは”状態確認さえなく、電源ONで立ち上がった端末側のソフト（トロイ）がいきなり「複数の宛先や掲示板の複数スレにそれぞれ内容も変えて予告書き込みを行う」とか「フリーメール使用して、ログインパスワード入力・送信先アドレス入力・（題名入力)・本文入力等を行い、送信ボタンを押してメールを出す」といった複雑な機能の命令を実行する”というようなソフト構造は、制御系やってる人ならとても考えないということである。
もしかすると、掲示板ということで「◯◯と××を、□□と△△という内容で行なって下さい」と依頼文を書いておき、他の人がそれを見て実行するというイメージが湧くのかも知れない。しかし、人にやってもらうのとソフトにやらせるのとは雲泥の差があって、ソフトはもっと細切れの動作を組み合わせて全体的な動作にしていくのが一般的である。例えば、「◯◯」、「××」、「□□」、「△△」はそれぞれ別々に送って、その後に「実行」という命令を送るというようなイメージである。
そのため、前述の「状態確認」も最低限レベルのやり取りであって、実際の制御系ではもっと様々な命令・応答のやり取りを行なって動作することになる。
なお、それでも上記の例で「◯◯、××、□□、△△」は先に送っておいて、電源ONした後にトロイが「実行」の命令だけ掲示板から受け取って実行すればよいという発想があるかもしれない。しかし、フリーメールの例で考えて頂ければすぐ分かるように、ログインして必要項目入力した後、「送信ボタン」だけ押せば良い状態で放置しようとしても電源OFFしたら初期化されるのである。また、電源が入っていなければそもそもログインや入力ができない。
ただ、今回のトロイ作者が命令・応答方式の制御系的な発想のソフトを作っても、実際に制御系やった人物かどうかは分からない。独創的或いは変わった発想をする人なのかも知れない。そのために、リアルタイムと断定せずに「仮定」して考えるということである。
以上
