NetAgent Official Blog

　こんにちは、愛甲です。今日は私が趣味で（というより業務の合間に）作っているゲーム(?)について紹介したいと思います。正直、セキュリティとはまったく関係ありませんが…（汗）。

-----

■Robocode（ロボコード）
　Robocodeというプログラミングゲームをご存じでしょうか？　Robocodeとは、Javaを使ってプログラミングしたロボット（戦車）同士を戦わせるというゲームであり、RobocodeのWebサイトからフリーでダウンロードできます。
　プレイヤーはロボットを動かすプログラムをあらかじめ記述しておき、そのプログラムをソフトウェアに読み込ませて他プレイヤーと対戦します。Robocodeは、戦車を操作して戦うゲームなので「戦車の移動」や「どの角度に弾を発射するか？」などをプログラミングする必要があります。プレイヤーが直接ゲームのキャラクタを操作するわけではなく、あくまでもJavaというプログラミング言語を通してキャラクタを操作するところが、一般的なコンピュータゲームとは大きく異なる部分です。
　Robocodeは、もともとはJavaプログラミングの学習用教材として開発されたようですが、現在は.NETにも対応しており、学習用に留まらずに多くのユーザから利用され、大会なども開かれています。実は、私も以前Robocodeをやっていた時期がありました。ただ、私自身Javaや.NETについてはそれほど知識を持っていませんでしたので、すぐに止めてしまった経緯があります。

■アセンブラで記述したい
　Robocodeはとても面白いのですが、やはりJavaや.NETよりもアセンブラで記述したいのがリバースエンジニアの本音です。というわけで、アセンブラを利用したプログラミングゲームを新たに作成しようと考えました。実行ファイルはこちらからダウロードできます（まだまだ開発の途中なので不具合が多くあるかと思いますが…）。
　プレイ画面は右図のようになります。上下にある赤と青のテーブルを動かして真ん中にあるボールを打ち合うゲームです（普通です（汗））。上下のテーブルはアセンブラライクなスクリプト言語で操作できるようになっており、下がscriptフォルダ以下のred.kbファイル、上がscriptフォルダ以下のblue.kbファイルを読み込んで適用しています。
　毎フレームごとにプレイヤーが用意したスクリプトが呼び出され、テーブルの動作を決定します。スクリプト側では、呼び出された段階で以下のデータにアクセスできます。

　1. 自テーブルの位置（x, y）サイズ（width, height）
　2. 相手テーブルの位置（x, y）サイズ（width, height）
　3. ボールの位置（x, y）サイズ（width, height）

　さらに出力結果として、テーブルの移動方向（上下左右）をセットします。これらのメモリマップは右図になります。
　レジスタはeax、ecx、edx、ebx、esp、ebp、esi、ediの8つと、cmp命令の結果を反映させるflagレジスタのみ用意しています。
　スクリプトが呼び出された直後は、espとebpのレジスタ以外はすべて0であり、espとebpには　キー入力情報の場所のアドレスが格納されています。また、スクリプトで使用できるアセンブラ命令は、mov、push、pop、call、leave、ret、jmp、add、sub、inc、dec、cmp、je、jne、jl、jle、jg、jge、xor、and、or、shl、shr、nopとなります。
　そして、これらを用いた実際のソースコードは右図のようになります。

■アルゴリズムを考える
　ボールとテーブルの位置（x, y）が分かるので、まずはそれらのx軸を合わせるようにプログラミングすれば、とりあえずはそれっぽく動きそうです。しかし、それだけだと面白くないので、ところどころに上下運動を取り入れたり、あと何フレームでボールがどこへ移動するか、などを推測しながらテーブルを移動させていくことで、より強いキャラクタ（ただのテーブルですが…）を作成できそうです。
　プログラミング言語は、本来「何かを作るため」に存在するツールですが、Robocodeを初め、こういったプログラミングを題材としたゲームでは、プログラミング技術を通して、一種の「対戦」を実現できます。勝ったから、負けたからといって何か得することがあるわけではないですが、より強いアルゴリズムを考えようとすれば、それだけプログラミング技術も鍛えられるかと思います。仕事の息抜き程度に挑戦してみるのも面白いかもしれません。

-----

