こちらでどうぞ。
MERIKEN's Tripcode Finder(旧CUDA SHA-1 Tripper MERIKEN's Branch)は
2012年9月現在で最速の12桁トリップ検索プログラムです(最高速の記録は
1689.88M tripcodes/s)。CPUのみでも検索できますが、NVIDIA GeForce
シリーズのビデオカードを使用すれば非常に高速に検索を行うことが
できます。特徴は以下の通りです。
・ビデオカードのGPUによる高速検索(CPU検索にも対応)。
・GUIによる簡単な操作(コマンドラインからの使用も可能)。
・正規表現によるターゲットの指定。
・漢字等のShift-JIS文字を含むキーの探索。
・ヒット率、ヒットまでの平均時間等のさまざまな情報の表示。
・ターゲットの数の制限の撤廃。
・10桁トリップ検索への暫定的対応。
・検索速度の実行時の最適化。
・GPLv3で公開されたソースコード。
■入手先
http://www.meriken2ch.com/programming/merikens-tripcode-finder
■前スレ
http://anago.2ch.net/test/read.cgi/software/1311428038/
【OS】Windows XP/Vista/7/8
【ビデオカード】NVIDIA GeForceシリーズ (ビデオカードがなくてもCPU検索は可能)
【その他】使用するためには次のソフトウェアが必要です。
Microsoft Visual C++ 2010 再頒布可能パッケージ(x86)
http://www.microsoft.com/ja-jp/download/details.aspx?id=5555
Microsoft .NET Framework 4
http://www.microsoft.com/ja-jp/download/details.aspx?id=24872
NVIDIA Display Driver Version 270.81以降 (ビデオカードを使用する場合)
http://www.nvidia.co.jp/Download/index.aspx?lang=jp
乙です。
どもども。このスレでもよろしくお願いします。
昔Athlonだったのでmtyとか使ってた
当時10Mtrips/sで神だったのが1500Mとかどうなってるんだよｗ
トリップ12桁になったから単語の自由度も増えてそれでも探し飽きることはなさそうだけど
次の目標は2G超えですｗ トリップ探しは結構面白いですよね。正規表現が
使えるようになったのでかなり自由に探せるようになりました。
気になって来ました。やっぱ一時停止の機能は必要ですね、これ。
Win32のメッセージ通信を使うしかないのか…
以前からどうも怪しいと思っていたので、具体的な例が見つかって大変助かりました。
問題はこれからどうするかということなんですけれども…
ヒットしないのです。
#regex
^[Aa]+$
^\.+$
^\.*AAA\.*$
^AAA\.\.
正規表現のパターンは内部である程度展開されているんですけど、
問題があるとしたら、(1)展開の仕方か、(2)検索時の見逃しか
どちらかのはずです。
> expandedPatternArray[ 10] = {`AAA..', 0}
> expandedPatternArray[ 11] = {`AAA.........', 0}
この部分でexpandedPatternArray[11]の条件が
expandedPatternArray[10]の条件と重なっているのが問題だとおもわれます。
expandedPatternArray[11]を取り除くようなルーチンを書いてやれば
解決するはずです。今あまり時間がないので今晩やろっと。
http://developer.amd.com/tools/hc/CodeXL/pages/default.aspx
今去年組み立てたPCにWindows 7をインストールしているところです。
Radeon HDとOpenCLの組み合わせが楽しみです。
たま〜に引っかかるはずのパターンがなかなか引っかからなくて気にはなっていたのですが、
これで本当にすっきりしました。報告していただいてありがとうございました。
最強のツールにまた一歩近付きましたね。
どもども。これで野望にまた一歩近づきましたｗ
サンプルの一部が最新のSDKに対応していなかったりと
投げやり感が半端ではありません。「資料がない」という話は
よく目にしたけど、こういうところもCUDAのほうに開発者が
流れる原因になっているんでしょうねえ。
出来ればひとつのバイナリでNVIDIAとATI/AMDの両方のグラボに
対応させたいので、OpenGLについてはのんびり調べてみたいと思います。
つかCLはバイナリ互換でなくてソース互換だったような…
またやらかしてしまった… 「一つのバイナリで」と書いたのは
一つの実行ファイルでCUDAとOpenGLの両方に対応する、という意味です。
サンプルを見てたら、とりあえずOpenCL.libをリンクして
CL/cl.hppをインクルードしてやればOpenCLのAPIは呼び出せるらしいことが
わかりました。なんとか楽をして既存のプロジェクトからAPIを
呼び出せるようにしたいところです。
OpenCLのカーネルを呼び出すことに成功しました。これで
環境は整ったので後はひたすらOpenCLのコードを書くだけです。
しかしこれ、アプリケーションを実行するたびにカーネルをコンパイル
するようになっているんですね。デバッグとか超めんどくさいことに
なりそうな予感…
コンパイル済みのバイナリを与えること(オフラインコンパイル)も可能だけど、
いろんなデバイスで使われる場合は実行時のコンパイル(オンラインコンパイル)でないとつらいのかな
やっぱりそういう機能もあるんですね。CUDAだとコンパイル時にComputing Capabilityを
幾つか指定できるようになってますけど、AMD APP SDKの場合はどうなんだろう…
とりあえず一時停止の機能を何とかしないと…
とりあえずMutexを試してみることにしました。計算資源をMutexで管理すると
考えるわけです。
検知することができました。これであとは検索プロセス側の処理を
実装するだけです。
Mutexが使えるのがわかってからはかなり楽でした。
Mutexを一時停止状態を表すフラグとして使っているので
本来の使用法とはだいぶ違うのですが、うまく動いているので
問題ないでしょう。GUIをあとちょこっと直してから
明日辺りにBeta版をうpする予定です。
検索パターン一覧内でパターンの位置を移動できるようにしました。
ちょっとした変更ですけどかなり使い勝手が違ってきます。
Visual C#はVB並のお手軽さでロジックをそのままの形で記述できるのが
実にいいです。あとはエラーチェックの気になっている部分を直したら
Beta版の完成です。
ちょっとリアルが忙しかったんでGUI版テストしてませんでした。
せっかくCPUスレッド数の指定とかも盛り込んでもらったのにすみません。
今から回してみます。
GUI版ぜひ使ってみて下さい。1週間でC#を勉強しながら
作った割にはいい出来ですｗ
すごく使いやすいですよ。
それとブロック/スレッド各オート時で
自分で設定詰めたものとあまり遜色ないくらい速度出てます。
安定して速度が出始めるまでには5分から10分はかかっていますが
細かく設定詰めなくてもここまで出るのはユーザ側にとってはかなりありがたいかと。
「お手軽に最高の性能を出す」のが目標なのでそう言っていただけると
嬉しいです。性能改善という点ではCUDAではほぼやれることはやり尽くしてしまった
感があるので、やっぱり残りはCPU検索とRadeonへの対応ですね。
そのコンセプトからするといい方向かと。
DOS窓でコマンド打ってまでやろうと思わない人のほうが多いでしょうしｗ
ただ、CPUのオートについてはまだ改良の余地があるかもしれません。
オートより6スレッドの方が自分の3820QMじゃ安定して速度出てました。
オートだと100%使い切っちゃってましたし。GPUドライバ周りのCPU負荷が高そう。
自分の使った感想だと6スレッド≧7スレッド＞8スレッドでした。トータル速度的にも。
トリッパー回しながらPCを使うという場面を想定してもオートだときつかったです。
いちおCPUは非力じゃないはずなのにオートだとまともに文字打てなくなりましたから。
ただ、CPU単体検索という面に於いても従来のソフトの2倍近く速度は出てるんじゃないですかね。
自動だと 132.72M
8スレッド 131.05M
7スレッド 132.40M
6スレッド 131.47M
みたいな結果となりますのでCPUの種類によっては自動が最適なんてこともあるみたいですよ
CPU検索のみを実行しますと
オート設定だと12.49M
8スレッドだと12.41M
7スレッドだと11.18M
6スレッドだと10.32M
5スレッドだと9.28M
4スレッドだと8.19M
3スレッドだと6.23M
2スレッドだと4.25M
1スレッドだと2.11M
という結果で同時期のハイエンドGPUの8800GTXは
GPU単体だと121.35Mなので10倍近く高速と言う結果となります
あと負荷掛け続けるとCPUが過熱し過ぎたのか警笛が鳴って焦ったｗ
やはりGPGPUはエアフローに気を付けないとCPUも熱くしてしまうので要注意ですね
CPU検索の自動設定は、何も考えずにCPU検索スレッドの数を
「(論理スレッドの数) - (GPUの数)」に設定しているだけなので、
これも変える必要がありますね。たぶんIntelの石ではhyper-threadingの
おかげでスレッド数を下手に増やすと遅くなる場合もあるのでしょう。
ここらへんはもうちょっと調べる必要があります。
現在の実装だととにかく速度を出すために目一杯計算資源を使っているので、
利便性の点からはかなり改善の余地があるでしょうねえ。検索スレッドの
優先度を低く設定してやるのも手かもしれません。今考えているのは検索の設定で
速度を「速い」とか「最大」とか「ゆっくり」とかから選べられるようにすること
です。GUIの実装が一段落したらぜひ取り組みたいですね。
詳しい報告、ありがとうございました。スレッド数を増やしてもペナルティに
ならないのはやはりXeonだからなんでしょうかね。非常に興味深いところです。
8800GTXも結構速度が出てますね。テスト用に一個欲しいところです。
このプログラムはシステム全体にとんでもない負荷をかけるのでかなり注意する
必要がありますね。私のメインのデスクトップPCはケースの蓋が開けっ放しです。
次からははじめからこんなの
http://www.dangerden.com/store/popup_image.php?id=428
か、こんなの
http://www.dangerden.com/store/popup_image.php?id=250
にしておきます…
http://www.dangerden.com/store/dd-torture-rack.html
http://www.dangerden.com/store/dd-extended-air-box-eatx.html
現在実装しているところです。とりあえずここのコードを使わせてもらって
ウィンドウの位置は保存されるようになりました。
http://stackoverflow.com/questions/105932
あとは各タブの状態を保存してやるようにすればGUIの実装は一段落ということに
なります。
そこはどうなんでしょね。
Keplerは従来よりもCPU負荷がきついですから
Fermiまでとは違うという事も考えられます。
いずれにせよ色々なプラットフォームで自動で最高の結果を出そうとすると
相当にデータ集めが必要なんだと思いますよ。単純に。
ホントにプログラミングとかかじったこともないド素人の意見ですけども。
俺のノートはパワーもないしOCの幅もないけど、開発に携われるだけでうれしいです。
新バージョンにクレジットしてくださっただけでも本当にうれしかったです。
できることはできる範囲で全力でやります。
> Keplerは従来よりもCPU負荷がきついですから
こういう要素もあるんでしょうねえ。最適化の作業を進めていると
各Compute Capability毎に1枚テスト用のカードが欲しくなりますけど
流石にそんなわけにもいかないですからねえ。こうやって色々報告していただけると
助かります。
3820QM+GTX680Mの最新版でのベストスコアは
GPU(224Bl/SMX)：294+CPU(6T)：26の320MT/sでした。
これは瞬間値じゃなくて長時間平均をとりました。
CPU、GPUそれぞれの単体でも従来よりずっと速いです。
私としてはこのプログラムができるだけいろんなグラボで動くようになればいいと
考えているので、グラボの性能自体はそれほど気にしていないのです。実際のところ
ちゃんと動いているのが確認できて安心しましたｗ
Keplerちゃんもなかなか頑張ってますね。CCが3.0の場合はCPU検索スレッドの数を
1つ減らしてやるぐらいがちょうどいいのかな。あとで修正しておきます。
今までのことを考えるととんでもないスピードだと思いますよコレ
確かにFermiの方がCUDAは速いけどもKeplerでも十分に速いと思います
というか構造上KeplerにCUDAのスピード求めるのも酷ですしね
あとノートは数日前にGTX6xxMXが発表されてKepler化がどんどん進むと思われます
こんだけ省電力で3D性能(に限って言えば)上昇してればKeplerシフトは進むわなぁ
やはり動かす時は同じComputing Capability同士のGPUを使用した方が良さそうです
ついでに12桁での速度は
FX4600単体で80.25M
GPUx2で202.17M
CPUGPU込みで210.00M
消費電力は最大664Wとかなりの電気食いです
548Wも食って12M位しか出ないCPU
552Wとチョイ上回る程度で202MもでるGPU…
ま〜ノートにFermiとか想像できないですからねえ。7xxシリーズでも
一部はKeplerのままかもしれません。
Compute Capabilityが違うカードのために幾つかcubinを用意してるんですけど、
これらのバイナリを同時に使うことは出来ないということなんでしょうね。
さっきソースでエラーチェックを怠っていた場所を特定したので、
新しいバージョンではちゃんとエラーが出るはずです。
Netburstはもう仕方がないですね。自分の使ってたPentium 4もとんでもない
爆熱仕様でした…
MERIKEN's Tripcode Finder 0.05 Beta 1
http://www.meriken2ch.com/programming/merikens-tripcode-finder
今回の変更点は以下になります。
・ウィンドウの設定の保存。
・GUIの改善。
・正規表現のバグの修正。
・エラーチェックの改善。
このバージョンに問題がなければ、これをこのまま安定版にする予定です。
見逃していました。すいません… 修正したバージョンに差し替えておいたので
ダウンロードされた方はお手数ですがもう1回お願いします。
MERIKEN's Tripcode Finder 0.05 Beta 2
http://www.meriken2ch.com/programming/merikens-tripcode-finder
いやーそれがノートの6xxシリーズでも675Mとか670MなんかはFermiなんですよ。
そして当然ながら、全く同じ環境でも680M比で675Mは温度が10度以上高い。
真夏とはいえ、ゲームやるとGPUが90度オーバーとかいうトチ狂った温度になってましたから。
しかし675Mは580Mのリネームな上に
今度は(多分)Keplerの675MXを出すとかなんで分かりづらすぎです。
思ったような酉が出てきてないのでもう少し廻しますが、WCG構造解析しながらでこれは結構出てると思います
便利なツールをありがとうです
90度で常用だとかなり不安ですねえ。一応設計上は97℃まで大丈夫なはずですけど…
>>54
どもども。CPU検索はもうちょっと速くしたいですね。
アーキテクチャが変わっているそうで… 今持ってるのは去年試しに買った
5770だけなので、とりあえずコードをOpenGLで動くようにしてから、
最適化をおアーキテクチャ毎に行うことになりそうです。
まあなんにせよOpenGLへの移植はかなりの長丁場になりそうなので、
CPU検索の性能向上と並行して行うことになるでしょう。
とりあえず簡単そうな12桁検索のほうから手を付けたいとおもいます。
次のコードが良さ気なんですけど、まずアセンブルできる環境を
整えないといけないですね…
次のはIntelの開発者が作った64bit版のルーチンで、
Improving the Performance of the Secure Hash Algorithm (SHA-1)
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1?page=1
こっちが32bit版らしいです。
http://cvs.openssl.org/fileview?f=openssl-addons/intel-accel/sha1-586.pl&v=1.1
Tesla K20も試してみたいけどさすがにお値段が…
K10も$3200ぐらいですからね。
GPUと並行できるのってかなり強みだと思います
性能的にはそれほど最適化されてないのです。
どうやらSSE3をつかえばかなり高速化出来るらしいということまでは
わかったのですが…
開発進行中なのはMERIKENさんのだけじゃないでしょうか
…などと書いてたんですけど、Macで次のコマンドを実行したらNASM用のコードが
出てきました。
perl sha1-586.pl win32n
出力もそれっぽいし、面倒くさいこと無しにこのまま使えるかも…
> %ifidn __OUTPUT_FORMAT__,obj
> section code use32 class=code align=64
> %elifidn __OUTPUT_FORMAT__,win32
> $@feat.00 equ 1
> section .text code align=64
> %else
> section .text code
> %endif
> ;extern _OPENSSL_ia32cap_P
> global _sha1_block_data_order
一応今の開発環境だとAVXまで対応できるんですけどねｗ
色々面白いことが出来るんじゃないかという気はしますけど、
x86系のアセンブラをいじるのはそれこそ10年ぶりぐらいなので、
今後の進展は神のみぞ知るといったところです。
無理に最新の拡張命令に対応する必要もないと思いますけどね
このSSE3用の_sha1_block_data_orderというルーチンは、
どうやら次のEric Young氏によるSHA-1の実装と組み合わせて使うらしいです。
> # define HASH_BLOCK_DATA_ORDER sha_block_data_order
:
> __private_extern__ void HASH_BLOCK_HOST_ORDER (SHA_CTX *c, const void *d, int num)
http://www.opensource.apple.com/source/CommonCrypto/CommonCrypto-7/Source/sha_locl.h
これはかなり楽して速度を上げられそうな予感…
SHA-1ではAVXは使いませんけど、実はAVXによるBitslice DESの実装にはかなり
興味があるのです。なんせレジスタ長が128bitから256bitになっていますからね。
Bitslice DESの特性を考えれば、AVXによる恩恵を直接受けられるのではないかと
思われます。その前に10桁検索をSSE2に対応させるのが先なんですが…
それが有限の時間の中で一番効率がいいと思います。
我々下々にくだるご光栄のおこぼれも増えると思われます。
must to do 事項はなかなかしんどいですから。
ああ私は他力本願‥‥‥
うちのIvyちゃんにできることがあれば…
ワッパは少なくともこのスレじゃ最強なはずだし気楽に回せますよ。
全開でもCPUは45Wとかですから。
intelのなら特許からんでくるかもね(*‘ω‘*)
Intelの中の人のコードは利用は自由だと書いてあるので問題ないでしょう。
> It is provided 'as is' and free for either commercial or non-commercial use.
http://software.intel.com/en-us/articles/improving-the-performance-of-the-secure-hash-algorithm-1?page=1
GRYTOGRAMSはGPLと互換性があるので、こちらのコードも
MERIKEN's Tripcode Finderで使用するするのに問題はないでしょう。
> ALTERNATIVELY, provided that this notice is retained in full, this
> product may be distributed under the terms of the GNU General Public
> License (GPL), in which case the provisions of the GPL apply INSTEAD OF
> those given above.
http://www.openssl.org/~appro/cryptogams/
とりあえず今はSSE3を使ったSHA-1のコードを動かすことが最優先です。
>>69
12完とか数世紀単位ですよw
>>70
新しいバージョンのテストをぜひよろしくお願いしますです。
アセンブルして実行ファイルにリンクできました。
ここまでは簡単すぎて拍子抜けするぐらいです。
問題はこのルーチンを実際にどうやって使うかなんですけれども…
書いたら、信じられないことに1発で動きました! でもperlのスクリプトで
何もオプションを指定しなかったせいか速度はそこそこです。SSE3を使うコードを
生成させるオプションがあるはずなんだけどなあ…
何やら内部で外部変数を参照してCPUの種類の判別をしているみたいなんですが、
何をやっているのかさっぱりわかりません。"_OPENSSL_ia32cap_P"って
なんなんだろう…
こいつですね
http://www.openssl.org/docs/crypto/OPENSSL_ia32cap.html
CPUIDを読みだしてプロセッサを判別する…ってことか
ちゃんと特許検索してみ(*‘ω‘*)
ここまですんなりいくとは思いませんでしたｗ
何事もためしてみるもんですね〜
>>79
間違い無くそれですね。とりあえずその変数をチェックしている部分は
全部削除してしまうことにします。
…が、スピード自体はかなり微妙です。確かに今までのコードよりちょこっと速く
なってることはなってるんだけど、思ったほどではないです。これはもともと使っていた
SSE2 Intrinsicsで書かれたルーチンがかなり速かったということなのかなあ。
なるな… 64bit対応はもうちょっとあとにする予定だったけど、せっかくCPU検索の
速度向上に取り組んでるんだから前倒しにするのもいいかもしれないですね。
あ、あとアプリケーションを終了させたときに.NETの例外が稀に発生するバグを
見つけました。バージョン0.05の安定版では直しておきます。
経過時間が1ヶ月分増えてしまうのですが、これも直しておきました。
結構色々でてくるもんですねえ。
12桁検索が32bit版よりも5M TPSほどはやくなっていました。13%ほどの
速度向上になります。やっぱりx64のほうが効率がいいって本当だったんですね…
これも一発できちんと動いたものの速度の向上はわずかでした＼(^o^)／
今まで使っていたSSE2 Intrinsicsで書かれたルーチンが予想外に効率が良かった
というわけです。まあ64bit版と定格のCore i7-3770K単体の組み合わせで
40M TPSを超えてるんで結構な速度なんですけど、なんとも微妙な結果です。
とりあえず64bit版が大分速くなるということはわかったので、
これはバージョン0.06で使えるようにしておきます。
とりあえず12桁の方はこれ以上何も思いつかないので、今度は10桁トリップの
CPU検索のほうを速くしようかな。こっちは最適化の努力を全くしてなくて
SSE等のSIMD命令を一切使っていないので、速くなることは受け合いですｗ
まあ今の実装が遅すぎるだけなんですけれども…
CUDAのときのようにガリガリに最適化されたJohn the Ripperの実装を
持ってきてもいいし、自分でIntrinsicsを使ってちまちま最適化してもいいし、
色々手はあります。
超えられるようにがんばって！
AVX無しでmtyを超えられたら言うことないですねｗ
色々やりたいこともあるので当分の間楽しめそうです。
なんだかオラ、ワクワクしてきたぞ!
AVXってちゃんとした整数演算を256bitでできるんけ(*‘ω‘ *)？
これで遠慮無くIntrinsicsを使ってコードを書き直せます。
まず最初にCで書かれたBitslice DESのルーチンをSSE2で書きなおして、
それからさらにAVXを使って書きなおしてやる予定です。AVXはレジスタ長が
倍になっただけのはずなので問題ないでしょう。
使ってメインのモニタと入力装置につなげてやりました。これで気軽に
移植の作業ができます。1年ぶりぐらいにPC周りを大掃除したんですけど、
やっぱ整理整頓って重要ですね…
MERIKEN's Tripcode Finder 0.05
http://www.meriken2ch.com/programming/merikens-tripcode-finder
>>84-85のバグを修正した以外は、Beta 2と同じです。
CUDA DEVICE
CUDA Device Count: 1
Device No.: 0
Device Name: GeForce GTX 460
Multiprocessor Count: 7
Clock Rate: 1400MHz
Compute Capability: 2.1
CPU
===
Number of Processors: 8
Number of Search Threads: 7
TARGET(S)
=========
0: "TEST//"
TRIPCODES
=========
◆TEST//xz05/X #BｱXｸC｡Vﾗ∀Zｵ (42 B1 58 B8 43 A1 56 D7 81 CD 5A B5)
STATUS
======
Performing a forward-matching search for 1 pattern (1 chunk)
with 6 characters on CPU and GPU(s):
CUDA0: 271.5M TPS, 48 blocks/SM
0.105T tripcodes were generated in 0d 0h 5m 58s at:
302.28M tripcodes/s (current)
GPU: 280.99M tripcodes/s
CPU: 21.29M tripcodes/s
291.47M tripcodes/s (average)
On average, it takes 2.7 minutes to find one match at this speed.
1 match found at 10.04 matches/h and 104.53G tripcodes/match.
The actual matching probability is 34% lower than expected.
0% of matching tripcodes were invalid.
あ、早速有り難うございます。CUI版もちゃんと動いていますね。
GUI版の作成にあたってCUI版にもある程度手を入れざるを得なかったので、
ちゃんと動作するかどうか不安だったんですよね〜
Bitslice DESのルーチンをまとめてえいやっとSSE Intrinsicsで書きなおしたら
案の定動きませんでしたorz おとなしく動作確認をしながら少しづつ
書き直すことにします…
TOP カテ一覧 スレ一覧 2ch元 削除依頼 ▲
【ゴム】GOM Player Part35【プレーヤー】 (210)
漫画用画像ビューア総合スレ Part9 (252)
VNC使ってますか？ Part12 (811)
foobar2000 Part76 (782)
Chromium派生ブラウザ CoolNovo(ChromePlus) Part6 (326)
foobar2000 Part76 (782)
--log9.info------------------
【ようは】羽田〜関空ｼｬﾄﾙｴｱﾗｲﾝの新設を【運賃】 (280)
【ダメ空港】関空から撤退する路線を予想するスレ (882)
【早期】羽田→関空の陸上航行と時間短縮【実現を】 (248)
●東京・大阪なら飛行機で行く人-1@airline→ (562)
大阪梅田から関西国際空港へは高速バスが有利 (265)
【退役】ANA B747-400 Part1【カウントダウン】 (433)
【ＡＮＡ】羽田−三宅島 4往復目 (688)
【JTA】日本トランスオーシャン航空【RAC】 (589)
-∴-装甲騎兵ボトムズ･VOTOMS専用スレッド44-∴- (391)
ガンプラ特売情報本スレ全国編Part.62 (335)
F-15イーグルの模型 part3 (639)
【1/32】ﾄﾗｯｸﾄﾚｰﾗ総合ｽﾚ24【ﾊﾞﾘｭｰ】 (478)
【良いMG】MG総合スレpart192【悪いMG】 (290)
【#121】ミニ四駆総合スレ【ブレイジングマックス】 (437)
プラ模型帆船 ２隻目 (329)
【FSS】ファイブスター物語83★永野護【MH】 (647)
--log55.com------------------
第一次世界大戦について語るスレ 5
1941の時点で日本はどうすれば勝ち組に入れたのか？
核兵器総合
ヒトラーユーゲントの少年少女兵を捕虜にしたら
韓国軍総合スレ366
【核武装】日本共産党でしか不可能【自主防衛】
【悲報】陸上自衛隊、クマに負ける
中国軍総合スレ part62
