Winny暗号強化プロジェクト「WinNynja(仮)」

Winnyの暗号を解読してブロックできるソフト
http://tmp2.2ch.net/test/read.cgi/download/1077006092/
↑これがどっか逝ってしまったので建てました。
まだ満足に物出来てない状況ですが、皆で強化策考えた方がいいかとも思いまして。
地道にまったりのんびり行きましょう。

2!

メリットは何？

方針：
　SafeNyと同じく、ws2_32.dllをラップして、TCPレベルでの暗号強化・偽装を行う
　暗号化にはOPENSSLのAES256-SHAを、擬装プロトコルはhttpsを使う予定
　また、当ラッパーを使っていないノードとも接続可能（認証失敗の場合はスルー）を目指す

つまりクラック対策できるってことか？

メリット：
　TCPレベルで通信制御するため、通信パターンの変更が比較的容易
　https擬装が完全に行えれば、SSL対応串経由も可能

デメリット：
　当然CPU負荷は増大
　通信量も若干増大

クラック対策も、UPとDOWNの通信量を比較監視すればある程度は可能かも。
元々は、一点壁に対する嫌がらせですw

と言う訳で、出来るだけ方針に則ったアイディアを募集しますです。
他スレでｶﾞｲｼｭﾂであっても歓迎します。
よろしこ。

負荷次第

お、やる気だな。ガンガレ>>1

あと、割とどーでもいいことですが、現在Squidの親子間のSSL化に取り組んでます。
http(s)の実際の挙動についての情報収集とOPENSSLの実装テストです。
ある程度安定して、かつ需要があれば副産物として公開してもｲｲんですが・・・有り得ねえなw

ついでに今までに思いついたアイディアをスプレッド。

・暗号鍵にIEの証明書が使えないか？
・通信途中に鍵を任意のタイミングで変えられるか？
・鍵交換をUDPで？
・TCPセッション張る前にICMPで氏んでるか確認した方が負荷が減る？

それぞれ、なんとはなしに問題ありそう。
エロくて暇な人、誰か検証ﾌﾟﾘｰｽﾞ

この板に、高度な話ができる香具師はもういない

いまいちよくわからん。
ＩＳＰの帯域制限対策ってことですか？

>>14
ぷらら辺りの、パターン検出してるとこなら多分効果あり。
IIJみたいな総量規制には多分逆効果。

ADSLなんで上りあんまり喰われなければ大歓迎です

>>1
お？ダウン板で久しぶりに期待です。
>>6のデメリットは俺にとっちゃまったく問題ないな

昼休みに、ちょっとここを流し読みしてみた。
http://tmp2.2ch.net/test/read.cgi/download/1075400646/

数分前まで接続していたノードを覚えて置いて、ランダムで強制中継を行うって案が浮かんだ。
つまり串のような動作をして、１ポップだけ挟む。
更に普通の串も混ぜれば、もう追跡不能だろう。
nyの中継と違うのは、クラスタ無関係に全くのランダムに中継先が選ばれると言うこと。
全部の接続にやらかしたら夥しく効率低下するが、嫌がらせ程度(1/16とか？)に混ぜれば効果ありかも？

言葉の意味はよくわからんがとにかく凄い自信だ

ｶﾞﾝｶﾞﾚ

よくわからんけど頑張って