　今回はセキュリティとは関係のない話となりましたが、いかがだったでしょうか。
　そもそもなぜこのようなものを業務の合間に作れるのか、というと、実は、弊社の研究開発部には「20%ルール」というものがあります。20%ルールとは「業務時間の20%は自分の好きなリサーチをやってよい」というものであり、例えば、一般的な会社の完全週休二日制の場合、1週間に月～金までの5日間働くことになりますが、この5日のうちの1日、つまり業務時間の20%は自分の好きな研究に使用できます。これを利用すると、セキュリティとはまったく関係のない、ただのゲームを作ったりできます（汗）。

　さて、少し話がそれてしまいましたが、たまにはこういうのもよいかな、と思い、ブログに書かせていただきました。楽しんで頂けたら幸いです。
　なお、当ソフトウェアはまだ未完成ですので、動作環境の確認等は行っておらず、動作保障もできません。ブログのネタ程度に考えていただけると有難いです。

　はじめましての方ははじめまして、いつもお世話になっている方はこんにちは！　今回初めてこのBlogで記事を書くことになりました「まっちゃだいふく」と申します。まず自己紹介からするのがこのBlogの定石のようなので自己紹介から。
（編注：そんなことないですよ、自由に書いてください（汗））

■自己紹介
　私は、本名「八尾 崇（やおたかし）」と申しますが、ネット上では「まっちゃだいふく」というハンドル名で活動しています。京都在住でネットエージェント大阪支社に勤務している関西人です（よく東京に住んでいると間違えられますが…）。
　2004年頃より「まっちゃ１３９」という情報セキュリティに関する勉強会を開催し始め、2008年より弊社でエバンジェリストとしての活動を行っております。主に全国各地で情報セキュリティに関する勉強会のサポートや開催を行っており、現在、情報セキュリティの勉強会は全国各地で14件ほど開催されている中、そのうち11件の勉強会のお手伝いをしています。場所は、北海道、東北、北陸、東京、静岡、京都（大阪）、神戸、香川、愛媛、島根となります。

■よく聞かれること（FAQ）
　勉強会を開催していると、はじめましての方とお会いする機会も多く、様々な質問をされることがあります。特によく聞かれることとして、ハンドル名の由来があります。私のハンドル名「まっちゃだいふく」の由来ですが、そもそも発端は、2004年頃にさかのぼります。私が勉強会を開催してまだ間もない頃に…………、ってなんか話が長くなりそうなので3行でまとめてみました。

　1. 勉強会初参加、ハンドル名なし
　2. お菓子を持っていく （だいふく）
　3. 次の勉強会でお菓子を持っていく （まっちゃ）　→　合わせて「まっちゃだいふく」

　はい、あまり深い意味はありませんでした。というかお菓子の名前を繋げただけでした（汗）。

　次によく聞かれることとして、TwitterやはてなのIDである「ripjyr」の読み方についてですが、このIDは、実は私もどう読んでよいのか分かりません…。なぜこのようなIDにしたのかというと、そもそも最初にブログを始めようと思いアカウントを登録した際には本名から由来したIDを使っていたのですが…………、ってこれも書いてて長くなりそうなので3行でまとめました。

　1. 本名由来IDではてなブログを書いていた
　2. 色々問題があって廃止
　3. 新しいものを面倒なのでパスワードメーカーで作成　→　「ripjyr」が生成された

　はい、今思えば、パスワードメーカーはパスワード生成するツールであって、ID生成するツールじゃなかったです（汗）。

　さらによく聞かれる質問として、勉強会名である「まっちゃ１３９」や「まっちゃ４４５」の語尾についている3桁の数字は何？　というものがあります。

　1. 私の師匠伊原さんのPort139勉強会、Port445勉強会に由来
　2. 2004年に名前の一部をもらって「まっちゃ１３９」を開催、
　　 2008年に東京でも名前の一部をもらって「まっちゃ４４５」を開催
　3. １３９と４４５はMicrosoftのファイル共有のポート番号に由来？

　こちらはなかなか深い意味があります。詳しい話は「なぜ、まっちゃ４４５勉強会という名前なのか」に書かれてあります。

■そもそもなぜ私が勉強会をやっているのか？
　私はもともと某IT系企業にてシステムやネットワーク等の管理をやっていたのですが、2004年当時、それらに関連するセキュリティ対策についての情報がどこを探しても見つけられないことに疑問を感じていました。また折しも、2004年当時は個人情報保護法が施行される1年前ということで、会社として何をしたらよいのか？　何をしなくてよいのか？　何から始めたらよいのか？　それらが全く分からない状況でした。
　ちょうどそんな時に「Port445勉強会」が京都で行われ、個人情報保護法に関する話題を聞けるという話を耳にしました。それまでコミュニティ活動などをしたことはなく、メーリングリストなどに投稿したこともなく、ましてや勉強会に参加したこともありませんでしたが、個人的に興味のある話題でしたので、意を決して参加を決めました（もちろん事前に参考文献を読んで事前学習していきました）。そこで自分を含め、参加者が全員で勉強する姿勢を感じたり、個人情報保護法への理解を深めることができたり、会社へもフィードバックできたりと、勉強会の楽しさ、有意義さを実感し、以後それにどっぷりハマっていくことになります。

