UNIX 用 分散 C2 総当り攻撃クライアントの MMX 最適化版を公開しました。ダウンロードは 分散 C2 総当り攻撃 からです。今回コンパイルには nasm が必要になっています。また MMX 命令を持たない CPU では動かなくなってしまっています。SPARC 使ってたり alpha 使ってたりする方で、コンパイルしたけと動かないぞとか言ってくる方はいないと思うのですが、為念。
今回 UNIX 用クライアントに組み込んだ MMX 最適化コードは、WIN 用クライアントで使用した MASM 用のコードをそのまま nasm 用に移植したものです。これで同一 CPU であれば Windows 版と UNIX 版での速度差はほとんどなくなったと思います。今後は WIN 用アセンブラにも nasm を使用する予定ですので、最適化版のリリースは WIN/UNIX 同時にできると思います。
また、今回のバージョンから UNIX 用クライアントにも、WIN 用同様のサーバ側 CPU 負荷低減対策を組み込みました。基本的には一度の鍵要求で複数の鍵ブロックを割り当て可能にして、サーバへのアクセス頻度を下げようという手法です。まだ中断前の鍵解析速度に追いついていないので正確な比較はできませんが、それなりに効果は出ているようです。
今後の予定としては、MMX コードをもう少し高速化できないか試してみて、多少なりとも高速化できたならばクライアントのバージョンアップという予定でいます。また、WIN 用クライアントのホスト名が引けなかった場合にアクセス違反を派生させるバグの修正も同時に行います。
分散 C2 総当り攻撃 MMX 専用クライアントを、WIN/UNIX 用共に更新しました。今回の最適化で処理時間が 1 割程度短縮してくれたはずです。
これ以上の最適化はかなり難しいと考えています。正直 PROLD/PRORD が欲しくてたまらないのですが、まず搭載されることは無いだろうと予想できるのが悲しいところです。P4 系での shift/rotate 命令が、せめて add/xor の倍程度の遅さならば F 関数部分を通常の x86 命令で書いてみるという選択肢も出てくるのですけど……。
敗北気味。少し前からやらなきゃいけないと思っていた、鍵の有効範囲（どの範囲で同じ鍵が使われているか）のチェックを昨日まるまる潰してやってみたのだけど、CBC ユニットの先頭を書き換えてしまうと、エラー量が AVHDD の許容範囲を超えてしまうらしく、書き換えポイント周辺で再生が停止してしまい、対応平文を取り出すことができずにいる。
運良く最初の一回だけは書き換え後も再生は停止せずに対応平文を取り出すことができたのだけど、それ以降では一切成功せず。徒労感だけが積もっていく。
とりあえず判ったこと。512 バイトブロック内の、インタリーブされた CBC ユニット同士は同じ鍵が使われている。唯一成功した書き換えで、512 バイトブロックの先頭 16 バイトを 0 クリアした場合、同じ平文が出てきたのでそれは確認できた。
むー Time/Memory Trade Off で攻撃する場合は CBC モードの 2nd ブロック以降をターゲットにしたほうがよさそうだな。256 バイトエラーが発生すると再生停止してしまうけど、最終 2 ブロックの 16 バイトだけ書き換えならまず再生は停止しないし、連続した 2 ブロックの鍵さえ判ればユニット鍵は判るんだし。
えーと、できればオーバークロッキングは控えめにしておいて欲しいかなーと思ったり。完全にオンキャッシュで動くプログラムだし、CPU 内部でのデータ化け (= 不正命令とか不正アクセスとかでブルースクリーンに行く) が無ければまず大丈夫だとは思うのですが……。サーバ側もはやいとこ C で書き直してチェックルーチン入れやすいようにしとかなきゃ。
実は昨年末に冬茄子を使って CSV-EX11 (Cocoon 500GB モデル) を購入していた。本当は松下の DMR-E200H あたりを買うつもりだったのだけどちょうど買いに行った時に品切れ気味でヨドバシ・ビック共に在庫無し状態だったため、ついふらふらと。もちろん 例のクライアント の存在が頭にあったのは言うまでもないことだったりする。
というわけで「おまかせ・まる録」機能により、ダメな番組が着実に溜め込まれていく至福の生活がやってきた。とても便利。これでデジタルチューナ内蔵だったらどんなに嬉しいだろうと、それだけが残念な点。
TS 吸出しも簡単にできて、取り出した TS は 某副産物 でも読み込めている。そのうち間違った Cocoon の楽しみ方とかを書くかもしれない。
未確認情報ながら、Rec-POT シリーズ生産停止という話が出ているらしい。店頭から消えているという情報も。解析用の一台とは別に数台欲しかったりしたのだけど……年末のうちにもう一台買っておけばよかったかなー。
現在状況の画像更新コードに、稼動中クライアント数とか割り振り済みブロック数とか試行済みブロック数とかを表示する機能を追加しました。working client が稼動中クライアントにあたるのですが、これは全クライアントの中から過去 24 時間以内にアクセスのあったクライアントのみを抽出した数を出力しています。
延べ PC 数なら 900 を超えているのですけど、継続的に参加してくれている PC はその半分以下という悲しい状況です。うーん、ランキングの表示機能とかつけた方が……しかしそうするとオーバークロックの誘惑に駆られる人が……。
てな訳で、サーバ側へのチェックルーチン追加が急務だったりするのですが、今回の機能追加でますます ruby-GD への依存度が高まってしまったのでどーしよーかなといったところです。いっそチェック部分は外部プロセス起動形式にしてしまおうかしらん。
最近めっきり発想が黒くなってていやな感じなんだけど。AMD と Intel、プロセッサに攻撃防止機能装備へ [ITmedia] という記事を眺めての感想が、クラック対策の為に実行時暗号解除型になってるプログラムはどーなるのだろうというものだったりする。
要は実行属性と書き込み属性を排他にして、書き替え可能なメモリアドレスは実行不能にしてしまうという技術だと理解したのだけれども、EXE の段階では圧縮されてたり、暗号化されてたりして、起動後に自己解凍・自己復号されるようなプログラムは存在を許されなくなってしまうのかなというのが心配な点。こいつらは自己書き換え型のプログラムに相当するわけなのだけれども、当然ならが書き込み不能なアドレスには解凍・復号結果を書き込めないわけで、実行不能なアドレスに解凍・復号結果は書き込めるけれども実行できないわけで。一体どーするのだろう。単に私がその機能を誤解してるだけだったら良いのだけど。
現在実行中の総当りでの結果次第という部分もあるのですけれども、大体次の予定でいます。
まず、最悪のケース。総当りが最終ブロックまで進んでも、鍵が発見できなかった場合。この場合、手がかりが無くなってしまうので、クラックは断念して、二度目の敗北宣言を行い、尻尾を巻いて逃げ出します。（この可能性は非常に高いです）
次に、鍵が発見できたケース。この場合、S-Box が確定（現在仮定中のもので正しいと判明）するので、次のステップに進めます。が、その前に、発見できた鍵がどの範囲で有効かの確認を行います。常識的に考えて全 HDD をたった一つの鍵で暗号化しているだけということはありえないのですが、相手は松下（暗号の世界ではメジャープレイヤーじゃない）なので、ひょっとしたらそーゆー間抜けな設定の製品になっているかもしれません。これで鍵が全領域で有効と確認できた場合はウハウハです。私の AVHDD に関しては生 TS が取り放題ということになります。
鍵の有効範囲がどちらであれ、S-Box 確定後は Time/Memory Trade Off 攻撃の分散型準備計算を開始します。詳細は現在検討中なのですが、基本的には CBC モードでの 2nd ブロック以降をターゲットにして、選択暗号文に対応する鍵と平文のデータベースを作り、総当りよりも短時間で鍵推定を行うという方針でいます。事前の準備計算に総当りと同じか、それ以上の時間がかかってしまいますが、事前計算が十分な状態になれば、c2bf が 1 ブロックの計算を終わらせるのと同じぐらいの時間で鍵を発見できるようになるはずです。
本当は、ここまで進んだら次は別の Rec-POT を購入して、HDD のシリアル情報等と暗号鍵の対応関係などを調べていく予定だったのですが、Rec-POT メーカ在庫完了（いくつかオンラインショップに当たってみたのですが、判を押したように同じ答えが返ってきてしまいました）ということなので、ここから先はどうしようか悩んでいるところです。HDD が死んだときの交換を考えると、鍵生成アルゴリズムまで判明していないと不安なのですが、データが 1 つのペアだけではアルゴリズムの推測すらできないので。ひょっとしたら他の所有者の方々に情報提供を依頼するかもしれません。
ペチペチとサーバ側 CGI を C++ で書き直し中。昨日・一昨日と二日間かけて、とりあえずメール周りと GD 周辺と MD5 は何とかする目処が立った。後は POST データの処理と全体の統合ができればスクリプトからの置き換えが可能になる。
これでサーバ側 CPU 負荷が半分程度になってくれれば良いのだけど。現状でも CPU 負荷自体は 33% (AM4:00〜AM8:00) 〜 50% (PM19:00〜PM24:00) 程度とそれほど高くない [MRTG の CPU グラフ] のだけれども、クライアント PC が 1000 台でも大丈夫と言えるほど低いわけではないので。
PROXY 対応はサーバ側のリプレースが済んだら着手します。
Celeron 1.3GHz × 2 台追加投入。本当は 1.4GHz で投入したかったのだけど、リテールの在庫が少なくなっているため仕方なく。
とりあえず 1 ブロックの処理にかかる時間は 290 秒前後で、Celeron 2.8GHz の 240 秒と比較すると、50 秒ほど遅くなっている。この辺は納得済みで予定どおりだから問題なし。
これで一日あたり 360+296+296=952 ブロックは最低進む計算になってくれるはず。現状だと一日に約 50000 ずつ進んでいるから、私の寄与は約 1.9% と。多いのか少ないのか微妙なところ。
試みに Celeron 2.8G だけで全鍵空間を探索した場合の電気代とかを試算してみる。Processor Spec Finder [intel] によると、Celeron 2.8GHz の TDP は 68.4 W。c2bf がフルに回っている状態だと多分これに近い電力を使っているだろうから、CPU 単体で 68.4 W としてそれに電源でのロスや他のデバイスが食う電力が 20W 前後あると考えて、計算を単純化するために PC 全体で 90W 食っているとする。
一日あたり 360 ブロック処理できるから、全探索ならば 2^24/360=46603.377 日必要。90 W に 24 時間と 46604 日をかけると 100665 kWh になって、東京電力の従量電灯 B の 2 段料金 20.67 円をかけると…… 208 万円。
同様に Celeron 1.3G の場合。TDP が 32.0W で電源でのロス等ほぼ同じくらいかかるとして 52 W。一日あたりの処理ブロック量が 296 だから 56680 日必要で 52×24×56680 から 70737 kWh になって…… 147 万円。
やっぱり Socket370 Celeron で正解だったらしい。これが終わると使い道がなくなってしまう点が悲しいけれども。
サーバ側 CGI を C++ 版に置き換え。CPU 負荷が半分程度になってくれれば良いかなと期待していたのだけど、結果は 1/10 まで下がってくれた。平均で 30% 台の後半だったのが、一気に 3〜4% にまで下がってくれるとは。[MRTG CPU グラフ]
スクリプト側にも多少問題があったので、それを削ったとはいえ……やっぱり ruby って遅いのね。
まだ結果のチェックルーチンは入れてません。チェックルーチンまで入れようとすると、クライアントとの通信プロトコルまで変更しなければいけないので、どのタイミングで入れようかと悩んでいるところです。
ユーザが増える前に対策を済ませておいたほうが良いのはもちろんなのですが、しかし、サーバ側のリソースにかなりの余裕ができたので、クライアントが増えて欲しいところでもあり……。微妙なところなんですよね。
やっぱりサーバ側でのチェックルーチン追加を最優先にしよう。計算結果が無駄にならないと確信できる環境をつくって、それで安心して勧誘なり宣伝なりができるようにした方がいい。
チェックルーチン追加の際の移行手順ですが、サーバ側で新アドレスを作成し、対応クライアントを配布すると同時に、現在のサーバ側アドレスからのブロック割り当てを停止の予定でいます。
ただし、MMX 版でのバグ発覚時とは違い、それまでに検索が済んだ鍵領域のリセットは行いません。とりあえず検索が済んだ領域に関しては今までの結果を信用することにして、引き続き残りの領域の検索を行い、最後まで行ったけれどもそれでも鍵が見つからなかった場合のみ、サーバ側チェック導入前の領域を再探索する予定です。
PROXY 対応や、ネットワークエラー時の一定時間後自動リトライといった既に入っている要望とどちらを優先するか考えたのですが、やはりエラーが無いことを保障できる環境を作るべきだと決断しました。
専用マシンを作りたい方へ。Athlon64 や Itanium は無意味なのでやめた方が良いです。C2 暗号自体が 32bit 処理向けにかなり最適化された暗号なので、64bit CPU に意味はありません。
コストパフォーマンスを最優先するなら、370 Celeron か AthlonXP/Duron の実クロック高めのモデル (L2 キャッシュは 128kB もあれば十分ですので) で複数台投入が一番だと思います。478 Celeron はクロック当たりの処理能力が低いのと消費電力が高いのであまりお奨めしません。
実際私は Celeron 1.3 GHz が 2 台に、Celeron 2.8GHz が 1 台体制で参加していますが、Celeron 2.8 は止めておけばよかったかなと後悔していますので。
どうしても 1 台だけで最高速という話でしたら、P4 Xeon 3.06GHz dual のマシンで c2bf 4 個起動という方が現状での最高速のようです。2ch PC 自作板のスレッドでも報告されていましたが、起動中の c2bf 合計して 324 秒で 4 ブロック処理できているそうですので、一日当たりの処理量は 1067 ブロックになります。(サーバ側の記録では現在処理ブロック数で 1 位の方だと推測してます。一つだけ 10000 の桁に突入しているので目立つのですよね)
全てが順調にすすめば、Rec-POT の分解と HDD のダンプ、および IEEE1394 キャプチャができる方であれば、1 時間程度の計算で誰でも TS の復号ができるようになるはずなのですが…… D-VHS のヘッダ調整や PCI ボードの改造よりは敷居が低いはずなんですけど、それができない方を救うことは私にはできません。
とりあえず、Rec-POT 120S の 2 台目を駆け込み入手済みだったりするので、総当り以外で何とかする方法は考えています。AVHDD crack [21] - 今後の予定 で書いた Time Memory Trade Off 攻撃ですね。
引きこもってコード書き。とりあえず UNIX 向けクライアントのチェックルーチン対応は目処がたった。次はサーバ側の修正をしてテストの予定。
エクスプローラ再起動時のタスクバーアイコン消滅もチェックルーチン追加版で対処予定です。
UNIX 版のチェック対応クライアントとサーバ側のテスト & デバッグはほぼ済み。後は WIN 用クライアントと PROXY 対応。とりあえず WIN 用では設定ダイアログも作ってあげなければいけないか。
目標は今週末に入れ替えなんだけれども……そのためにも今日明日で WIN 用のチェックルーチン追加周りの作成とデバッグを済ませておかねば。
WIN 用もチェックルーチン周辺のテストと explorer 再起動時のアイコン復活まではテストできた。後は PROXY 対応と順位表示追加と非 MMX 版への修正反映が済めばチェック版に移行できる。
はやければ明後日あたりには移行できそう。もう少し頑張らねば。
チェック対応クライアント最終テスト中。全バージョンとも問題なく動いてくれているようなので、明日には入れ替えができそう。
一応予定としては、明日の昼、12:00 〜 13:00 にかけてサーバ側アプリケーションの入れ替えをするつもりでいる。参加者には悪いと思うけれども、今回も対応クライアントのダウンロードと旧バージョンと置き換えての再起動が必要になる。
後チェック対応コード追加によって、クライアント側の実行速度が 5〜10% 落ちているのも悲しい点。仕方がないことだと判ってはいるんだけどね。
分散 C2 総当り攻撃、チェック対応版への置き換えを行いました。一応 PROXY 対応や explorer 再起動時のアイコン消滅等、今までに要望されていた機能のいくつかも追加しています。
また、結果報告時に累計処理ブロック数でのランキングをサーバから返信して、それを tips 部に表示するようにしてみました。本当は複数の PC を合計した、参加者毎のランキングを出したい & サーバ側で HTML でランキング表出力したいところなのですが、ちょっと面倒だったので、楽なほうへ逃げてしまいました。
そのうちその手の機能も追加されるかもしれません。またチェックルーチンを組み込んだことでサーバ側のソースも出せるようになったので、機能追加してやるからソースよこせという要望にも対応できたりします。
エラーチェック機能を追加したところで、この程度のクライアント数なら殆ど意味はないだろうとか考えていたのだけど……。サーバ側でエラー検出したから拒絶したぞというシステムからの通知メールが ひところの Sobig.F なみ に届いてるよ。
傷が深くなる前にエラーチェック対応できて良かったと、人生の明るい側面を見ることにしよう。えーと、"error - failed on report()" とかログに出力されて止まってしまう方、オーバークロッキングは控えめにお願いします。
とりあえずチェックルーチン導入前にこれらの PC が計算してくれたブロックは処理済から未処理に戻しておかないと。チェックルーチンの実現方法を教えてくれた方にはいくら感謝しても足りない。名前を出してしまうと多分迷惑をかけてしまうと思うのでこんな形でしか感謝を表現できないのが心苦しいぐらい。
"error - failed on get_block () - 0, waite 15sec" と言われてしまう方、去年旧バージョンを動かしたことがあって、今年に入ってから c2bf を起動したことがないマシンだったりするとそのエラーが延々と表示され続けることがあります。
以前取得した ID がレジストリに残っているけれども、結果報告が 1 件以下で 1 週間以上放置されていたために ID がサーバ側から抹消されてしまっている場合にそのエラーが出ることがあります。
本当はそんなケースでは動作を止めるつもりだったのですが……ええ、バグです。サーバから拒否されているのをネットワークエラーと勘違いしてリトライループに入ってしまっています。おまけにエラーの詳細ログ出力してないし。
とりあえず、この場合はレジストリから HKEY_CURRENT_USER\Software\marumo\c2bf.exe (UNIX 版の場合は ~/.c2bfrc) を削除してください。
申し訳ありません。クライアント側は無実でした。私の参加している PC でも 3 台中 2 台が止まっていたために気がつきました。まだ原因調査中なのですがサーバ側でのデータ保持に際して、排他制御の甘い部分が存在し、ワークブロック情報に異常が発生していたようです。
この対処で完全か自信がないのですが、一応推測される穴は塞いでみました。これでしばらく様子を見たいと思います。とりあえずサーバ側で異常データを削除したので、既に化けてしまったブロックの割り当てを受けたクライアントでは、初回起動後の結果報告時に "error - failed on report()" が表示されて止まってしまうかと思いますが、その状態からもう一度起動してみてください。
17:00 のサーバ側修正で、今回の問題は解決されたはずです。敗因は flock() と FILE * のバッファリング周りでした。素直に open() を O_EXLOCK 付けて使うことで逃げました。思うに、flock(fileno(fp), LOCK_UN); fclose(fp); なんてしないで問答無用で fclose(fp) していれば問題は起きなかったような気もしてます。
えーパフォーマンスを最優先するためにサーバ側ではバイナリ独自フォーマットファイル（というよりもほぼ構造体ダンプ）を選んだのですが……それでバグ出してたら言い訳できませんね。はい。次からは負荷テストも済ませてからの公開が必要と学習しました。
風邪でダウン。２回休み。
いま動いているチェックアルゴリズムは、ワークブロック内のランダムな鍵で暗号化を行って暗号文をクライアントに渡し、クライアント側で対応鍵を発見した場合はブロックの報告時に暗号文と鍵のペアを添えるというだけのものです。この方法には一つ大きな穴があるのですけど、そこまでコストをかける妨害者は出ないと思われる（コストを厭わない妨害者が出る = S-Box の正しさの間接的証明 = 総当りの目的達成だったりする）ので放置してます。
type.h の WORK_UNIT::c[8], WORK_UNIT::k[8] や network.c の get_block() やら report() やらを見ればどんなことをしているかはすぐにわかると思います。
ID をレジストリに置いてるのは、別フォルダから複数起動してる場合でも同じ PC からのレポートだと認識できるようにするためだけだったりします。なので複数 PC にレジストリから ID コピーして、単一 ID で動かすようにしても c2bf の実動作には影響はありません。
問題があるとすれば、ユーザごとのランキングを出すときに参加 PC 台数が少なく表示されることと、一度に割り当てるブロック数を ceil(log10(completed_block)) で算出しているので、順位が表示されるまで多少時間がかかるようになるくらいです。
上の記述についてもう少し説明すると、今までに報告を上げたブロック数が 0〜10 個のクライアントには一度に 1 ブロックしか割り当てず、11〜100 個まで報告を上げたクライアントには 2 つ、101〜1000 までのクライアントには 3 つという割り当てになっています。
複数 PC で ID をまとめる人が増えたせいか、手元のクライアントの順位がざくざくと下がっていく。先月末のリセットからフルタイム参加してる Celeron 2.8 は 6 位でまだ動きがないけど、パートタイムの P4 2.0 とか P3 1.26 とかは軒並み 3 〜 10 ランクを落としてる。
えーと、ID 統一するかどうか悩んでる方、今サーバ側でのランク表示を作成中だったりするので、今週末まで待てるなら、ID 統一は止めといてください。いまさら遅いかもしれませんが、ID 統一する場合は、旧 ID も記録しておいた方が良いです。ユーザランキングができたときに、旧 ID で報告したブロック数が加算されなくなってしまうので。
作成中のユーザランキング機能は、2ch 自作 PC 板 の「分散 C2」スレッド 340 さんので正解です。チーム制までは考えていなかったのですけど……なしじゃダメですかね。
それはさておき、今日 6 -> 7 位に移動した Celeron 2.8 GHz マシンはまだ 10000 ブロックを越えてません。割り当てブロック数はまだ 4 個ですし、サーバ側で確認しても 9582 block (21:00 現在) と表示されてますし。
今のところ 10000 越えているのは 5 位以上の ID の方だけですね。1 位の方は明日あたり 20000 を越えてそうですけど。
やっつけですが、分散 C2 総当り攻撃 にユーザランキング機能付けました。とりあえず WIN 版を使用している人は、2.1.0/1.1.0 のクライアントをダウンロードして、置き換えて、再起動して、アイコンをクリックすると出るメニューから「RANK」を選んでください。WEB ブラウザが開いて登録ページが開くはずです。
UNIX な人は "head ~/.c2bfrc" して先頭行に表示されている "id=00112233445566778899aabbccddeeff" という部分を "http://www.marumo.ne.jp/c2/bf/user.cgi?" に引っ付けた URI へアクセスしてください。この id の例で言うと "http://www.marumo.ne.jp/c2/bf/user.cgi?id=001122334455667788aabbccddeeff" になります。この通りにしたけれどもステータスページに飛ばされてしまう方、id が間違ってないかもう一度確認してから、メールを投げるなり、2ch のスレッド (自作 PC 板 / ダウンロード板 / ハードウェア板 のはチェックしてます) に書き込むなりお願いします。
とりあえず最低限の機能で、まだメモの入力とか PC 毎のブロック数表示とかの機能は作ってません。できるのは、純粋に順位表示だけです。
WIN 版は、このバージョンから c2bf.dat の書き込み頻度を 1 分に 1 回に制限しました。
つかの間の 1 位でしたか。まさかマシン (ID) ランク 1・2・3 位が同一人物だったとは思いもしませんでした。えーと……参加ありがとうございます。
で、チーム参加してると思しきユーザ名が話題になっているようですが、私としては代表名義で参加してても別にいいんじゃないのというか、結果として稼動台数が増えてくれるならそれで OK というかそんな感じです。つーかそれ言い出したら元々マシンごとに固有のはずの ID ランクでも複数台で ID 共通化してる方もいる訳ですし。
ランキング機能についてですが、チームランキングは今のところ考えていなくて、ユーザ名の変更とかマシンの別名義への移動とかができる切り口を作るつもりでいます。後はフィールドは用意してるけど画面作ってないメモ欄の入力機能とか。(構成情報とかが書き込まれることを期待してるフィールドだったり)
レジストリを消してしまって ID がロストしている場合、ログファイル (log.txt) が残っていれば、それをメールしてもらえれば ID を調べて返信します。