皆様の暖かいご声援(ry
のたのたとやってきまつ。

で、httpsの実際の挙動だけども、なんか根本的に勘違いしてた自分をﾊｯｹｿ。
SSLセッション上にフツーのhttpが乗ってるﾀﾞｹﾅﾉﾈｰ｡
でも、串経由させようと思ったらちゃんとhttpヘッダつけんと駄目だろうなあ。
もっとも、串経由させる事にどれほど意味があるか不明。
これの所為で串壊滅なんかしたら恨まれまくりだろうし。

むしろ、>>18で書いた方式を発展させていった方がｲｲかも知れない。
過去に接続していたノードまでのホップ数は解っている訳だから、
ホップ数が少ない上位５ノードくらいを迂回先として設定すると、
ISPの負荷が軽減出来るかも知れない。
もう少し考えて見よう。

全然意味が分かりませんが、がんばってください。（・∀・）

全然期待していませんし、手伝う気もさらさらありませんが、がんばってください。（・∀・）

>>22-23
(・∀・)ｶｴﾚ!!


その他の次期Winny候補と天秤にかけていますが、がんばってください。（・∀・）

ウィ忍者！

自分が誰だかわかりませんが、がんばってください。

激しく1に期待。
nyを使うだけの男より

winnyの使用に耐えられるほどの串って存在するのか？

良い考えだと思うが地味すぎるのかな。

ｎｙが完全崩壊する前に、色々と次の手を考えるのは必要だと思うので
ここの１さんにも頑張って貰いたい

>>30
まあ、まだ崩壊といえる状況には全くなってないけどな。
マターリが基本のwinnyで、マターリできん香具師らは崩壊と思いこんで
いなくなってくれて結構。

兎に角！頑張ってください！
完成予定は・・・

完成は３年を予定しています。

【なおなおの】砂の器のVTR編集winny愛用か？【キンタマ】
http://202.212.211.213/news/image/20040316/naonao.html


【なおなおの】砂の器のVTR編集winny愛用か？【キンタマ】
http://202.212.211.213/news/image/20040316/naonao.html


【なおなおの】砂の器のVTR編集winny愛用か？【キンタマ】
http://202.212.211.213/news/image/20040316/naonao.html


【なおなおの】砂の器のVTR編集winny愛用か？【キンタマ】
http://202.212.211.213/news/image/20040316/naonao.html

３年あれば、全く新しいファイル共有ツール作れそうだな。

それはともかく、
Winnyの暗号を解読してブロックできるソフト の続きのスレなら
そのソフトを紹介しておかなくてはならないだろう。
http://www.netagent.co.jp/onepoint/

ＦＡＱ up
Ｑ：Winnyの暗号が解けるというのは本当ですか？
Ａ：本当です。詳細は[資料]Winny検知とブロックをご覧下さい。

Ｑ：Winnyのソースコードを手に入れたのですか？
Ａ：手に入れていません。あえて言えばメモリ上の実行イメージが我々が解析したソースコードです。

Ｑ：Winnyかどうかの判断はトラフィックのパターンの特徴からではないのですか？
Ａ：Winnyの暗号化通信を解読してWinnyかどうかを判断しています。

Ｑ：One Point Wall Winnyはノードの情報をログとして残すのでしょうか？
Ａ：残しません。残す情報は発信受信のＩＰアドレス及びポートのみです。ログに通信内容は含みません。
　　Winnyの検知画像はWinny検知システムの画像でありOne Point Wallでこのように見れるわけではありません。

Ｑ：One Point Wall Winnyで止めることができるWinnyのバージョンは？
Ａ：Winny v2 7.1, 7, 6.6 ,v1 1.14, custom5 ,custom6で検知フィルタ動作確認済みです。

Ｑ：Winnyで感染するウイルスによる情報漏洩を防げますか？
Ａ：Winnyが動作しているパソコンをwinnyのネットワークから切断しますので１次流出を止めることができます。キャッシュ保有者からの２次流出は止まりません。

Ｑ：ログはどのように出ますか？
Ａ：One Point Wall Winnyのログは以下のように出ます。
03/01-02:30:26.701121 [**] [1:0:1] Drop Winny Connection request [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} 192.168.1.1:4524 -> xxx.xxx.xx.xxx:17316

コピペしてから気づいたけど、

Ｑ：One Point Wall Winnyで止めることができるWinnyのバージョンは？
Ａ：Winny v2 7.1, 7, 6.6 ,v1 1.14, custom5 ,custom6で検知フィルタ動作確認済みです。

すでにcostomにまで対応してんじゃんｗ
WinNynjaが作られても対応されるのは時間の問題だな。

いま気付いたんだが、２CH書き込み＆FF11ログイン規制って・・・

ny自体に串を持たせて・・・　
例えば1.2.3って通信してるなら1から直接3にダウンしているようにみせかけて
ＩＳＰの帯域制限対策をするとか　どうですか？

別に現状の状態でもかまいまへんわ＾

>>39
> どうですか？
もっとネットワークの仕組みを勉強してから出直してください。

47が新しい暗号プロトコルに変更すれば良いだけだが、
京都府警あたりからパソコンが帰ってこないから
なんにもできないのか？

多分、返す気無いと思うｗ
クソ京都府警は。

>>37
それ見て思ったんだけど、実は一点壁って送受信ポートが両者とも1000番以降の奴を切断してるだけとちゃうか？
但し、PASVなFTPに対応するために21番でもセッション張ってるのだけは通してる、みたいな。
他に1000番以降使うメジャーなプロトコルあったっけ？

メッセンジャーとか？

X Window Systemとかnfsとかircとか

>>44
メジャーなプロトコルは1024未満を使う。
1024以降を使うメジャーなプロトコルは無い。

ただし、メジャーなプロトコルを使わない、
メジャーなアプリは沢山ある。

ここはようはみなあほばかりだ

を、ちらほらと偽物が出始めたようで。
俺の正体がバレにくくなるので適当に騙っててくだされ(藁

で、>>45-47
なるほどねえ。それで「ルーター通んねえぞ(ﾟдﾟ)ｺﾞﾗｧｧｧ!!」って騒いでるのが後を絶たない訳だ。
流石にメッセは対応してるだろうけども、XWindowとか微妙にマイナーっぽいのまで止まってたらビンゴ？
どっかに人柱レポないかなあ。

本当の1はトリップ付けれ

それはさておき簡単な進捗状況など。

・親子Squid実験は継続中。なんか途中で訳もなく切れる謎の現象が発生。
　Squid自体の問題かもと思い始めてる(普通にやっててもたまに切れる)
・暗号通信関係をひたすら勉強。
　やはり現時点では、成りすましを防止するためには認証局が必須、と言うことらしい。
　自分は対タンパ技術まるっきりトーシローなので、解析喰らう前提で考えていたのだが
　ちょっと無理ぽくなってきた。

それでちょっと考えたんだけども、何種類かの擬装を用意して、それをランダムに切替えて
接続ってやったら撹乱出来るだろうか？

もしくは、SOCKSを実装して本物のメッセ等と通信を混ぜてしまう。
この手に訴える場合、俺一人では氏んじゃうからオープンソースにして協力者募るしかないな。
それとも、既にあるのかな？

えーっと、これでｲｲのかな？
でもこれは、将来ブツが出来た時の証明用と考えてるんで、暫く付けません。
なんで本物かどうかは各自好きに邪推してお楽しみください(藁

これってUtataneにも対応できませんか？？

>>53
あー、１は無知なのでその手の要望出す時は纏めサイトなり入門スレなりを提示してくだちい。

>>51
暗号アルゴリズムなら、Twofishがお勧め。
暗号化するたびに、暗号化ファイルのバイナリがランダムに変わるんだよ。
でも復号化はきちんとできる。

これなら、暗号化するたびにバイナリが変わるから、パターンでブロックが出来なくなる。

(･∀･)ﾄﾞｳｾｶﾀﾙﾀﾞｹﾃﾞﾂｸﾙｷﾈ-ﾀﾞﾛ!!

>>54
ttp://www.geocities.co.jp/SiliconValley-PaloAlto/9537/
これだす

1は八頭身氏か？(･∀･)

期待∩ﾟ∀ﾟ∩age

んで、パケット暗号化パスワードは固定でないほうが良いので、
接続確立時にランダムで生成したパスワードのやり取りをする、と。

手順はSSLをパクればよいのではないだろうか。

1. コネクション確立
2. RSA公開鍵交換
3. 乱数にてTwofishパスワード生成
4. RSAにてTwofishパスワード暗号化
5. 暗号化されたTwofishパスワード交換
6. RSA秘密鍵にてパスワード復号化
7. 交換したTwofishパスワードにてパケットを暗号化し通信

これは接続のたびに行わなくても、起動したら生成する方式でも、
ある程度はなんどかなるのではないだろうか。
とまぁ勝手に妄想を膨らませてみた。

ちなみにけっこうメンドクサイ上、CPUパワー食うよ。
RSAは128bitくらいで限界かもね。

One Point WallってFreenetブロックできるのかね。
あれはどういう暗号化(?)してるんだ？

保守age

ファイル提供してる人には大助かり？