■まっちゃ１３９勉強会の主催と継続
　そんな勉強会にどっぷりハマってしまった私は、その後すぐに勢いで勉強会を旗揚げしてしまいました。第1回勉強会には、35名入る会議室いっぱいになるほどの人たちが参加してくださり、また東京からも多くの有名な方々が参加してくれました。その後、1年に4回程度、無理せずに勉強会を重ねていき、現在に至ります。

■全国でお手伝いしている勉強会
　さて、私は全国で情報セキュリティ勉強会の開催のお手伝いをしていますが、初めは関西（まっちゃ１３９）だけ主催していました。4年ほど細々と勉強会を開催していたのですが、2008年に弊社社長杉浦より東京でも情報セキュリティの勉強会を開催してほしいというオファーがあり、当時かなり悩んだのですが、私も東京で情報セキュリティの勉強会をやりたいと言う思いで、ついには転職を決意しました。
　2008年に転職後、東京で勉強会を開催し、その後全国各地の知り合いに声をかけ始めたところ、様々な地域で勉強会を開催したいと言う声が上がり始めました。各地の勉強会の立ち上げから運営まで色々お手伝いをした結果、現在では、合計11件の勉強会の開催をお手伝いしているという状況になりました。
　私自身、できる限りお手伝いしている勉強会には参加するようにしているのですが、11件の勉強会が平均して年に4回ほど勉強会を開催するとして、11×4＝44回/年となり、現在においては1年に44回の勉強会に参加する計算になります（実際、昨年に参加した勉強会数は40を超えています）。1年に44回とすると約8日に1回の割合でお手伝い（or開催）している勉強会に参加している計算になります。

■勉強会主催時のモットー
　私が勉強会を主宰する上でのモットーとして「参加する人が楽しんでくれる勉強会」を意識して開催しています。これは、勉強会参加者が楽しんでくれることで、その参加者がその面白さを会社の知り合いや友人に伝え、さらにその楽しさを共有できる人が増えていけばいいと感じているからです。
　私の経験上、組織の1～2％の人が勉強会に参加するように思えます（100名の組織で1名か2名が勉強会に参加）。このパーセンテージを少しでも増やせたらと思い、色々な方法で参加者に楽しんでもらえる勉強会を企画しています。例えば次のようなものです。

　1. 開催場所の参加者が興味を持つテーマ選び（集客）
　2. 勉強会で自己紹介（声出し）
　3. グループディスカッション（全員参加型）
　4. お菓子タイム（参加者同士の交流）
　5. 参加者全員との会話をするように心がけ（壁の花は作らない）

　全国各地で勉強会を開催していると「情報セキュリティへの意識が片隅にはあるが、付加機能としか上司が思ってくれない」という声をよく聞きます。情報セキュリティ勉強会に参加してもらうことで、このような意識が0から1に増えてくれることを期待していています。
　そのためにも、当社としても私としても「参加した人が喜んでくれる」→「会社の知り合いや友人を連れて来てくれる」という参加者の輪を広げる活動を続けて行きたいと思っています。

　もし勉強会に興味を持たれた方は「日本の情報セキュリティ勉強会ポータル」や「IT勉強会カレンダー」を参考に参加してみてください。初参加の方でも学生さんでも気負う必要はまったくありません。
　どこかの勉強会でお会いできることを楽しみにしています。

　みなさん、こんにちは。ネットエージェント株式会社、研究開発部の長谷川です。
　「ネットエージェントのブログに書いてあることは難しいことばかりだ」という声を頂きましたので、今回はWindowsにおけるUSBメモリの調査方法に関して、レジストリに関する基礎的なトピックスを取り上げることにします。

-----

■USBメモリの初回使用日の把握
　みなさんご存知のように、WindowsはユーザーがUSBデバイスをマシンに初めて挿入したときに、対応するデバイスドライバのインストールを自動的に行ってくれるのですが、実はこのとき、Windowsはインストールされたデバイスドライバの情報を日付や時刻とともにログファイルに記録します。よって、このログファイルを調べることで、そのマシン上で初めてデバイスを使用した日時をあとから追跡することができます。
　一般的なUSBメモリのデバイスドライバがインストールされたときのログファイルの場所は、Windows XP と Windows Vista および Windows 7 とでそれぞれ異なり、XP では %SystemRoot%\setupapi.log に、Vista および 7 では %SystemRoot%\Inf\setupapi.dev.log になります（%SystemRoot%は一般的なPCでは C:\Windows を指しています）。
　以下は、手元の Vista マシンでの setupapi.dev.log の一部です。

>>>  [Device Install (Hardware initiated) - 

USBSTOR\Disk&Ven_IO_DATA&Prod_USB_Flash_Disk&

Rev_4.50\06C0834150310167&0]

>>>  Section start 2008/01/08 13:23:21.448

     ump: Creating Install Process: DrvInst.exe 13:23:21.448

     (中略)

     dvi:      Created Driver Node:

     dvi:           HardwareID   - GenDisk

     dvi:           InfName      - C:\Windows\System32\DriverStore\

                                   FileRepository\disk.inf_e0b0b355\

                                   disk.inf

     dvi:           DevDesc      - ディスク ドライブ

     dvi:           DrvDesc      - ディスク ドライブ

     dvi:           Provider     - Microsoft

     dvi:           Mfg          - (標準ディスク ドライブ)

　これより、I/Oデータ製のUSBメモリを2008年1月8日にインストールした、すなわちこの日に初めてこのUSBメモリを使用した、ということが見て取れます。

■USBメモリの最終使用日の把握
　Windowsでは、USBメモリなどのストレージデバイスがマウントされドライブレターが割り当てられると、レジストリの HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2 および HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume 以下にデバイスごとの接続情報が記録されます。
　右図のうち、例えば {4dad2e2a-d14e-11dd-82f9-005056c00008} というキーをさらにレジストリエディタで検索してみると HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices の下に \\?\Volume{4dad2e2a-d14e-11dd-82f9-005056c00008} というバイナリデータが保存されているのを発見できます。
　このバイナリデータの中身を見てみると、「Disk&Ven_I-O_DATA&Prod_USB_Flash_Disk&Rev...」というUnicode文字列を見つけることができます。これは、前節で述べたI/Oデータ製のUSBメモリですので、このUSBメモリをマウントしたときの情報が HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{4dad2e2a-d14e-11dd-82f9-005056c00008} に記録されているということになります。
　さて、あまり知られていないのですが、レジストリはキーごとに最終書き込み日時のタイムスタンプを保持しています。ですので、この HKEY_USERS\<ユーザSID>\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\{4dad2e2a-d14e-11dd-82f9-005056c00008} というキーのタイムスタンプを調べれば、このI/Oデータ製USBメモリを最後にマウントした日時も把握できる、ということです。
　レジストリのタイムスタンプは、RegEnumKeyEx や RegQueryInfoKey といったAPIを使用すれば取得することができますので、これらのAPIを使った小さなプログラムを作成し、実際にレジストリキーのタイムスタンプを取得してみました。
　このように、8月20日の夕方に該当のUSBメモリを使用したということが追跡できます。
　また、このレジストリは HKEY_USERS\<ユーザSID> の下に書きこまれますので、特定のUSBメモリの最終使用日時はユーザごとに把握できる、ということになります。

■より簡単に
　さて、このようにUSBデバイスを使用した際に利用されるレジストリを把握・調査することにより、(1)USBメモリの初回使用日時、(2)USBメモリの最終使用日時、(3)USBメモリの最終使用者 のような使用履歴がある程度追跡できることがおわかり頂けたと思います。とはいえ、実際にUSBメモリの使用履歴を調査しなければならないような現場では、レジストリエディタでこのような作業を行うことは現実的ではありませんので、様々なツールを使うことになります。
　弊社が扱っている「USB関所守」という製品にもこれらの機能が含まれており、リモートレジストリ経由で接続することで、各クライアントPCへのエージェント等のソフトウェアのインストールを行うことなく、管理者は各クライアントPCで使用されたUSBメモリの使用履歴を追跡することができます。

　今回は、USBメモリとレジストリの基本的な部分に的を絞ってみましたがいかがだったでしょうか。弊社の技術が皆様のお役に立てることを願っています。

　みなさんはじめまして、ネットエージェント株式会社、研究開発部の山口尋久（やまぐちひろひさ）と申します。大阪で製品やサービスの開発をしています。
　今回はドメイン名レピュテーションの扱いについての最近の話題を紹介したいと思います。

-----

　「レピュテーション（Reputation）」とは、通信を制御／ブロックするためのデータをユーザから収集した評価情報をもとに整備する手法のことで、近年では迷惑メール対策によく使われます。レピュテーションを直訳すると「評判」という意味であり、これはいわばユーザからの「タレコミ」と言えます。このような情報提供により、実績報告に基づくデータベースの構築がより早期に可能になり、仮に通信するべきでない問題サイト（マルウェア配布サイトなど）が新たに見つかった場合も、この即応性によりすぐに対応可能となります。
　ただ、この早期対応可能であるという特徴は、悪意を持った報告や誤った報告に対して脆弱な側面もあります。迷惑メール送信実績サイトを集めたブラックリストの中には、この即応性を重視しすぎた結果、大手ISPを丸ごと登録してしまい、なかなか解除されなかったといったトラブルを経験したという話もしばしば聞かれたものです。
　確かに、評価情報を収集する際「迷惑メールを送信した」というネガティブな情報は比較的集めやすいですが、逆に「問題がない」という情報は扱いにくい（集めにくい）印象があります。
　よって、DNSサーバやメールサーバなど、問題のある設定をしてしまいやすいサービスについては、設定状況を確認してポジティブな評価をしていくというのも有効な方法かもしれません。また、どれぐらいの期間それらの情報が有効であるとするかでデータベースの特徴も変わってきます。

　評価情報データベースの実装自体は、key-value型のデータベースを使えば容易に可能なので、レピュテーションに関しては、情報収集の手段（いかにして情報を集めるか？）が各公開リストの大きな特徴（差別化される点）と言えます。迷惑メールの送信実績のあるIPアドレスを収集したもの、そのアドレスを含む同一契約と思しきアドレスブロック単位で提供するもの、ドメイン名単位で収拾するもの、フィッシング（phishing）サイトを収拾したもの、マルウェア配布サイトを収集したものなどは、あちこちで公開されているサーバやアプリケーションの設定サンプルによく含まれています。
　とはいえ多数ある「レピュテーションエンジン」を切替えて使う手法は、色々なサイトで試みられているものの横断的な利用についての議論はあまり多くはなかったように感じます。
　そんな中、今年の8月にIETFのDKIM（DomainKeys Identified Mail）WGの議論からスピンアウトする形でnon-working groupメーリングリストが作られました。non-working groupメーリングリストでは、DKIMに特化した話ではなくすべてのアプリケーションに共通する形でドメイン名のレピュテーションの扱いについて議論されていくようであり、メーリングリスト内では、データベースの用途について考慮すべきか、古いデータをどうするか、提供された評価情報をどのように扱うか、複数データベース間での連携をどうするかなどの、メンテナンスにまつわる諸問題、問合せ記録を見ることによって問合せ側のサイトのプライバシーが明るみに出る可能性をどのように解決するかなど、周辺の諸々の事項についても様々な意見が出されています。個々の議論については、アーカイブが公開されているので、興味のある方は追いかけてみてください。
　個人的に、特に興味深かった話題としては、ドメインレピュテーションリストの用途（メール用かurl用か）について議論すべきであるかという話の流れの中で、「通信の中身（私信なのか取引上の連絡なのか等々）に比べたら、サービスの種別（メールかWebか）はさほど重要ではない」という趣旨の発言がありました。spam送信サイトのリスト、フィッシングサイトのリスト、マルウェア配布サイトのリストといった用途別のリストばかりが念頭にあったので、この視点は新鮮に映りました。
　通信内容の性格を考えると、たとえば私的な通信の場合は個人的なつながりによる関係性により重みづけがきまるためレピュテーションによる評価づけがふさわしくないでしょうし、逆に不特定多数へ送信される広告などはレピュテーションによる評価づけが有用だと言えるでしょう。また、メールアドレスのドメインとwebサイトのドメインが同じである場合にそれらの評価情報に関連性が認められる場合も多いでしょう。用途別のサービス横断的なレピュテーションデータベースが作られるとすれば、どのようなものになるかどのように使いこなしていくのがいいかと想像が広がります。

　レピュテーションという手法は古くからあり、既存の実装も多数存在する中で、こういった議論を経ることで新しい実装のあり方や活用の仕方が見えてくるとまた面白いかもしれません。